Hmm Thanks Alot Andy,
All that description cleared lots of things.
There is one little question/confusion.
If my 1st DB backup expires on 4th day, its only that DB tape that would return
to vault-retrieve and not the corresponding data tapes since these data tapes
contain data that is refered to by the 2nd db backup. NOW the problem starts
where I have to keep sending data tapes daily and there is most likely never
returning data tapes. Am I right? So my question that on 5th day would backup
stgpool command take full backup of my primary pool so that those earlier tapes
would start to come back to main site??
Sorry for these dumb questions.. but after going through the documentation it
was my understanding that things would behave like that.. but i came across
this incremental backup thing for copypool and brought all the confusions in.
Kind Regards
sandra
---- storman AT US.IBM DOT COM wrote :
> 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
>
>
_____________________________________________________
Sent via SUPERwebmail - Supernet web-based email service
http://www.super.net.pk/mail
|
