I dunno from white papers, but I started on ADSM from a hidebound
full/ incremental/ incremental
background (Unix dump levels, for those who've used them)
and it took me a long time to really understand Incrementals Forever. But I
tell you, sisters and brothers, it is the WAY.
Keep in mind that, while full / incremental may be easier to wrap your mind
around, you are unquestionably wasting storage space, bandwidth, client CPU,
and _TIME_.
I'm in a university environment, so I'll take my example from there: Think
about the number of times I'd re-transmit Professor So-And-So's archive of the
electronic copies of all his grad students' theses, all 2GB of them; Every
weekend, I'd send them over the wire. Never mind that he hasn't had a grad
student for 2 years, never mind that the whole directory hasn't been written
to for a year and a half..
In any organization, there is a preponderance of data that just _sits_. You
look up your 1998 notes on invoices to BigBiz.com, and look to see exactly
what you told customer Q the last time he made that stupid request. But you
don't _change_ anything. Why should you write it to tape 52 times a year?
And the Lord help you if you are backing up some poor benighted,
Windows-fettered workgroups C-drives. You could be copying MicroSquish Office
to your server, 23 times, EVERY weekend.
All ADSM is doing is what you would do if you had the time:
Has this changed? Nope, the copy we've got is still good
[ ... ]
Hmm, never seen this before, grab a copy
Has this changed? Nope, the copy we've got is still good
[ ..... ]
Wow, this has changed! Grab another version.
There is simply no technical reason to prefer a full/incremental scheme if you
have the kind of tape management that ADSM (Koff. TSM) (or its peers, I
presume) provides.
Now don't get me wrong, there are certainly political reasons to prefer the
less-efficient scheme, but do keep track of the costs.
Allen S. Rout
NERDC ATDSM admin.
|