We probably have fewer tapes than you do, but we have two cases LTO cases
for our offsite tapes - up to 20 tapes per case.
They rotate on-site daily. While onsite, we put a 'disaster floppy' and a
full DB backup into the case along with any on-site copypool tapes. We pull
the
previous 'disaster floppy' and db backup, and any tapes that are pending
to come back on site (found with a q vol * access=offsite status=empty ).
If they are in that case, it is OK and we pull them to go back in the
library.
If not, we don't worry, they will come in the other case eventually.
We do not leave a case onsite overnight. When it comes on site, it goes
offsite with the same tape runner. As our library grows, I expect we will
just add another case, and another day, to our tape rotation.
Right now we have 17 copypool tapes, 2 are listed empty, and two are
pending. And 18 tapes in our library, 1 cleaner, 4 scratch, one old
database backup that was returned, and the rest are tape pool (13 tapes)
that are either full or filling.
Before a question is asked (not by you, but from some others) the 'disaster
floppy' is a copy of our volhist, devconfig, license files, and a listing of
other disaster information and README.TXT files with some basic directions
of how to handle things.
The disaster floppy gets put into a separate LTO tape case and put with
its related full backup in particular location in the tape case each day.
In case of a disaster, look on the floppy for the latest dates, and follow
the
directions -- or at least that is the idea.
I hope this helps.
My eventual hope is to do remote vaulting over our network so we can do
without the tape cases and the offsite tape storage vendor altogether.
> -----Original Message-----
> From: Seay, Paul [SMTP:seay_pd AT NAPTHEON DOT COM]
> Sent: Wednesday, October 23, 2002 6:02 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Offsite Vaulting with Locked Canisters
>
> Actually, our issues had nothing to do with old backup methodology. Cost
> of
> open storage was a concern but we would have probably been OK with that.
> The real issue is if a 3590K tape is dropped, the chances of it being
> readable are bordering on slim and none, same is true for LTO and 9840.
> The
> Vault people are never going to admit they dropped a tape. These people
> get
> paid $6/hr and need the job. So, it gets into physical protection of the
> media and the ability to rely on its readability which is ultimately a
> data
> integrity issue. Data integrity is the reason we do this.
>
> Paul D. Seay, Jr.
> Technical Specialist
> Naptheon Inc.
> 757-688-8180
>
>
> -----Original Message-----
> From: Mark Stapleton [mailto:stapleto AT BERBEE DOT COM]
> Sent: Wednesday, October 23, 2002 8:28 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Offsite Vaulting with Locked Canisters
>
>
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Seay, Paul
> > Think for a second, if reclaimation supported a days option versus the
> > current percent utilized option. If that was the case you could set
> > that number of days about 7 days less than when the closed boxes are
> > to return and achieve the goal.
> >
> > Well, I have written the code to do just that via the MOVE DATA vvvvvv
> > RECONSTRUCT=YES based on the change date in the drmedia table. We have
> > been doing this for about 9 months now, very successfully.
> >
> > I still use DRM for its management functionality, but I would not
> > require it to achieve the goal.
>
> The point I was making (perhaps not too successfully) is that all attempts
> to perform cannister-based "batch" offsiting are just trying to make TSM
> mimic the behavior of <ahem> lesser backup systems. Backup Exec, Arcserve,
> and Netbackup all work on the "batch of tapes" system of offsiting.
>
> Granted, TSM's method of offsiting is based on manipulation of individual
> tape volumes, which can be laborious when handling large numbers of tapes.
> That's the way TSM works out of the box, and I for one don't see much
> reason
> to go into elaborate scripting efforts and large-scale MOVE DATA and MOVE
> NODEDATA gymnastics to get to a goal that TSM handles quite nicely all by
> itself. As I've stated in the ADSM-L FAQ, you're not using your old backup
> software anymore.
>
> --
> Mark Stapleton (stapleton AT berbee DOT com)
> Certified TSM consultant
> Certified AIX system engineer
> MCSE
|
