Miles Nordin wrote:
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)
We should see a resolution for this soon, I have have a support case
open and I no have a reproducible test case. I haven't been able to
panic any recent SXCE builds with the streams that panic Solaris 10.
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.
Luckily for us, they haven't broken it yet on a production release.
They would give them selves a massive headache if they did. One point
that has been overlooked is replication, I'm sure I'm not alone in
sending older stream formats to newer staging servers.
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
I currently use iSCSI.
* 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.
I receive the stream as well as archive it.
* 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
Not necessary.
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.
I don't do this for "handy" backups. We only do this to archive a
filesystem.
--
Ian.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
