ADSM-L

Re: Monthly Backups, ...again!: The Real Issues

2002-04-10 01:15:14
Subject: Re: Monthly Backups, ...again!: The Real Issues
From: "Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
Date: Wed, 10 Apr 2002 01:14:47 -0400
I would like to find the first customer out there with 20 clients (80+GB
servers) that does not lose a full backup at least once a week and exceeds
the backup window time and has no backup of that server.  Or similarly on
the incremental that is not restartable.

TSM does checkpointing and completes a backup after restarting at the backup
point.  Heck, I have HALTed my TSM server in the middle of backups and
watched them restart at were they left off.  I did it to see what would
happen.  My Windows folks lost 1 backup that was in a unrecoverable
initialization state at the time of the halt.  And, that was easily
restarted.  There is no other viable product in the market that can do this.

The argument is you cannot restore the incremental because it takes too long
is bogus.  I never could realize what I was missing in the conversation
until I read Zlatko's explanation below.  I forget that the Weekly FULL
paradigm INCREMENTAL daily makes people think they have to restore each file
to make up the incremental many times.  When TSM just restores the right one
to the point in time that you need recovery.

There is an issue that concerns me that most folks forget about.  Your DR
offsite set may span a long period of time.  After so long the tapes may not
be readable because the DR site people dropped them a couple of times and
you not know it.  Two sets pose the same threat, but less so.  So, if a tape
is bad, you lose a lot of data, possibly a lot of servers if many are in the
same storage pool and you do not have any collocation turned on.  There are
two solutions to this problem.  If we had reclaim a tape if it was created
more than x days ago, that would force reclamation on a tape no matter what.
The other is a duplicate offsite pool.  Neither of these capabilities are
automatic today.  To get the tapes to reclaim you have to do your own MOVE
DATA RECONSTRUCT=YES for any tape last written to over x days (it would be
nice to have an optional value to specify in the storage pool for this).
The duplicate offsite requires you to run the BACKUP STG for each copy (it
would be nice to specify multiple outs if that makes sense and is possible).
The other thought that I have had is to have multiple copy pools and rotate
through them updating each on on a cyclic basis.  So, if you had 6 and you
sent an update offsite weekly you would have 6 intact storage pools.  But,
the server overhead to do this is significant.

Other FULL Backup tools have a way around this by accepting a week older
backup of the data.  Essentially, they have 6 copies of the data offsite.
Just a matter of how much data they want to lose.

The point here is plan your TSM environment to meet your business recovery
needs and you will have a vastly superior solution than any other product
can offer.

<Prev in Thread] Current Thread [Next in Thread>