Niall Power wrote: > Hi all, > > A while back, I posted here about the issues ZFS has with USB hotplugging > of ZFS formatted media when we were trying to plan an external media backup > solution for time-slider: > http://www.opensolaris.org/jive/thread.jspa?messageID=299501 > > As well as the USB issues in the subject we became aware of some serious > issues > with the ZFS send/recv stream format's backwards and forwards compatibility.
What serious compat issues ? There has been one and only one incompatible change in the stream format and that only impacted really really early (before S10 FCS IIRC) adopters. > This was enough incentive to make us think about other potential solutions. > One > of my colleagues in Xdesign (Frank Ludolph) came up with the suggestion of > using > a ZFS mirror of the root pool as the mechanism to backup to an external > device. > This seemed like a very nice idea. It made use of existing functionality that > already > exists in ZFS and works reliably, allows time-slider to expose yet another > great feature > of ZFS to the desktop/laptop user: > > * It provides a full, reliable backup that is maintained in sync with the > main storage device > * No user interaction required. Just plug the disk in and pull it out when > you like. ZFS will > resynchronize it ASAP > * Provides a bootable backup mechanism. The mirror is bootable and the > main disk can be > fully replaced and/or recovered from it. > * Errors on the main disk can be corrected from the external device and > vice versa. > * Simplified UI - user doesn't have to configure backup schedules etc. I actually see that as a downside, but given we have autosnapshots with time-slider it is acceptable. > * Resynchronisation is always optimal because zfs handles it directly > rather than some > external program that can't optimise as effectively However the MAJOR disadvantage of using mirroring though is that the backup disk needs to be at least as large as the normal rpool disk (and will only be used to the exact size - resulting in wastage). Rather than when using zfs send/recv where the backup disk only needs to be big enough to hold the data stored on the rpool. For example I have a 150G internal drive in my laptop but the smallest drive I can easily buy in a retail/consumer enclosure to attach via USB is 500G that is a massive amount of waste. At the other end of the scale USB flash drives are around the 16G mark but might be plenty big enough for the datasets I actually care about (like my data not the OS and not my Music because I have other copies of that on my iPods anyway). Using zfs send/recv also allows for the possibility of using a single backup disk (pool) for multiple machines, making better use of that 500G USB drive than backing up a single 150G internal laptop drive. Really to do this properly with mirrors the "zpool split" capability needs to be implemented, however I think it is the wrong solution - or rather a complementary one to using zfs send/recv (or even using rsync if preservation of the snapshots isn't important). -- Darren J Moffat _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
