>>>>> "da" == David Abrahams <d...@boostpro.com> writes: >>>>> "ic" == Ian Collins <i...@ianshome.com> writes:
da> disadvantage of the recommended approaches shows up when you
da> start taking advantage of ZFS to clone filesystems without
da> replicating storage. Using "zfs send" will avoid representing
da> the data twice
Two or three people wanted S3 support, but IMVHO maybe S3 is too
expensive and is better applied to getting another decade out of
aging, reliable operating systems, and ZFS architecture should work
towards replacing S3 not toward pandering to it.
Many new ZFS users are convinced to try ZFS because they want to back
up non-ZFS filesystems onto zpool's because it's better than tape, so
that's not a crazy idea.
It's plausible to want one backup server with a big slow pool,
deliberately running a Solaris release newer than anything else in
your lab. Then have tens of Solaris's of various tooth-length 'zfs
send'ing from many pools toward one pool on the backup server. The
obvious way to move a filesystem rather than a pool from older Solaris
to newer, is 'zfs send | zfs recv'.
The obvious problem: this doesn't always work.
The less obvious problem: how do you restore? It's one thing to say,
``I want it to always work to zfs send from an older system to a
newer,'' which we are NOT saying yet. To make restore work, we need
to promise more: ``the format of the 'zfs send' stream depends only on
the version number of the ZFS filesystem being sent, not on the zpool
version and not on the build of the sending OS.'' That's a more
aggressive compatibility guarantee than anyone's suggested so far,
never mind what we have.
At least it's more regression-testable than the weaker compatibility
promises: you can 'zfs send' a hundred stored test streams from
various old builds toward the system under test, then 'zfs send' them
back to simulate a restore, and modulo some possible headers you could
strip off, they should be bit-for-bit identical when they come out as
when they go in. zpool becomes a non-fragile way of storing fragile
'zfs send' streams.
And to make this comparable in trustworthyness to pre-ZFS backup
systems, we need a THIRD thing---a way to TEST the restore without
disrupting the old-Solaris system in production, a restore-test we are
convinced will expose the problems we know 'zfs recv' sometimes has
including lazy-panic problems---and I think the send|recv architecture
has painted us into a corner in terms of getting that since gobs of
kernel code are involved in receiving streams so that there's no way
to fully test a recv other than to make some room for it, recv it,
then 'zfs destroy'.
so... yeah. I guess the lack of 'zfs send' stream compatibility does
make into shit my answer ``just use another zpool for backup. Tape's
going out of fashion anyway.'' And when you add compatibility
problems to the scenario, storing backups in zpool stream rather than
'zfs send' format no longer resolves the problem I raised before with
the lack of recv-test. I guess the only thing we really have for
backup is rsync --in-place --no-whole-file.
ic> I wouldn't have any serious concerns about backing up
ic> snapshots provided the stream version was on the tape label
ic> and I had a backup of the Solaris release (or a virtual
ic> machine) that produced them.
I would have serious concerns doing that because of the numerous other
problems I always talk about that you haven't mentioned.
But, I don't wish for 'zfs send' to become a backup generator. I like
it as is. Here are more important problems:
* are zfs send and zfs recv fast enough now, post-b105?
* endian-independence (fixed b105?)
* toxic streams that panic the receiving system (AFAIK unfixed)
though, if I had to add one more wish to that list, the next one would
probably be more stream format compatibility across Solaris releases.
Understand the limitations of your VM approach. Here is the way you
get access to your data through it:
* attach a huge amount of storage to the VM and create a zpool on it
inside the VM
* pass the streams through the VM and onto the pool, hoping none are
corrupt or toxic since they're now stored and you no longer have
the chance to re-send them. but nevermind that problem for now.
* export the pool, shut down the VM
[this is the only spot where backward-compatibility is guaranteed,
and where it seems trustworthy so far]
* import the pool on a newer Solaris
* upgrade the pool and the filesystems in it
so, you have to assign disks to the VM, zpool export, zpool import.
If what you're trying to restore is tiny, you can make a file vdev.
And if it's Everything, then you can destroy the production pool,
recreate it inside the vm, u.s.w. No problem. But what if you're
trying to restore something that uses 12 disks worth of space on your
48-disk production pool? You have free space for it on the production
pool, but (1) you do not have 12 unassigned disks sitting around nor
anywhere to mount all 12 at once, and (2) you do not have twice enough
free space for it on the production pool so that you could use iSCSI
or a file vdev on NFS, yo uonly have one times enough space for it.
wtf are you supposed to do? With traditional backup methods your
situation is workable because you can restore straight onto the free
space in the production pool, but with ZFS you must convert your
backup into disk images with the VM first, then restore it a second
time to its actual destination. And with the ponderously large pool
sizes ZFS encourages, providing these ``disk images'' to the restore
VM could mean doubling your hardware investment.
This breaks the filesystems-within-pools aggregation feature of ZFS.
Filesystems are supposedly the correct unit of backup, not
pools---this is pitched as one reason filesystems exist in the first
place. But in this example, compatibility issues effectively make
pools the unit of backup because it is only a pool that you can
reliably pass from an older Solaris to a newer one, not a filesystem.
You're right to say ``a VM'' though. A backup of the solaris DVD used
to do the 'zfs send' is not worth much when hardware is becoming
unobtainable on a 6mo cycle---you won't be able to run it anywhere.
pgpC7V7kKJ26T.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
