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 <ewi...@ewilts.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.de...@gmail.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 > ewi...@ewilts.org > >
_______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
