ADSM-L

Re: Mitigating Risk with TSM's incremental backups

2002-01-25 13:25:38
Subject: Re: Mitigating Risk with TSM's incremental backups
From: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
Date: Fri, 25 Jan 2002 20:24:04 +0200
Only one remark:
As Kelly pointed reusedelay parameter has to be set how long to keep
already reclaimed tape before reuse.
This is parameter for both primary and copy pools. *BUT* the parameter also
must be greater than the oldest DB backup kept on-site and off-site.
If you restore from DB backup say 4 days old but reusedelay is set to only
2 days a tape reclaimed 2 days ago may be reused again. And DB restore from
4-days old DB backup does not know about that !!
So bring back on-site only "empty" tapes. If tape is in state "pending"
this means its data is already reclaimed on another cartridge but we still
have old DB backup unaware of the fact.
And as a rule of thumb:
perform "del volh tod=-<DB_retension> t=dbb" using daily administrative
schedule and have reusedelay for every storage pool longer than
<DB_retension> days.

Zlatko Krastev
IT Consultant





"Kauffman, Tom" <KauffmanT AT NIBCO DOT COM> on 24.01.2002 16:32:06
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: Mitigating Risk with TSM's incremental backups

I'd suggest using TSM to back the data up to LTO, then back up the LTO
storage pool to a copy pool and send the copies off-site. Run reclaims and
only bring back empty or pending empty off-site tapes. My worst case sends
off a tape that is 5% full daily. The reclaim actually kicks in just after
the tapes are checked out. The downside to this is the number of $110 LTO
tapes you need, and that's a function of how often you move tapes off-site
and how often you bring back the empties.

You don't need DRM for this, although it may help (never tried it, so I
can't help there). I've got a few conventions I use and a few scripts that
simplify life, and we ship off-site daily, with the empties coming back on
Friday. The naming convention I use is <poolname> as diskpool,
<poolname>-LT
as tape pool, and <poolname>-LT-COPY as copy pool: INDEF (disk pool for our
commonstore), INDEF-LT, and INDEF-LT-COPY. One of the daily scripts does
the
backup storage pool. Another does a "q vol stg=*copy acce=reado,readw
st=fil,ful", captures the volsers and does the "checkout libvol <library>
<volser> remove=bulk checklabel=no". A typical day sees 8 tapes going
off-site, including the TSM database backup; a normal Friday has 40 tapes
coming back, including 5 week-old TSM database backups.

Hope this helps -

Tom Kauffman
NIBCO, Inc

> -----Original Message-----
> From: Justin Derrick [mailto:jderrick AT CANADA DOT COM]
> Sent: Thursday, January 24, 2002 8:06 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Mitigating Risk with TSM's incremental backups
>
>
> I've been using TSM for quite a few years on AIX, and
> surprisingly, this
> issue hasn't come up before.
>
> My customer is using TSM in conjunction with Content Manager
> OnDemand.  The
> config looks like this:
>
> AIX 4.3.3 on H70
> OnDemand, DB2, TSM
> Data is cached on disk (by OnDemand, not TSM), and also
> copied to Optical
> (a la 3995), then backed up to LTO.
> They are currently a very low-volume shop, adding under 1GB a
> day to the
> TSM system.
>
> The question raised to which I didn't have a good answer was:
>
> If we take a non-full LTO offsite for disaster recovery purposes, then
> bring it back onsite as part of regular rotation, a vulnerability is
> created.  If the tape is on site when a disaster occurs
> (which would always
> be the case since their courier only delivers once a day),
> not only is that
> day's information lost, but all the previous days of incrementals
> previously written to the tape are destroyed as well.
>
> I know we could keep multiple copypools in the chain, but it
> seems like an
> expensive solution to a simple problem.
>
> The immediate solution would be to create new 'full' backups of the
> contents of the optical jukebox every day, and take them
> offsite.  While
> this would actually be feasible in the short term (given
> their low growth)
> it would quickly become unmanagible in the future.
>
> Is the solution to simply buy enough tapes so that you simply
> send one tape
> a day offsite for as long as possible, then perform large
> reclaimation once
> every 'long as possible'?  This sounds like it's within the
> realm of the
> DRM, which I'm woefully inexperienced with.  Any advice,
> direction, etc.
> would be greatly appreciated.
>
> -JD.
>