Andy,
I'm begining to see the point you made in the earlier post that stated
"I don't think there is any great way to ensure that you can *always* do=
a PIT restore from the GUI unless you have a management class for
directories that basically keeps all versions of directory backups forever
(NOLIMIT= ).
Depending on how often your directories change, this could potentially
impact the size of our TSM database."
Its just very difficult in my environment, because we've made service level
aggreements that say we will retain a certtain number of versions and when
we can't restore them with the GUI, which is what 99.9% of my admins use,
it makes it real difficult. I gues I'll just have to make them command line
experts.
Thanks for your assistance
"Andrew Raibeck" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 04/11/2002 09:21:20
AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Monthly Backups, ...DIRMC
Off-hand, I'm not sure that the problem is directly related to DIRMC per
se, though if you are specifying a management class for DIRMC where
directories could expire before files in those directories expire, this
could be the case.
Here is a link to a prior post I made related to the subject of doing PIT
restores from the GUI:
http://msgs.adsm.org/cgi-bin/get/adsm0103/207.html
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: [EMAIL PROTECTED]
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Jim Healy <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
04/11/2002 04:49
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: Monthly Backups, ...DIRMC
Be careful with dirmc, I'm not sure but I think it might be causing a
problem doing restores from the GUI with point with point in time backups.
Yesterday I was trying to do a point in time restore with a date of march
20 on a specific sub-directory in NT. I Drilled down to the where the
directory should have been displayed and it it wasn't yet when i did a
view
of the files with active and inactive displayed it showed files that would
have been there when the point in time was specifing. I fell back to the
trusty command line with the point in time option and it worked fine.
Beware!
"Don France (TSMnews)" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 04/11/2002
01:48:55 AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Monthly Backups, ...again!: The Real Issues
Bill,
Just out of curiosity, in your restore situation -- was it an NT platform
(I
see it must have been alot of tiny files)?!?
If you are using NT, Netware or AIX as file server platforms, the DIRMC
option pays for itself... BIG TIME. I recently responded to a customer,
clearly a smaller shop, but the storage pool was non-collocated for over a
year, using DLT library in a Win2K-to-Win2K context; there was a total
RAID
failure for the E: drive, but I originally engineered it with DIRMC on
disk,
migrated to FILE on disk, then copy pool'ed to tape. After about 30
hours,
1.6 million files and 316 GB of data were restored to the point-in-time
specified as the last-known-good; this performance was achieved by using
two concurrent restore sessions (across 10 high-level directories),
CLASSIC
restore (not the default), and the "dirsonly" first, then the data -- only
slowdown was due to tape mounts (which were consolidated within each
session), because the customer had more tapes than slots, so needed to
respond to demand mount requests for tapes "mountable not in library".
This experience is usually a wake-up call for the customer to evaluate
RESTORE requirements; if 5-10 GB/Hr is satisfactory, then, so be it. 2GB
restore in 8 hours, did you check your accounting records for media wait
--
and does that reconcile with the time? How about the number of tape
mounts
(available from the summary records or count the approp. message # in the
activity log)??? Sounds abit suspicious, to me.
I've seen several ideas shared in this thread, any one of which could be
the
right answer for a given context; your 3-class system sounds interesting
--
as does Bill Colwell's, and Paul's, and Nick's, and Alex. Also, with 5.1
the new IMAGE backup would seem a good substitute for monthly backupset.
Ultimately, I like Jim Taylor's answer the best... get the dialog on
RESTORE
needs, then figure out what of the various suggestions will work for a
given
customer/server/class-of-servers.
Of course, the key political question is truly to get a dialog on RESTORE
REQUIREMENTS; focus on the business needs for that first, then benchmark
and/or collaborate for possible solutions -- ultimately, the customer
needs
to take this seriously enough to "pay" for trial exercises a couple times
a
year... else, they're just putting their heads in the sand and courting
disappointment.
Regards,
Don France
Technical Architect - Tivoli Certified Consultant
Professional Association of Contract Employees (P.A.C.E.)
San Jose, CA
(408) 257-3037
[EMAIL PROTECTED]
----- Original Message -----
From: "William Rosette" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 10, 2002 6:12 AM
Subject: Re: Monthly Backups, ...again!: The Real Issues
> I enjoy TSM debates, but one that has not sold me yet is this particular
> one. Yes, I come from a different environment (than
Incremental-forever).
> One of the biggest drawbacks of the old ADSM was the abnormal slow
restores
> and this has been notified by a collegue of mine of why his previous job
> did not get ADSM back in the early 90's. My suspicion was this
> Incremental-forever and here I see why. It all relies on the collocate
> issue. If you have numerous tapes and numerous drives than collocate
will
> make Incremental-forever a quck restore. I started with 2 drives 80
> clients and 500 tapes leading to no-collocate. When restoring 2 GB+
> restores that were spread out over 70-100 tapes this took almost 8 hours
> (note this took about 1 year to get to 70-100 tapes). At our DR test we
> noticed a diffence of 6 times a normal restore for no-collocate versus a
> backupset. But on the other hand I brought that restore time down when
> splitting the restore into 5 separate restores for 5 tape drives (I
> currently have 6 drives). So the no-collocate will work if the right
> amount of tape drives are available (our 3570 are pretty expensive). Now
> in the real world you usually have 1-2 tape drives for restores
(dedicated)
> and you cannot afford to send 80 tapes off every night for collocate, so
> what we are gravitating to is a class1, class2, and class3 system.
class1
> will be our DRM critical restore with collocate onsite and offsite,
class2
> our noncritical but high restore class with collocate onsite and
> noncollocate offsite. and then the good class3 with nocollocate onsite
or
> offsite. The monthlys or Absolutes will be used to stop the spreading
of
> info over 70 -100 tapes. It may not be true, but I seem to see the more
> reclamation the more spreading of info. and I would have thought that
the
> reclamation would bring info closer together. All it takes is one time
of
> getting burned with the 70-100 tape restore spread. We have presently
> moved data from one server to another 7 GB and used TSM to do this. If
the
> manual full had not be done the night before (which has happened) then I
> still be restoring as we speak. There are more good things about fulls
> than meets the eye. Now I know not all restores are 2 GB+ but I do see
> more and more and we will all have to deal with it in our own ways. Just
1
> way of dealing with it. Not the only but a way is better than no way.
>
>
>
> "Seay, Paul"
> <seay_pd@NAPTH To: [EMAIL PROTECTED]
> EON.COM> cc:
> Sent by: Subject: Re: Monthly
Backups,
...again!: The Real Issues
> "ADSM: Dist
> Stor Manager"
> <[EMAIL PROTECTED]
> IST.EDU>
>
>
> 04/10/02 01:14
> AM
> Please respond
> to "ADSM: Dist
> Stor Manager"
>
>
>
>
>
>
> 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.
>
> -----Original Message-----
> From: Zlatko Krastev [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 07, 2002 11:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Monthly Backups, ...again!
>
>
> Similar to what I try to explain to customers:
> TSM does only incrementals but at the server they are transpatently
merged.
> So you (I mean the customer) get restore from full backup. This is the
best
> - quick backups and quick restores, no incrementals to apply, no full
> backups to transfer. Just after this start saying "Incremental-forever"
or
> "Progressive Backups" mentioning the benefit.
>
> Zlatko Krastev
> IT Consultant
>
>
>
>
> Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> cc:
>
> Subject: Re: Monthly Backups, ...again!
>
> My current favorite way to explain Progressive Backups - "TSM updates
the
> full backup incrementally." Get that one across, then explain
versioning
> at
> the file level, and you've got them!
>
> Nick Cassimatis
> [EMAIL PROTECTED]
>
> Today is the tomorrow of yesterday.
