|
we've been doing
this "hack" for years for moving data between sites and business recovery.
we backup data to tapes, ship the tapes, and tar the catalog and ftp it to the
master at the other site. 1 step that you may be able to do, and avoid
editing the *FULL files: in the bp.conf file, use the "force restore media
server" option. it tells netbackup that if the restore says to use a
certain media server (that may not
even exist in your current netbackup
environment), use this other one.
such as:
FORCE_RESTORE_MEDIA_SERVER = dallas_nb1 hous2
FORCE_RESTORE_MEDIA_SERVER =
denver_nb hous2
much simpler and no need to take a chance on
screwing up the catalog files.
thanks,
jerald
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
Donaldson, Mark
Sent: Thursday, July 16, 2009 8:56
AM
To: Dean; veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re:
[Veritas-bu] Any thoughts on this "hack" to avoid import?
Force
the assignment? "vmquery -assignbyid"
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
Dean
Sent: Thursday, July 16, 2009 6:49 AM
To:
veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Any
thoughts on this "hack" to avoid import?
Woops, just after sending that, I
realised I can't freeze an unassigned tape.
On Thu, Jul 16, 2009 at 10:42 PM, Dean <dean.deano AT gmail DOT com>
wrote:
Thanks Ed, I appreciate the input.
Yeah, in a perfect
world, I would flip the write protect on all the tapes. But they are in a
managed site, which is quite difficult to get access to. I'm thinking I'll
probably just freeze them.
And regarding the 2GB file size, I'm only
editing the small "index" files in the catalog - the flat text files that
describe the details of the backup and fragments. The largest one I've run into
so far was about 30 KB.
Regards,
Dean
On Thu, Jul 16, 2009 at 9:52 AM, Ed Wilts <ewilts AT ewilts DOT org>
wrote:
Very interesting... You're going to make a lot of
people very, very happy if this turns out to be stable.
A couple of
things to be aware of. You might want to throw the write-protect tabs on
those tapes if they have them (I don't know anything about the 3592
drives). Right now, you really, really don't want the new environment to
reach out bu accident and bite you by expiring an image you don't want
expired. When you're checking your list on tapes to re-use, flip the tab
back and re-label the tape, and make EMM happy.
I'd watch for any files
that are over 2GB - some of the scripts you're working with to do inplace
updates may break on large files. Ask me how I know :-). We ran into
this doing a Windows to Solaris master conversion many years ago.
I'll
let others chime in on whether rewriting those files was a good idea or
not.
.../Ed
On Wed, Jul 15, 2009 at 6:04 PM, Dean <dean.deano AT gmail DOT com>
wrote:
Hello veritas-bu'ers.
I'm interested to hear if any of
you experts have any thoughts on my current scenario.
We have recently
moved on from a NBU 5.1 on HPUX environment to NBU 6.5 on Linux (with a
different master server name). Mainly because of urgent requirements at the
time, I just created a new master server, installed NBU 6.5 from scratch, and
didn't bother about integrating the NBU 5.1 catalog.
Now the HP server
has been decommissioned, and it's time to do something about the long term (7
year retention) backups.
Last week, I started Phase 2 import on a
spangroup (connected set of tapes) of Lotus Notes backups. I left it running
over the weekend. It ran for 3 days, and only got through 3 of the 1,000 or so
tapes I have to import. At that rate, it's going to take over 3 years to get all
the imports done. Aside from the constant monitoring, that basically means one
expensive (IBM 3592) tape drive in use constantly for 3 years, and a constant
drain on our cross-site fibre bandwidth.
However, I seem to have found a
"hack" that allows me to restore from these old backups, without having to
import the tapes.
I have found that you can copy the catalog entries from
the old catalog to the new one, then edit the *FULL index files, replacing the
old master server/media server name on the FRAGMENT records with the new master
server name, and the backup image appears completely normal in the new system,
with all the right attributes, including expiry date, and can be restored
from.
I wrote a small script to automate the catalog file modifications,
and managed to get these 7 years worth of backups cataloged in the new NBU
server, in about 20 minutes, as opposed to 3 years of importing. I tested
several restores, and it all works perfectly.
The only issue seems to be
that that NBU doesn't know much about the actual tape. I have all the old tapes
in a seperate volume pool called "imported", which no policies can (should) EVER
write to. (feature request for Symantec? - read only volume pools). When I do a
bpmedialist on one of these tapes, NBU/EMM thinks it's unassigned. I have a list
of when all these tapes are due to expire on the old system, and my current plan
is just to check this list periodically and move them from the "imported" pool
to the scratch pool when they are due (I'll probably script this bit
aswell).
It all makes perfect sense to me.
I guess this post
serves two purposes:
1: To see if any seasoned experts see any problems with
this approach.
2: To catalog this "hack" on this mailing list, for posterity
:)
Cheers!
Dean
.../Ed
Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE
ewilts AT ewilts DOT org
****************************************************************
Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in
reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
****************************************************************
|
