Allen Eastwood wrote:
On Jan 19, 2010, at 22:54 , Ian Collins wrote:
Allen Eastwood wrote:
On Jan 19, 2010, at 18:48 , Richard Elling wrote:
Many people use send/recv or AVS for disaster recovery on the inexpensive
side. Obviously, enterprise backup systems also provide DR capabilities.
Since ZFS has snapshots that actually work, and you can use send/receive
or other backup solutions on snapshots, I assert the "problem" is low priority.
What I have issue with is the idea that no one uses/should use tape any more. There are places for tape and it still has value as a backup device. In many cases in the past, ufsdump, despite it's many issues, was able to restore working OS's, or individual files. Perfect, not by a long shot. But it did get the job done.
As was pointed out earlier, all I needed was a Solaris CD (or network boot) and I could restore. Entire OS gone, boot and ufsrestore. Critical files deleted, same thing…and I can restore just the file(s) I need. And while it's been a few years since I've read the man page on ufsdump, ufsrestore and fssnap, those tools have proven useful when dealing with a downed system.
For a full recovery, you can archive a send stream and receive it back. With
ZFS snapshots, the need for individual file recovery from tape is much reduced.
The backup server I manage for a large client has 60 days of snaps and I can't
remember when they had to go to tape to recover a file.
--
Ian.
Let's see…
For full recovery, I have to zfs send to something, preferably that understands tape (yes, I know I can send to tape directly, but how well does zfs send handle the end of the tape? auto-changers?).
I keep a stream (as a file) of my root pool on a USB stick. It could be
on tape, but root pools are small.
Then for individual file recovery, I have snaphots…which I also have to get on
to tape…if I want to have them available on something other than the boot
devices.
No, just keep the snapshots in place. If a file is lost, just gab it
form the snapshot directory. If the root filesystem is munted, roll
back to the last snapshot.
Now…to recover the entire OS, perhaps not so bad…but that's one tool. And to
recover the one file, say a messed up /etc/system, that's preventing my OS from
booting? Have to get that snapshot where I can use it first…oh and restoring
individual files and not the entire snapshot?
As I said, roll back. Boot form install media, import the root pool,
get the file from a snapshot, or roll back to the last good snapshot,
export and reboot.
At best, it's an unwieldy process. But does it offer the simplicity that
ufsdump/ufsrestore (or dump/restore on how many Unix variants…) did? No way.
It certainly does for file recovery. Do you run incremental dumps every
hour, or every 15 minutes? Periodic snapshots are quick and cheep. As
I said before, careful use of snapshots all be removes the need to
recover files from tape. We have 60 days of 4 hourly and 24 hourly
snapshots in place, so the odds on finding a recent copy of a lost file
are way better than they would be on daily incrementals. I certainly
don't miss the pain of loading a sequence of incrementals to recover
lost data.
So ZFS solves the problems in a different way. For fat-finger recovery,
it's way better than ufsdump/ufsrestore.
A simple, effective dump/restore that deals with all the supported file
systems, can deal with tape or disk, and allows for complete OS restore or
individual file restore, and can be run from a install CD/DVD. As much as I
love ZFS and as many problems as it does solve, leaving this out was a mistake,
IMO.
It possibly was, but it has encouraged us to find better solutions.
--
Ian.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
