Joerg Schilling wrote:
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.
Is that because they are NFSv4 ACLs? tar uses the formatting routines
from libacl to archive them.
--
Ian.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
