| I very strongly disagree. The closest ZFS equivalent to ufsdump is
| 'zfs send'. 'zfs send' like ufsdump has initmiate awareness of the
| the actual on disk layout and is an integrated part of the filesystem
| implementation.
I must strongly disagree in turn, at least for Solaris 10. 'zfs send'
suffers from three significant defects:
- you cannot selectively restore files from a 'zfs send' archive;
restoring is an all or nothing affair.
- incrementals can only be generated relative to a snapshot, which
means that doing incrementals may require you to use up significant
amounts of disk space.
- it is currently explicitly documented as not being forward or backwards
compatible. (I understand that this is not really the case and that this
change of heart will be officially documented at some point; I hope that
people will forgive me for not basing a backup strategy on word of future
changes.)
The first issue alone makes 'zfs send' completely unsuitable for the
purposes that we currently use ufsdump. I don't believe that we've lost
a complete filesystem in years, but we restore accidentally deleted
files all the time. (And snapshots are not the answer, as it is common
that a user doesn't notice the problem until well after the fact.)
('zfs send' to live disks is not the answer, because we cannot afford
the space, heat, power, disks, enclosures, and servers to spin as many
disks as we have tape space, especially if we want the fault isolation
that separate tapes give us. most especially if we have to build a
second, physically separate machine room in another building to put the
backups in.)
- cks
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
