ADSM-L

Re: backup stgpool

2005-09-09 09:46:52
Subject: Re: backup stgpool
From: Jon Evans <Jon.Evans AT HALLIBURTON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 9 Sep 2005 14:46:26 +0100
Andy..

>Note
>that you can configure your TSM server so that data will be written
>simultaneously to primary and copy storage pools, you might want to
look
>into that as well, though it might prove a little difficult due to
having
>only two tape drives.)

I understand that simultaneous write is not supported for the Lan free
backup client.. any idea if there are plans to change this in the near
future?

Many thanks

Jon

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Andrew Raibeck
Sent: 08 September 2005 20:41
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: backup stgpool

Hi Sandra,

I think one concept to understand is that a copy storage pool is a
logical, point-in-time mirror image of the primary storage pool(s) that
are backed up by that copy storage pool.

Let's say for the sake of simplicity that you have two primary storage
pools, DISKPOOL and TAPEPOOL; and that you have one copy storage pool,
COPYPOOL.

After you run:

   BACKUP STGPOOL DISKPOOL COPYPOOL
   BACKUP STGPOOL TAPEPOOL COPYPOOL

COPYPOOL will contain copies of all the backup versions in DISKPOOL and
TAPEPOOL.

Next, if a client runs a backup, the new backups will go to one of the
primary storage pools. At this time, the copy pool is no longer a
complete
image of the primary pools, until you run the next set of BACKUP STGPOOL
commands. This is not a "problem", just a point of understanding. (Note
that you can configure your TSM server so that data will be written
simultaneously to primary and copy storage pools, you might want to look
into that as well, though it might prove a little difficult due to
having
only two tape drives.)

The net result is that after the BACKUP STGPOOL commands complete, you
can
restore any data from COPYPOOL that you could restore from DISKPOOL or
TAPEPOOL. If you keep 4 days worth of backups in DISKPOOL and TAPEPOOL,
then you can restore any of those 4 days worth of backups from COPYPOOL.
Thus if the primary pools contain 4 backup copies of a file, COPYPOOL
also
has 4 backup copies of that file. If you were to find that one of the
tapes in COPYPOOL was corrupt, you could try restoring a different
version
of the file, assuming it resides on a tape that is not corrupt.

> Now my understanding is:
> 1- DB tapes along with plan file would decide which tapes in DR set
are
> required.
>
> Now confusion is:
> 1- What would happen if one of my data tapes required by certain DB
and
plan
> file gets corrupted, since backup stgpool has incremental backup, that
file
> might not be recoverable leading to entire restore failure.

If a particular version of a file cannot be restored, you can see if
there
is an earlier available version. The number of available versions
depends
on your copy group settings and how often the file changes.

The possibility of faulty media is a reality in *any* recovery
situation.
You must have some *very* stringent restore requirements if the failure
to
restore a single file would cause the entire restore operation to be
"failed". :-)    But note that you can have as many copy pools as you
want:

   DEFINE STGPOOL COPYPOOL1 ...
   DEFINE STGPOOL COPYPOOL2 ...
   ...
   DEFINE STGPOOL COPYPOOLn ...

   BACKUP STGPOOL DISKPOOL COPYPOOL1
   BACKUP STGPOOL DISKPOOL COPYPOOL2
   ...
   BACKUP STGPOOL DISKPOOL COPYPOOLn
   BACKUP STGPOOL TAPEPOOL COPYPOOL1
   BACKUP STGPOOL TAPEPOOL COPYPOOL2
   ...
   BACKUP STGPOOL TAPEPOOL COPYPOOLn

Now you have n copy pools, each of which mirrors your primary storage
pools. In the event of a disaster, if a file cannot be recovered from
one
copy storage pool, it can be restored from another.

The number of copy storage pools you need depends on a number of
factors:

1) What are the chances that you will *ever* need to do a full disaster
recovery?
2) What are the chances that you will *ever* need to do a full *offsite*
disaster recovery?
3) What are the chances of media failure?
4) What are the chances that a media failure will result in the
inability
to restore a *vital* file?
5) You are already planning to have an onsite copy pool and an offsite
copy pool. What are the odds that your primary pools, onsite copy pool,
and offsite copy pool will *all* fail at the same time?

