On Wed, 16 Jul 2003, Jody.Gregersen AT VISHAY DOT COM wrote:
> What I was thinking of doing next was to do an mminfo and figure out
> what files are on each tape and then running 4 CLI recover's at a
> time specifying each file on each of the 4 tapes. Does anyone use
> this type of recover? Anyone have any comment on how they think
> this type of recover might work?
6.0.3 here.
I do parallel recovers by calling mminfo for a particular directory,
e.g. A, and getting ssid numbers a1, a2, a3...
Then I call
recover [other arguments, for instance -d RESTORE_DIR -s SERVER and -i
OVERWRITE_MODE] -S a1
recover [other arguments] -S a2
recover [other arguments] -S a3
in sequence (optionally multiple ssids can be batched together) . All
this is in one single Perl script which I can post if anyone is
interested. I can call the script for directory A in one session,
directory B in another session, etc. (using GNU screen works really
well, you can keep all your restores as screen sessions and check on
them from home). It effectively parallelizes the restore process,
depending on how deep the directory branching goes. You can start a
separate process for each subdirectory of A, for instance, and the
recover processes will request the tapes they need separately.
I asked the list earlier about save set consolidations; the problem
was precisely that I didn't know what would happen if a file existed
in one save set but not in a later one (not because it was deleted,
but because of a problematic backup). The file could be assumed to be
deleted, and I circumvent the problem by doing the restores described
above with one ssid at a time. The delay caused by this seems to be
minimal.
Another advantage of one-ssid-at-a-time restores is that if a ssid
resides on a bad tape, which has happened, you can interrupt that
particular recover process and go on to the next one. With multiple
ssids you have to backtrack, which is a bit more annoying.
Hope that helps... I know I spent too much time working this out :)
Ted
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
