Hey Niall, > Here are the issues that I am aware: > - Running "zfs upgrade" on a zfs filesystem will > cause the "zfs send" stream output format to be > incompatible with older versions of the software. > This is according to the zfs man page. > - Again from the zfs man page: > "The format of the stream is evolving. No > backwards com- > patibility is guaranteed. You may not be able > to receive > your streams on future versions of ZFS."
Well yes, but this really shouldn't be a problem for this usage. It just means there's no guarantee that you can always do a send/receive between different versions of Solaris (although most of the time you'll be ok), but there's nothing stopping you doing a send/receive to an external device. It will never be a problem in this situation because you're doing the send/receive on the same system, so you can't be running two clashing versions. The absolute worst case scenario I can think of is that you might have to keep the external device's zfs pool running the same version of zfs as your live pool. I really don't see this being a problem for you. > From the thread I linked to in my original post, it > was pointed out that there is no error > checking or checksum info in the file blobs of the > stream. No, there's no error checking while *sending* the stream. However, ZFS checks as it's receiving it, so provided you are receiving this into a live zfs pool this isn't a concern. The checksum issue is only a problem if you're storing the zfs send as a binary blob. Receiving it into a proper zfs pool is fine. It's not quite so flexible as mirroring in that you can't do this as incrementally as mirrors (ie you can't restart the operation), for each stream it's all or nothing. However, after the initial synchronisation you'll be sending incremental snapshots so there shouldn't be too much data to send. And that ties in perfectly with time slider's automatic snapshots. I would also hope that zfs send/receive might improve in the future to allow for resuming sends since this seems a relatively common request. > > 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. > > > > This is true, but consumer level storage is soooo > cheap nowadays. > One company has even turned it into a excuse to sell > external storage > devices. I think they're named after some kind of > fruit or something :) Maybe, but being able to store *years* worth of snapshots on your external media, even if you only have space for a few months worth on your live system is a big plus. Also, there's no need to keep just one external backup drive. You could just as easily send to two of them. Or even buy a 500GB drive and synchronise all your snapshots to that for a year, then buy another one when it's full and start sending the next lot of snapshots. There's potential to keep far, far more data this way, in a much more flexible way. And thinking about it, I think it ties in perfectly with time slider. You could have a second set of options for how long you want to keep snapshots on your external devices. You could even have those options configurable per device. So you could have a 200GB backup device that you just keep your recent data on, and a 1TB one that you use occasionally but store years worth of snapshots on. By running a script as the devices are plugged in, you could check the pools to synchronise and the last snapshot received. From there you could look at the local rules and decide which new snapshots need sending over to bring the device up to date. It also means you can show status more easily, without any of the confusion mirrors would cause in zpool status. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
