>>>>> "mg" == Mike Gerdts <mger...@gmail.com> writes: >>>>> "tt" == Toby Thain <t...@telegraphics.com.au> writes: >>>>> "tb" == Thomas Burgess <wonsl...@gmail.com> writes:
mg> Yet it is used in ZFS flash archives on Solaris 10 and are
mg> slated for use in the successor to flash archives.
in FLAR, ``if a single bit's flipped, the whole archive and any
incrementals descended from it are toast'' is a desireable
characteristic. FLAR is a replication tool, just like 'zfs send | zfs
receive' together are, and the sensitivity's desireable because you
want a deterministicaly exact replica.
If zpools themselves had the characteristic, ``single bit flipped,
entire pool lost,'' few would be happy with that. In fact it's part
of the ZFS kool-aid cocktail that bitflips are detected and reported,
and that critical metadata is written several times far apart on the
pool so the damage of a single bitflip, even on an unredundant pool,
is limited. Other things that aren't ``enterprise backup solutions'',
like tarballs, are also resilient to single bit flips. so, why
tolerate this fragility from a backup format? It's not appropriate.
The other problems are lack of a verification tool that doesn't
involve ponderous amounts of kernel code revision-bound to hardware
drivers and such that may one day become unobtainable, the possibility
of painting yourself into a corner (ex. if you are backing up a 17TB
filesystem, you must provide 17TB of restore space or else there is no
way to access a 2kB file), and the stream format which is
intentionally tied to the relatively often-changing zfs version so
that it can make exact copies but at the cost of constraining the
restore environment which may be separated from the backup environment
by seven years and/or in the midst of a disaster in a way that
tarballs and cpios and so on don't constrain.
Another problem is that the snv_112 man page says this:
-----8<-----
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.
-----8<-----
I think the new man page says something more generous. The use case
here is, we should be able to:
old solaris new solaris newer solaris
zfs send -----------------> zfs recv
\
\_____ zpool upgrade -->
(not 'zfs upgrade')
-- zfs send
|
-> zfs recv
zfs recv <----------------------------------------- zfs send
That is, the stream format should be totally deterministic given the
zfs version, and not depend on the zpool version nor the
kernel/userland version. This way a single backup pool can hold the
backups of several different versions of solaris. The alternative to
this level of guarantee is for your archival backup to involve a ball
of executable code like a LiveCD or a .VDI, and that's just not on.
Seven to ten years, people---there are laws TODAY that require
archiving WORM media that long, and being able to read it, which means
no rewriting for a decade. That's a ``hard requirement'' as
Christopher says, _today,_ never mind what's desireable or useful.
I'm not sure the new man page makes a promise quite that big as
accomodating the above chart, but IIRC it's much better than the old
one.
anyway, zfs send and receive are very good replication tools, and
replication can be used for backup (by replicating into another zpool
*NOT* by storing the stream modulo the caveat above) or for system
install (by recv'ing multiple times like FLAR).
If you choose to store zfs send streams as backups, the least you can
do is warn those you advise that zfs send streams are different from
other kidns of backup stream, because sysadmin experience in how to
write backups is old and hard-won, and these tools diverge from it.
they diverge usefully---I'm not putting them down---I'm saying *don't
use them that way* unless you are able to think through
$subtleproblems, after which you'll probably not want to use them that
way.
tt> I can see the temptation, but isn't it a bit under-designed? I
tt> think Mr Nordin might have ranted about this in the past...
no, I think it's great for FLAR. single-bit-self-destruct is exactly
what's wanted for FLAR.
for those case where you could somehow magically capture and replay an
rsync stream it's great. It's not a dumb design because IMHO a single
format probably can't do well for both replication and backup, but
it's not a backup format, enterprise or otherwise. What escalates my
objection into a rant is the way ``enterprise backup solution'' gets
tossed around as some kind of soundbite hatetorial prole phrase
substituting and blocking off exploring the actual use cases which
we've done over and over again on this list. I bet the phrase is
still there on the si wiki, implying while sneakily and lawyer-like
not outright saying, that the tools are non-enterprise backup tools
like 'tar', but they're not, and a hundred web2.0 sneaker-wearing
douches scribbling away in bouncylogo textpad iwordpress meblog will
not make me wrong.
>> Cpio coes not support sparse files and is unable to archive
>> files > 8 GB.
tb> I found this out the hard way last time i used it.
yeah, I guess they all suck. Also some of them, like tar, don't have
checksums.
the solaris userland is ancient, so if you use gtar you'll be
surprised less often, like IMHO you are less likely to have silently
truncated files, but then it's maintained upstream so it's missing
support for all these forked files, mandatory labels, and windows
ACL's that they're piling into ZFS now for NAS features.
When we brought it up last time, I think we found no one knows of a
userland tool similar to 'ufsdump' that's capable of serializing a ZFS
along with holes, large files, ``attribute'' forks, windows ACL's, and
checksums of its own, and then restoring the stream in a
filesystem-agnostic read/write/lseek/... manner like 'ufsrestore'.
pgpcmOkH1ae3W.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
