Sometimes trying to be clear gets me in trouble :-)
On Sep 3, 2009, at 10:24 AM, Ross wrote:
Some points to help clarify the situation:
1. There is no other way to archive a dataset than
n using a snapshot
Other than tar, star, and numerous other archive utilities.
You are talking about files. Snapshots are for datasets. There is
more information in a dataset than the collection of files.
[perhaps Darren can chime in regarding encrypted datasets :-)]
The fact that ZFS doesn't have any alternative built in doesn't
mean that dumping a send to a file suddenly becomes a good idea.
It is the only way to archive a dataset.
By comparison, for UFS you could dd the file system. But since the
pool can contain many different vdevs, and dd only works on one
vdev, zfs send is the method to capture the dataset.
Especially when there is no step in those instructions to verify
that the archived file is actually a valid zfs send stream.
There is little precedent for this, but I agree that verification should
be done, if possible. Process can prevent future pain.
Going back to the UFS case, if you dd a UFS file system, the only
way to verify is to (effectively) dd again, which means that the file
system must be quiesced -- an unpopular requirement because
fssnap is ...uhhmm... limited. Similarly, ufsdump captures the logical
view of the file system, but has no inherent verification capability.
I'll wager that few people verify UFS dd/ufsdump output (I do, but
that is because I've got scars from using Exabyte drives :-(
2. You cannot build a zpool on a tape
So you need a different solution for tape, possibly streaming the
files to tape, with the zpool configuration also documented and
backed up somehow if necessary.
The information unique to a pool, besides its (mutable) physical layout,
is quite small. Other than zpool status and zpool get all, is more
needed?
Is there a use case lurking here?
ZFS represents a new way of managing data. zfs send is just one of the
new tools in the kit, but it won't replace an enterprise backup
solution.
zfs send is complementary to an enterprise backup solution.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
