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
> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
|
