> 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.
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."
So while the stream format has only changed once in the past, it doesn't
provide much
reassurance that it won't change in the future. This basically rules out
network backups
unless the remote target is running a compatible verisons of ZFS since file
blobs of the
stream maybe incompatible in the future.
- 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.
These would appear to be real blockers for this approach for us. Am I
misunderstanding the
issues? Or is there a viable solution that isn't subject to these constraints?
> > * 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.
Why would it be a downside? Normal user's don't like doing backups.
Our software will be more useful if it doesn't have to rely on the user
doing something we know they are not going to do until it's too late.
>
> > * 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.
>
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 :)
>
> 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).
We could create a partition on the disk that's
large enough to mirror the primary pool, leaving the
rest of the disk free for the user to use as they wish.
>
> 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
I haven't heard of this before. Any pointers?
Thanks,
Niall.
> 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-discu
> ss
--
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
