Thanks, Dave. This made me think. though, that there could be a problem
with selecting a level saveset as opposed to all the incrementals. Let's
say the saveset for the file system in question looked like:
level=full July 11, 2004
level=incrementals July 12-19, 2004
level=5 July 20, 2004
level=incrementals July 21-26, 2004
and you wanted to use saveset recover to rebuild something in that
saveset as of July 25, 2004. If someone had created one or more new
files July 19, and they were captured by the incremental that night, and
then they deleted them before the level 5 ran on July 20, then when you
go to do saveset recover using the full, the level 5 and all the
incrementals up to July 25, you would not get those files. But if you
instead used the full and all the incrementals up to July 25 then you
would have those files. Guess this would be slower, and you might end up
with more files you don't need? Maybe not a problem if you're trying to
make it look like it did on July 25, so maybe better to use the level 5
since the results will be closer to what nwrecover would have done --
more unwanted files but less than if you had picked all the incrementals.
George
Dave Mussulman wrote:
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
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
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
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
