ADSM-L

Re: progressive backup vs. full + incremental

2003-03-06 22:59:59
Subject: Re: progressive backup vs. full + incremental
From: DFrance <DFrance-TSM AT ATT DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 6 Mar 2003 12:01:01 -0800
To (briefly?) summarize... (the first two bullets address your original query):

- With TSM, all the active AND inactive versions are (a) always in the silo, 
(b) only sent across the network ONCE (if you use the progressive-incremental 
the way it was intended)... extra copies of the same "version" are created via 
copy pools and/or backupsets and/or image backups.  

- TSM's database is used to retrieve *only* the versions of files being 
requested, automatically taking into account all the modifiers used (eg, 
point-in-time, replace=y/n, etc.). TSM is designed as a "lights-out" 
application -- no need to attend to the daily/weekly/monthly tape rotations; 
more simply, use MOVE DRMedia (at the operator's convenience, notwithstanding 
your site's offsite-vaulting policy for extra copies) to control tapes moving 
to offsite vault and back (to scratch).

- the old G-F-S (grandfather-father-son) of mainframe days involved periodic 
FULL backups, typically every weekend; this technique consumes huge amounts of 
both (a) band-width (every new FULL goes across the network), and (b) tapes, 
just for primary copies (most sites have no time left to create a 2nd copy, so 
they're totally exposed to restore failure if that only volume fails for any 
reason!)

- FULL+Incremental mentality of Legato & Veritas is, unremarkably, similar to 
G-F-S -- its main benefit is that it's easy to understand and implement (if you 
are NOT the operator trying to track down the tapes!);  to recover any given 
file-system requires (a) retrieve the latest FULL, then (b) retrieve all 
subsequent INCRementals --- that can be alot of extra traffic, not to mention 
the tricks needed to avoid "losing" any files created and deleted within the 
same week AND you must know where the tapes are and get them loaded.  BTW, if 
any tape in the series goes bad, the data on that tape could be lost forever -- 
unless the file's age is such that some previous FULL or INCRemental captured 
it!

HTH!

Don France
Technical Architect -- Tivoli Certified Consultant
Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390
San Jose, Ca
(408) 257-3037
mailto:don_france AT ayett DOT net (change aye to a for replies)

Professional Association of Contract Employees 
(P.A.C.E. -- www.pacepros.com)



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Joni Moyer
Sent: Wednesday, March 05, 2003 6:21 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: progressive backup vs. full + incremental


Hello everyone!

I was wondering why the full + incremental would result in a longer restore
time than the progressive backup methodology?  From several co-workers
point of view they thought that it would be quicker on the full +
incremental because you wouldn't have to go back to the beginning backups
of the file and restore all of the incrementals, you would just go back to
the most recent full backup and apply the incrementals after that point.
When I went to explain the reasoning behind this, I had some problems
understanding the concept myself, so I was hoping someone could explain
both methods and why they differ in restore time and why progressive is
better than the full + incremental.  Thank you so much for any help you can
lend on this matter!



Joni Moyer
Systems Programmer
joni.moyer AT highmark DOT com
(717)975-8338