ADSM-L

Re: backup stgpool

2005-09-09 12:28:57
Subject: Re: backup stgpool
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 9 Sep 2005 09:28:39 -0700
> 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?

No plans at this time, though we are aware of the issue. If this is
important, consider opening a requirement with IBM. While that does not
guarantee an implementation, it can influence the priority, depending on
how many customers ask for it.

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-09
06:46:26:

> 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>