On Jul 7, 2006, at 1:45 PM, Bill Moore wrote:
That said, we actually did talk to a lot of customers during the development of ZFS. The overwhelming majority of them had a backup scheme that did not involve ufsdump. I know there are folks that live and die by ufsdump, but most customers have other solutions, which generate backups just fine.
Perhaps these dev customers needed to spend a little more time with ZFS, and do it in a production environ where backups and restores are arguably of a more urgent matter than in a test environment.
Regarding making things "ZFS aware", I just had a thought off the top of my head; the feasibility of which I have no idea and will leave up to those who are in the know to decide:
ZFS we all know is just more than a dumb fs like UFS is. As mentioned, it has metadata in the form of volume options and whatnot. So, sure, I can still use my Legato/NetBackup/Amanda and friends to back that data up... but if the worst were to happen and I find myself having to restore not only data, but the volume structure of a pool as well, then there a huge time sink and an important one to avoid in a production environment. Immediately, I see quick way to relieve this (note I did not necessarily imply "resolve this"):
Add an option to zpool(1M) to dump the pool config as well as the configuration of the volumes within it to an XML file. This file could then be "sucked in" to zpool at a later date to recreate/ replicate the pool and its volume structure in one fell swoop. After that, Just Add Data(tm).
/dale _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