There are probably other factors, but this is a good starter list. The
point is, this is like insurance: how much do you *want*, how much do
you
*need*, and how much can you *afford*?

The worst case scenario is when there is a full offsite disaster
recovery,
and all primary and local copy storage pools are destroyed. So you are
relying on a single offsite copy pool. If that is too risky, then
consider
two offsite copy pools.

Having said that, instead of having one onsite copy pool, why not just
have two offsite copy pools. Again, assess the risks: what are the odds
that you will actually need your copy storage pools in the event that a
non-offsite recovery is needed? If the odds are very low, then consider
just having your primary storage pools onsite, and if you need copy
storage pool volumes, retrieve them from the offsite location if and
when
that becomes necessary.

> 2- WOULD the DB expire, planfile expire and reuse delay of 4 make meto
do full
> backup of stgpool on 5th day? or what??

No. Just as your TSM database and storage pools reflect the current set
of
available client backup versions, so do the copy storage pools. The
database backups and planfiles are just point-in-time images of your TSM
server environment. Expiring database backups or planfiles does not
cause
expiration of the actual client backup versions in the live database and
storage pools. Thus backup of storage pools on day 5 is just another
incremental backup of your storage pools.

>
> Another insight by Todd is also making good sense to me and i am
following his
> point too and is also probably one of the solutions to my problem.
> but my above
> confusions still remain the same.

There are far too many "unknowns" about your environment for me to make
a
specific statement, but as a general statement, I think trying to
circumvent TSM's "natural" behavior is making things harder than they
need
to be (DR planning is already hard enough!!)   :-)     If I were a
consultant for you, I would want to know a *lot* more about your
environment and your recovery requirements before I could make sweeping
suggestions about how to configure your DR setup, especially if you are
inclined away from TSM's natural behavior.

Best regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-09-08
11:05:19:

