On Jul 9, 2006, at 12:32 AM, Richard Elling wrote:
I'll call your bluff. Is a zpool create any different for backup
than the original creation? Neither ufsdump nor tar-like programs
do a mkfs or tunefs. In those cases, the sys admin still has to
create the file system using whatever volume manager they wish.
Creating a zpool is trivial by comparison. If you don't like it,
then modifying a zpool on the fly afterwards is also, for most
operations, quite painless.
_Huh_?
I was taking the stance that ZFS is a completely different paradigm
than UFS and whatever volume management might be present underneath
that and should be treated as such. I don't accept the argument that
"it wasn't in UFS, so we don't see the need for it in ZFS."
What I was getting at was for a way to dump, in a human-readable but
machine parsable form (eg: XML) the configuration of not only a zpool
itself, but also the volumes within it as well as the settings for
those volumes.
Hypothetical situation:
I have all my ZFS eggs in one basket (ie, a single JBOD or RAID
array). Said array tanks in such a way that 100% data loss is
suffered and it and its disks must be completely replaced. The files
in the zpool(s) present on this array have been backed up using, say,
Legato, so I can at least get my data back with a simple restore when
the replacement array comes online. But Legato only saw things as
files and directories. It never knew that a particular directory was
actually the root of a volume nested amongst other volumes.
So what of the tens or hundreds of ZFS volumes that I had that data
sorted in and the individual (and perhaps highly varied)
configurations of those volumes? That stuff - the metadata - sure
wasn't saved by Legato. If I didn't manually keep notes or hadn't
rolled my own script to save the volume configs in my own
idiosyncratic format, I would be up the proverbial creek.
So I postulated that it would be nice if one could save a zpool's
entire volume configuration in one easy way and restore it just as
easily if needed.
Instead of:
1) Bring new hardware online
2) Create zpool and try one's best to recreate the previous volume
structure and its settings (quota, compression, sharenfs, etc)
3) Restore data from traditional B&R system (legato, netbackup, etc)
4) Pray I got (2) right.
5) Play config cleanup whack-a-mole as time goes on as mistakes or
omissions are uncovered. In all likelihood it would be the users
letting me know what I missed.
...I could instead do:
1) Bring new hardware online
2) Create zpool and then 'zfs config -f zpool-volume-config-backup.xml'
3) Restore data from wherever as in (3) above
4) Be reasonably happy knowing that the volume config is pretty close
to what it should be, depending on how old the config dump is, of
course. Every volume has its quotas set correctly, compression is
turned on in the right places, the right volumes are shared along
with their particular NFS options, and so on.
Having this feature seems like a no-brainer to me. Who cares if SVM/
UFS/whatever didn't have it. ZFS is different from those. This is
another area where ZFS could thumb its nose at those relative
dinosaurs, feature-wise, and I argue that this is an important
feature to have.
See, you're talking with a person who saves prtvtoc output of all his
disks so that if a disk dies, all I need to do to recreate the dead
disk's exact slice layout on the replacement drive is to run that
saved output through fmthard. One second on the command line rather
than spending 10 minutes hmm'ing and haw'ing around in format. ZFS
seems like it would be a prime candidate for this sort of thing.
/dale
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
