On Wed, Jul 27, 2005 at 03:13:15PM -0400, George Sinclair wrote:
> Just want to clarify my understanding here:
> If you're not using something like nsrck -L7 to merge in an older index,
> and you're gonna instead use saveset recover to rebuild a directory then
> you have to select the last full (depending), and all of the
> incrementals from the full up to the most recent time you want since you
> don't know which saveset instances would have the directory and which
> would not. If the directory only changed a few times since the last full
> then it might not be on all those savesets, but unless you knew, you'd
> have to play it safe and select all of them, right? Seems a bummer since
> some of those savesets might be very large and might not even have that
> directory on them if no changes occurred that day, but guess there's no
> other way. Gotta byte the bullet.
Right, except that you might be able to skip some savesets if you had
higher levels. ie: a full at the start of the month, a level 5 each
Sunday, otherwise an incremental daily would mean a restore from the end
of the month would only need the full, the last 5, and the incrementals
after the level 5. If all the backups are incrementals, you'll need to
step through all of them. Faster restores is one of the reasons we
switched to weekly level 5s; it also means we don't need to keep so many
tapes at hand to do the restores.
Another gotcha: If a file was created for the full, and deleted by the
third incremental, the multiple saveset restores would put that file
back and not know to remove it. (It just wouldn't be updated after the
second incremental, unless it was overwritten by a later version.) So,
a full+multiple incremental restore doesn't necessary recreate the file
system exactly as it was; deleted files will be back. The ability to
recreate a directory as it was at a certain time is a feature the
indexes give you.
> If the saveset was 300 GB, and you only needed to recover a 2 MB
> directory then I guess saveset recover must read through the entire
> saveset, so even if what you want is right at the beginning, unless
> you're absolutely certain you have all your data, you have to let it
> continue to read every thing else, right?
The backups work on the drives sequentially. I can't think of a
scenario where it would write part of a directory to tape, move
somewhere else, and then write more of the first directory. (I can
think of scenarios where other things get streamed to the tape that
cause that kind of a gap, but on a per-client basis the feed should be
serial.) If you're only restoring one directory, you could probably get
away with stopping the restore after you know that directory is done
being restored. Networker keeps going only because the only way it's
sure to restored everything under that directory is to scan every file
in the saveset. To be safe, I'd wait.
If you want to speed things up, you can kick off multiple ssid restores
at the same time (provided they're on different tapes/drives) and write
them back to their own "holding zone" where you can re-assemble the
pieces later. Also, as with anything else restore-wise, the less
parallelism you have when writing to the drive means the faster the
restore will be. That might not help you now, but, you know, for next
time. :)
Dave
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