> Welll Andrew,
> I had misconception as under:
> 1- backup stgpool will backup entire primary storagepool daily with DB
tape.
> This would be one set and on disaster, this set will recover us to the
point
> where that DB stands.
>
> 2- If any data tape in above set gets corrupted, i have a choice of
going back
> one step for earlier set of DR tapes. This way i presumed that
> DBexpire and plan
> expire  would give me 4 sets of "DB and data" to recover to.
>
> Now my understanding is:
> 1- DB tapes along with plan file would decide which tapes in DR set
are
> required.
>
> Now confusion is:
> 1- What would happen if one of my data tapes required by certain DB
and
plan
> file gets corrupted, since backup stgpool has incremental backup, that
file
> might not be recoverable leading to entire restore failure.
>
> 2- WOULD the DB expire, planfile expire and reuse delay of 4 make meto
do full
> backup of stgpool on 5th day? or what??
>
> Another insight by Todd is also making good sense to me and i am
following his
> point too and is also probably one of the solutions to my problem.
> but my above
> confusions still remain the same.
>
> Can anyone please enlighten me on this?
>
> Kind Regards
> Sandra
>
>
> Andrew Raibeck wrote:
>
> > > Ok..i have to have two copy storage pools both having a complete
and
> > > separate set of tapes. From this i understand that everytime the
> > > stgpool backup is performed, there is no way to tell TSM that you
> > > need to take full backup of primary pool instead of incremental
from
> > > what it did last day.
> >
> > That is correct.
> >
> > Why would you want to do otherwise?
> >
> > Regards,
> >
> > Andy
> >
> > Andy Raibeck
> > IBM Software Group
> > Tivoli Storage Manager Client Development
> > Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> > Internet e-mail: storman AT us.ibm DOT com
> >
> > The only dumb question is the one that goes unasked.
> > The command line is your friend.
> > "Good enough" is the enemy of excellence.
> >
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-09-07
> > 23:21:02:
> >
> > > Hmmm thanks andy,
> > > I have changed the reuse delay to 4, that is the same as dbbackup
> > > expiration days.
> > >
> > > Ok..i have to have two copy storage pools both having a complete
and
> > > separate set of tapes. From this i understand that everytime the
> > > stgpool backup is performed, there is no way to tell TSM that you
> > > need to take full backup of primary pool instead of incremental
from
> > > what it did last day.
> > >
> > > Kind Regards
> > > Sandra
> > >
> > >  ---- storman AT US.IBM DOT COM wrote :
> > > > Hi Sandra,
> > > >
> > > > I'm sure you'll get plenty of advice and suggestions from
others,
but
> > here
> > > > are my "two cents":
> > > >
> > > > Once concern right off the bat is the reuse delay of zero, which
puts
> > at
> > > > risk your goal of 100% restore capability of up to 4 days ago.
> > Instead,
> > > > your reuse delay should be the same as your dbbackup and plan
file
> > > > expiration settings. Consider the case where on day 1, tape 'A'
> > contains
> > > > valid data that is expired on day 2. Tape 'A' is now empty, so
it
is
> > > > available for immediate reuse. On day 3, the tape is written
over
with
> > new
> > > > data. Now it is day 4, and you need to restore your database
back
to
> > day
> > > > 1. You restore the database back to day 1. Now you want to
restore
> > data
> > > > from tape 'A' that was there on day 1... but that data no longer
> > exists
> > > > because it was written over with new data on day 3... and your
100%
> > > > restore capability is out the window.
> > > >
> > > > >From what you wrote, I am under the impression that you think
you
> > need
> > > > multiple sets of copy storage pools to allow you to restore up
to
4
> > days
> > > > ago. But this is not true. Since each copy pool is a logical
mirror of
> > the
> > > > primary pools, a single copy pool is all that is necessary to
restore
> > your
> > > > data up to four days ago (assuming everything else is also
configured
> > to
> > > > minimally meet the four day requirement). If you want an onsite
copy
> > pool
> > > > and an offsite copy pool, then have two copy pools: one that
stays
> > onsite,
> > > > and another that goes offsite. You can then run BACKUP STGPOOL
> > multiple
> > > > times to back up the primary pools to each of your copy pools.
If
you
> > need
> > > > more onsite copy pools, you can define them and back up the
storage
> > pools
> > > > to them.
> > > >
> > > > Regards,
> > > >
> > > > Andy
> > > >
> > > > Andy Raibeck
> > > > IBM Software Group
> > > > Tivoli Storage Manager Client Development
> > > > Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> > > > Internet e-mail: storman AT us.ibm DOT com
> > > >
> > > > The only dumb question is the one that goes unasked.
> > > > The command line is your friend.
> > > > "Good enough" is the enemy of excellence.
> > > >
> > > > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on
2005-09-07
> > > > 21:41:21:
> > > >
> > > > > Dear All,
> > > > > I am running TSM 5.2.3 on Windows 2003 with 3582 Library with
2
> > > > > drives. Ultrium2 tapes with 200GB space.
> > > > >
> > > > > Daily incremental backup of about 5GB.
> > > > >
> > > > > I have setup a copypool to which i backup my primary pool
daily.
The
> > > > > plan file (after running prepare) has ever increasing tapes
required
> > > > > for primary stgpool restore.
> > > > >
> > > > > My question:
> > > > > Can i take full backup of stgpool daily and not the
incremental
on
> > > > > daily basis. The command refernce says it won't copy any file
to
> > > > > copypool until the file is damaged or not available in
copypool...
> > > > > that is sort of incremental.
> > > > >
> > > > > Purpose is to send one set of DR tapes to offsite weekly on
friday.
> > > > > I want this set to be 100% capable of restoring my environment
while
> > > > > at the same time, having 3 sets of DR at main site so that I
can
> > > > > revert to a maximum of 4 days.
> > > > >
> > > > > DBbackup and plan file expiration is 4 days, and volume reuse
delay
> > > > > in all stgpools is 0. I want to reuse the tapes immediately.
> > > > >
> > > > > Can anyone enlighten me on this.
> > > > >
> > > > > Regards,
> > > > > Sandra
> > > > >
> > > > >
> > > > >
> > > > >  _____________________________________________________
> > > > >  Sent via SUPERwebmail - Supernet web-based email service
> > > > >  http://www.super.net.pk/mail
> > > >
> > > >
> > >
> > >
> > >  _____________________________________________________
> > >  Sent via SUPERwebmail - Supernet web-based email service
> > >  http://www.super.net.pk/mail
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient.  Any review, 
use, distribution, or disclosure by others is strictly prohibited.  If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.

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