ADSM-L

Re: The "incremental forever" paradigm

1998-03-09 11:21:54
Subject: Re: The "incremental forever" paradigm
From: Tim Dobrowolsky <tim AT CATRS.CAT.CC.MD DOT US>
Date: Mon, 9 Mar 1998 11:21:54 -0500
ADSM is a good product over all.

Sometimes when I'm in a silly mood I'll say:

And on the second day God created ADSM to backup up what He did on the first
day.

Not to imply that IBM is God or anything.


At 08:42 AM 3/9/98 -0600, you wrote:
>        I would have to say I totally agree with Kelly!!  ADSM is a cool
>Product!!
>
>
>Rick Smith
>Maritz, Inc.
>Storage & Security Administration
>smithrr AT maritz DOT com
>(314) 827-1584
>
>> ----------
>> From:         Kelly J. Lipp[SMTP:lipp AT STORSOL DOT COM]
>> Sent:         Saturday, March 07, 1998 2:46 PM
>> To:   ADSM-L AT VM.MARIST DOT EDU
>> Subject:      Re: The "incremental forever" paradigm
>>
>> And when was the last time anyone saw the sorts of disasters we're
>> contemplating in this thread.  We need to worry about this stuff, but
>> not
>> the exclusion of all else.  Yes, some bad things happen at times, but
>> we're
>> talking about five bad things in a row here.  Not many of us are that
>> unlucky.
>>
>> We don't do full disk restores often.  We have mirroring to save us
>> here.
>>
>> We don't have a disaster very often.
>>
>> Two copies of data is enough for anyone.  This means you would have to
>> lose
>> the original, and both copies before you would have a problem.  And
>> then
>> you would only have a problem if you actually needed a copy of the
>> three
>> copies you lost!
>>
>> ADSM with its data protection features is superior to anything you've
>> ever
>> done in the past.  Did you worry about this stuff as much in the past?
>> If
>> you did and you were satisfied, you probably had your head buried in
>> the
>> sand.
>>
>> There were all sorts of assumptions about backups in our previous
>> lives.
>>  Here are some of them:
>>
>> If a file existed on a system overnight, it was on an incremental tape
>> and
>> available for as long as we kept our incremental tapes.
>>
>> If a file existed on a system over a Saturday night, it was on a full
>> tape
>> and available as long as we kept our weekly full backups.
>>
>> If a file existed on a system over a month-end Saturday night, it was
>> on
>> the monthly full and available as long as we kept our monthly backups.
>>
>> If a file existed on a system over a year-end Saturday night, it was
>> on the
>> yearly full and available as long as we kept our yearly backups.
>>
>> Lots of "ifs" in this scenario.  Lots of data too, which is precisely
>> the
>> problem: too much data backed up too often.  Sure, if a file existed a
>> long
>> time we could have many tens of copies of it on tape.  But this isn't
>> a
>> good thing!  Ask the Pharmaceutical and tobacco industry.  Too much
>> data
>> for a lawyer to find is bad data.
>>
>> And the only reason we used the above method in the first place is
>> because
>> the tools we had only worked that way, or were to cumbersome to use
>> otherwise.  Using these tools, imagine an incremental forever
>> methodology.
>>  There was never any possible business requirement that demanded an
>> incremental every night and a full on the weekends.  The "stupid" tool
>> demanded this, not our business requirements!
>>
>> ADSM allows you to define precisely how long to keep information
>> around on
>> backup tapes.  ADSM allows you to define exactly how many copies of
>> data to
>> keep.  ADSM allows you backup only that data you would ever have a
>> requirement to restore. Take the time to decide exactly what your
>> business
>> needs instead of relying on the power of the tool.  ADSM is powerful
>> enough
>> to implement any of your business requirements.  It tends to fail
>> miserably
>> when we ask it to do something that is not a business requirement.
>>  Something like a weekly full backup for instance.
>>
>> Pardon the length and fervor of this message, but ADSM is a cool
>> product
>> and I can't stand to see anyone try to make it act like other less
>> cool
>> products in the marketplace.
>>
>> Kelly
>> What am I doing answering list serve questions on Saturday?
>>
>>
>>
>> -----Original Message-----
>> From:   Tim Dobrowolsky [SMTP:tim AT CATRS.CAT.CC.MD DOT US]
>> Sent:   Friday, March 06, 1998 1:39 PM
>> To:     ADSM-L AT VM.MARIST DOT EDU
>> Subject:        Re: The "incremental forever" paradigm
>>
>> About "incremental forever":
>>
>> For the reasons discussed on this list, I have two onsite copies, and
>> offsite
>> copies as well.  This gives me at least 4 backups depending on the
>> cycle.
>> And, on a regular schedule do old style unix backups for the more
>> important
>> systems.
>>
>> I do this because we don't have the resources to do regular full
>> backups.
>> ADSM helps a great deal in that respect.  The "incremental forever"
>> saves
>> much in the way of resources. Problem is, you have to examine your
>> configuration in excruitiating detail and determine how many failures
>> (big
>> and small) before you've lost data.  Failures can mean ANYTHING!
>>
>> Big things like a 747 lands in your data center, a fire, a flood.
>> Incremental or full doesn't really matter in those situations.  Yeah,
>> so
>> you've got 20 copies of something, but all of'em are on fire - maybe
>> you
>> can
>> sift throught the ashes later and get lucky.  And don't flame me about
>> this,
>> because I'm hiding in the fireproof safe where the tapes were supposed
>> to
>> be. Anyway, this would call
>> for use of offsite backups.
>>
>> Little failures need to concern ADSMers.  The stuff like an operator
>> drops
>> a tape, or it wears out, or the drive eats it.  Whenever this happens
>> to a
>> storage pool you've just lost a cross-section of your data. (in that
>> storage
>> pool)
>>
>> The nice thing I've noticed about reclamation is that it reads your
>> data
>> occasionally and you get the opportunity to find out about tapes that
>> went
>> bad. It's found a couple for me already. I feel this helps offset
>> problems
>> with "incremental forever".
>>
>> Plus if somehow you manage all 4 copies manage to be lost, probably
>> most of
>> the data would still be available, and reconstruction might be
>> possible.
>>
>> Finally, "incremental forever" allows us to backup more in less time.
>> I
>> think I
>> would feel more safe with full backups of every server every night,
>> but....
>>
>> Have a good weekend everyone!
>>
>>
>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>> > Tim Dobrowolsky                   > <                yksloworboD miT
>> <
>> > Computer Services                 > <              secivreS retupmoC
>> <
>> > Catonsville Community College     > <  egelloC ytinummoC ellivsnotaC
>> <
>> > tim AT catrs.cat.cc.md DOT us            > <         su.dm.cc.tac.srtac@mit
>> <
>> > 410-455-4562                      > <                   2654-554-014
>> <
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> Tim Dobrowolsky                   > <                yksloworboD miT <
> Computer Services                 > <              secivreS retupmoC <
> Catonsville Community College     > <  egelloC ytinummoC ellivsnotaC <
> tim AT catrs.cat.cc.md DOT us            > <         su.dm.cc.tac.srtac@mit <
> 410-455-4562                      > <                   2654-554-014 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<