On 2011-May-12 00:20:28 +0800, Edward Ned Harvey <opensolarisisdeadlongliveopensola...@nedharvey.com> wrote: >Backup/restore of bootable rpool to tape with a 3rd party application like >legato etc is kind of difficult. Because if you need to do a bare metal >restore, how are you going to do it?
This is a generic problem, not limited to ZFS. The generic solutions are either: a) Customised boot disk that includes the 3rd party restore client b) Separate backup of root+client in a format that's restorable using tools only on the generic boot disk (eg tar or ufsdump). (Where "boot disk" could be network boot instead of a physical CD/DVD). >I might suggest: If you use "zfs send" to backup rpool to a file in the >data pool... And then use legato etc to backup the data pool... As Edward pointed out later, this might be OK as a disaster-recovery approach but isn't suitable for the situation where you want to restore a subset of the files (eg you need to recover a file someone accidently deleted) and a "zfs send" stream isn't intended for storage. Another potential downside is that the only way to read the stream is using "zfs recv" into ZFS - this could present a problem if you wanted to migrate the data into a different filesystem. (All other restore utilities I'm aware of use normal open/write/chmod/... interfaces so you can restore your backup into any filesystem). Finally, the send/recv protocol is not guaranteed to be compatible between ZFS versions. I'm not aware of any specific issues (though someone reports that a zfs.v15 send | zfs.v22 recv caused pool corruption in another recent thread) and would hope that zfs recv would always maintain full compatibility with older zfs send. >But I hope you can completely abandon the whole 3rd party backup software >and tapes. Some people can, and others cannot. By far, the fastest best >way to backup ZFS is to use zfs send | zfs receive on another system or a >set of removable disks. Unfortunately, this doesn't fit cleanly into the traditional enterprise backup solution where Legato/NetBackup/TSM/... backs up into a SILO with automatic tape replication and off-site rotation. >Incidentally, when you do incremental zfs send, you have to specify the >"from" and "to" snapshots. So there must be at least one identical snapshot >in the sending and receiving system (or else your only option is to do a >complete full send.) And (at least on v15) if you are using an incremental replication stream and you create (or clone) a new descendent filesystem, you will need to manually manage the initial replication of that filesystem. BTW, if you do elect to build a bootable, removable drive for backups, you should be aware that gzip compression isn't supported - at least in v15, trying to make a gzip compressed filesystem bootable or trying to set compression=gzip on a bootable filesystem gives a very uninformative error message and it took a fair amount of trawling through the source code to find the real cause. -- Peter Jeremy
pgpnNCrRwuYrc.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
