ADSM-L

Re: The "incremental forever" paradigm

2015-10-04 18:00:05
Subject: Re: The "incremental forever" paradigm
From: David Hendrix [SMTP:dmhendri AT FEDEX DOT COM]
To: ADSM-L AT VM.MARIST DOT EDU
> >> 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?

Okay, my 2 cents (I was sick Wed-today, so missed this whole thing).

Kelly nailed it.  Don't use ADSM if you are comfortable using a GFS type
product.  It was not designed as such, and although it has it's faults,
we have never been unable to restore a db, file, or system using ADSM.
We have had 3590 tapes break, CE's drop carts, misplace carts, libraries
act very weird causing all carts to go read-only, ADSM DB corruption
(mainly V1 servers) and other miscellaneous "unplanned" random events.
We survived because the product has features to protect itself and the
data you backup.  We use those features.  It is not perfect, but we
would never be able to backup all of our servers every week across the
network.  Hence, for us, it is valid.

Look at what Veritas is trying to do: reduce the amount of data backed
up during incrementals by using block level filesystem backup.  They are
suggesting you host DB partitions in filesystem data to take advantage
of this.  What's the goal?  Reducing the amount of backup data and
network traffic.  They still use Full+incremental so must resort to a
tie in with their filesystem.  The incremental forever paradigm has low
data and network bandwidth as a given.  Why backup something 52 times a
year when it never changes?  If the product can answer that question
adequately, the paradigm is valid.  Maybe not for every situation and
every company, but it certainly is valid.

David Hendrix
dmhendri AT fedex DOT com

(Actually, my one major beef with ADSM is not doing parallel streaming
to tapes.  Allow multiple client streams to one device - only from the
same client - for better utilization of devices.  This would not
interfere with restores or any other process [limit it to collocated
storagepools only].  Almost all vendors now do this.  This is very
important for DB backups.  Jim Reil and I have discussed this, but I
don't think I'll see it my ADSM lifetime.)

--
Carelessly planned projects take three times longer to complete than
Carelessly planned projects take three times longer to complete than
expected.  Carefully planned projects take four times longer to
complete than expected, mostly because the planners expect their
planning to reduce the time it takes.
<Prev in Thread] Current Thread [Next in Thread>