Tim,
Sorry I missed your reply before responding to Davina...would have
helped clarify things for me before I sent that.
I would think that transferring the indexes and running the "scanner -m"
might have saved me a significant amount of time over a full "scanner
-i" given that these are large savesets with many small files (mailstore
backups, some savesets spanning 5+ tapes)...if I read right, there
wouldn't be a danger of the indexes being pruned in the meantime
(networker runs nsrck -L1 on startup, and it seems that pruning would
only happen with an -L3 or higher, or a -m).
However, if I do go the route of simply keeping a record and scanning in
savesets as needed, I'll have to use scanner -i, and I think in the end
that is what I will go with. I've backed up a copy of the output of
mminfo -av and mminfo -av -m, and will use that as needed.
As for ssid collisions, according to Preston's post and my searching,
looks like I should not have a problem with ssids. The only matching
short ssids occurred between a saveset on the new server and a bootstrap
on the old server, which I would not have need nor ability to recover.
Many thanks to all of you for your input - you have been a wonderful help!
Regards,
Greg
---
Tim Mooney wrote:
In regard to: [Networker] Moving client to a different Networker
server,...:
*Quote:*
I'm working to migrate a few clients from one Networker 7.4.4 server to
another,
Same OS, OS version, and architecture, I assume?
*Quote:*
and I'm trying to discern the quickest way to merge the index and db
entries into the new server. The documents (DRG) are a little vague on this
process, so I'd love if anyone could recommend. Leaving the old server
operational is not an option as I need to convert it into a storage node,
which will necessitate wiping out the /nsr folder and starting clean.
There are no public tools for merging two media databases. Assuming that
the server you're moving to already has media and index entries that you
want to keep, the only way to get information from the media database from
the old server into the new server is with scanner.
Let's be clear -- the client file indexes are a non-issue, there are
several ways to deal with them. It's populating the media database that
is the challenge.
*Quote:*
Seems to me like the recommended procedure would be as follows:
On old server, run 'savegrp -O -G GROUP' for all clients on to one tape.
Insert tape into library for new server.
Run scanner -i on new server to populate indexes.
That only saves the indexes and the bootstrap. Those don't really do you
much good, unless the new server also knows where to find some actual
backups of the client data (i.e. media database entries for all the
savesets that the indexes you just saved reference).
You should probably instead consider
savegrp -l full GROUP
Followed by a scanner of that tape. Whether or not you also then run
savegrp -O GROUP doesn't matter -- if you run scanner -i on a tape
containing full backups of your clients, it will (slowly) build the
indexes from the savesets. If you're going to use -i with scanner, you
don't need to have the index savesets on tape.
If the servers are both same os/arch/version, there is one tiny shortcut
you could take. Copy the client indexes from the old server to the new
one and then just run "scanner -m" rather than "scanner -i". You're still
going to end up scanning any tapes that the new server needs to know
about, but -m is faster than -i, especially if you're talking about a lot
of tapes. So sayeth EMC support.
If you're not in a true disaster recovery situation, I would probably just
go with the full backup and then scanner -i method.
*Quote:*
My question is: is this the most efficient way (or can I move index
files and
run some iteration of nsrck),
Won't work, because although the client file indexes can be copied on a
per-client basis, the media database is an opaque blob. The way to
populate it is with scanner.
If you were to move the client file indexes and then run nsrck (anything
from -L1 to -L6), nsrck is probably just going to prune most of what's in
your client file index anyway, because it believes that any savesets
referenced no longer exist, because there are no media database entries.
You also can't use nsrck -L7, because there needs to be media database
entries for the index savesets to pull them back. You're back to scanner
-m, at a minimum.
Tim
--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
Davina Treiber wrote:
Greg Etling wrote:
Interesting that it would appear then that EMC's own documentation and
support reps have led me astray on this! The scanner -i suggestion
(which the man page says "Rebuilds both the media and the online file
indexes from the volumes read.") came from both the 7.4 DR Guide (pg.
46) and from an EMC support rep.
They're correct. Scanner rebuilds the media database and optionally the
client file index from the data save sets on the tape, but not from a
backed up index on the tape.
I can certainly see that concurrent saveset IDs could cause a problem -
but what I fail to see is how they don't become a problem in all
scenarios you describe. Either via scanning in all old savesets or
scanning as necessary; if you hit a saveset with a duplicate ssid,
wouldn't you cause the same problems? And does the conflict arise from
standard ssids, long ssids, or both? I only appear to have one short
ssid conflict and no long ssid conflicts.
That's a good question and I am not certain of the answer. I assume that
it will renumber save sets as it scans them.
Lastly, in scenarios 1 and 2, recognizing the limitations you have
described, how do you use scanner to scan in savesets from which you
need to restore, if the media db entries do not exist? Given that our
retention period for these save sets is only three months, I will likely
use scenario 2 but before I go forward I need to be sure to know how to
run saveset and file level restores in the intervening three months.
Part of what scanner does is to recreate the media database entries as
it goes.
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
