Julian Regel <jrmailgate-zfsdisc...@yahoo.co.uk> wrote: > When I look at the documentation for Zmanda > (http://docs.zmanda.com/Project:Amanda_Enterprise_3.0/ZMC_Users_Manual/Appendix_A:_Backing_Up_and_Restoring_Solaris_ZFS), > it states that the command used to backup a ZFS filesystem depends on > whether backing up ACLs are required (the default is not to(!)). If backing > up ACLs are required - which they are for us - then the native /usr/bin/tar > command is used. Given that /usr/bin/tar doesn't handle sparse files > correctly and updates atime when creating archives, it's not possible to > create a complete copy of a filesystem without making intrusive changes to > the structure of the data and/or metadata. > > So it's arguable that ufsdump was a significant improvement over tar, and > that the current archiving solutions for ZFS are actually a step backwards. > > > From my perspective, Sun really need to create a zfsdump/zfsrestore set of > > commands that perform block level backups of a specified filesystem (or > > snapshot) and that preserves ACLs, atime, sparse files, handles multiple > > tapes (many of us still use and rely on tape!) etc.
Sun's tar is not able to archive files > 8 GB in a way that can be read on any other OS unless you use star. This is because Sun's tar does not implement support for the POSIX.1-2001 extended tar format. Sun's tar also writes ACLs in a way that is 100% non-portable. Star cannot understand them and probably never will be able to understand this format as it is not well defined for a portable program like star. Star supports to do backups without affecting atime (on Solaris) since 15 years already and star supports the withdrawn POSIX draft ACLs in a OS independent way. This allows to use star for platform independent ACL support in case you are using UFS on Solaris. Star will in future support NTFS ACLs in a OS independent way. If someone likes to contribute, he is of course welcome. As I am currently working on cdrtools-3.0-final, star is currently on maintenance only. What we need for the future is a OS/FS independent program that implements the needed features. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de (uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss