>>>>> "dm" == David Magda <dma...@ee.ryerson.ca> writes:
dm> Yes, in its current state; hopefully that will change some
dm> point in the future
I don't think it will or should. A replication tool and a backup tool
seem similar, but they're not similar enough.
With replication, you want an exact copy, and if for some reason the
copy is not exact then you need something more: you want atomicity of
operations so the overwatcher scheduler:
* can safely retry the send|recv until it works,
* can always tell its minder with certainty how much has safely been
replicated so far,
* can attempt further replication without risking existing data.
These things are a bit hard to achieve. And zfs send|recv does them:
* If a single bit is flipped the whole stream should be discarded
* If, on a 'send' timeline of <full>, <incremental>, <incremental>,
<incremental>, one of the preceeding blobs did not make it, or
became bad on the replication target (because somebody wrote to it,
for example---a FAQ), it should become impossible to restore
further incremental backups. The error should not be best-effort
worked around, or simply silently concealed, the way it is and
should be with restoring incremental backups.
* reslicing the unit of replication after writing the stream is
irrelevant, because you can just reslice on the replication-source
if you need to do this. The possibility of reslicing interferes
with the atomicity I spoke of which makes the replication scheduler
so much easier to get correct.
* there's no need to test a stream's validity without restoring it.
The replication target will always be available and have enough
free space to test-by-receiving.
* there's no need to restore the stream on an unimagined future
filesystem. It's more important that all fancyfeatures, ACL's,
gizmos, properties, compression modes, record sizes, whatever, make
it to the replication target exactly to avoid surprises. No one is
worried about data being locked in to a certain filesystem because
it's all there for you to get with rsync on both replication source
and target.
Try to use such a tool for backup, and you court disaster. Your pile
of backups becomes an increasingly large time-lapse gamma ray
detector, which signals a ray's presence by destroying ALL the data
not just the bit, not even just the file, that the ray hit. The
impossibility of reslicing (extracting a single file from the backup)
means that you can find yourself needing 48TB of empty disk on a
development system somewhere to get out a 100kB file locked inside the
atomic blob, which is an unacceptable burden in time and expense. The
other points have obvious problems for backups, too---I'll leave
inventing imaginary restore scenarios as an exercise for the reader.
All these harmful points are things that replication wants/needs. The
goals are incompatible.
If there's going to be a snapshot-aware incremental backup tool for
ZFS, I do not think zfs send|recv is a good starting point. And I'm
getting frustrated pointing out these issues for the 10th time---it
seems like, I mention five relatively unsolveable problems, and people
seize onto the easiest one, misinterpret it, and then forget the other
four.
the versioning issue (NOT mentioned above) is a problem for
replication among different Solaris releases, not just backup. It
means you could potentially have to upgrade a whole mess of machines
at once. At the very least you ought to be able to upgrade the target
before you upgrade the source, so you don't have to break replication
while doing the upgrade---coincidentally that's the right direction
for upgrade-test-downgrade, too, since it's on the target that you'd
possibly have to destroy the zpools if you decide you need to
downgrade. We should want this and don't have it yet.
It makes having a single backup pool for a lab full of different-aged
systems impossible (even with backward-only compatibility, how do you
restore?), so it is worth solving for that use case too. I think the
'zfs send' format of a given filesystem should be bit-for-bit
identical given a certain ZFS version, irrespective of zpool version
or kernel release on the sending system. That's enough to solve the
single-lab-backup-pool problem, and it's also
regression-testable---keep some old streams around, recv them into the
pool under test, send them back out, and make sure they come out
identical. And the 'zfs recv' panics need fixing. those would both
be great things, but they would *NOT* make zfs send|recv into a backup
system! They would make it into a better replication system.
zfs send|recv will not become backup tools if you manage to check off
a few other list-of-things-to-fix, either. They can't be both a good
replication system and a good backup system at the same time.
no, I don't think the si wiki explains the full size of the issue
adequately. It makes it sound like the tools are just a little too
small, and maybe someday they will get bigger, maybe some people
should just ignore the advice and use them anyway. It's CYA bullshit.
i think in the mean time you should make backups with cpio (or some
tool that uses something similar underneath like Amanda) or by
archiving file-vdev zpools. not perfect but better. And you should
store it on the medium in some way that the whole thing won't be wiped
by one flipped bit (not gzip).
pgp3QM5dzFvcs.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
