ADSM-L

Re: [ADSM-L] Serializing BACKUP STGPOOL / MOVE DRMEDIA

2014-06-04 09:51:01
Subject: Re: [ADSM-L] Serializing BACKUP STGPOOL / MOVE DRMEDIA
From: Skylar Thompson <skylar2 AT U.WASHINGTON DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 4 Jun 2014 06:49:07 -0700
This is pretty close to what we do now. We check out our tapes Tuesdays,
upload the list of tapes Wednesday to our offsite vendor, and the courier
comes on Thursday to pick them up. I actually toyed with the thought of
checking out tapes daily automatically, since our library I/O slots could 
handle a
day's worth of backups without issues, but the human interrupt overhead
seems a bit exorbidant for that.

On my way home (for some reason technical insight seems to come when I'm far 
from a
computer), I realize we might be able to use simultaneous copy to solve
this. We have the drive capacity to handle the byte-load of our backups,
but we have some clients that scan tens of millions of files, so not all of
our clients have the ability to stream directly to tape.

If I can identify these clients (or directories) ahead of time, I might be
able to get the bulk of our data into copy pools as part of the client
backup cycle, before BACKUP STGPOOL runs. If that's the case, we might be
able to have our weekly maintenance include MOVE DRMEDIA, and have a hope
of it actually getting to MOVE DRMEDIA during regular business hours.

I'll see how that goes next week.

Thanks for the ideas, everyone!

On Wed, Jun 04, 2014 at 01:36:38PM +0000, Rick Adamson wrote:
> Skylar,
>
> Rather than use the TSM "maintenance" script I chose to create my own.
>
> I added all the processes to one script, with the WAIT=YES and 
> Serial/Parallel options was able to schedule these processes so they don't 
> overlap.
>
> For example; disk pool migration runs in parallel, then expiration runs 
> serial, the pools are backed up in parallel followed by reclaims, switch to 
> serial for a DB backup and prepare. Each process group waits on the previous 
> one to complete before starting.
>
> If needed add appropriate trigger for an occasional incremental DB backup.
>
> As far as the "Move DRM" task, all my systems are daily but why not only run 
> it on the day you physically transport tapes, after all if they are remaining 
> onsite for days does it really matter if they are moved from mountable to 
> vault, or ejected from the library on days they aren't being sent off site? 
> The risk is the same because the tape is still there.
>
> In the end you may even use less tapes because day after day the system can 
> continue to use filling tapes until the day the physically move.
>
> Just my thoughts, hope it helps....

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine