ADSM-L

Re: AW: Incremental Forever

2015-10-04 17:30:26
Subject: Re: AW: Incremental Forever
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
To: ADSM-L AT VM.MARIST DOT EDU
Salak,

I'll be interested in the offline discussion that you and Alan are
conducting.  In the meantime, I would like to point out a couple of things
from your dissertation for the rest of our audience.  For those of you in a
hurry, don't read this.

What you presented is factual.  However, the truths apply to particular
situations, not the general case.  Your statement is that the restore speeds
are faster in a full/incremental scheme than in an incremental forever
scheme.  I'll come back to that.

*SM is optimized for file restores, where it excels above the other
enterprise backup products.  It does an acceptable job of volume restores in
most cases (there are degenerate cases where it is poor), and an excellent
job with a bit of tuning.  It does a superb job of organizing for disaster
recovery, and an acceptable job of speed in disaster recovery in most
situations.  It does an excellent job of archiving.

It your needs are outside of the above scenario, you should use another
product.

Why are file restores the most important consideration?  In the 70s, we had
removable disk packs.  When a removable pack failed, the operator put in the
backup removable pack and crashed that one, too, so we were doing full disk
restores from tape all the time.  In the 80s, Winchester drives took over,
but were unreliable.  We had problems - like glue coming off the filters and
crashing drives - so we did lots of full volume restores.

In the 90s, we achieved phenomenal reliability with disks.  We also added
hardware mirroring and RAID to increase the reliability.  We very seldom
restore entire volumes any more.  We restore files every day, and entire
volumes once every few months.  I speak to hundreds of customers each year,
and this is the general consensus.  I'm quite aware that there are
exceptions, but usually only a few per site.

For the exceptions, *SM allows collocation (which you correctly point out is
not as fast as a full/incremental scheme), collocation by filespace (which
can provide for much quicker restores of an entire server with many
filespaces) and now, backup sets (which are just as fast as
full/incremental, and can be performed by a client without server
involvement).

The exceptions to file restore, however, are normally databases, not
end-user filespaces.  Databases backups require an entirely different
approach.  They have an entirely separate backup, usually based on
full/incremental internal scheme, but entirely different than the
full/incremental scheme of this discussion.

Back to your statement - it is absolutely true.  Restoring volumes is faster
in a full/incremental scheme than in a incremental forever scheme
(discounting backup sets).  Let me submit an environment that is even
faster - full forever.  Why don't we do that?  Because we are trading off
resources. But speed of volume restore is most important if you restore
volumes frequently.  If you restore files more often, is it faster to
restore a file from an incremental backup or a full backup?  *SM is
optimized for file restores and it is faster at file restores than the
full/incremental products.  So perhaps the right resource compromise is
incremental forever, with an occasional backup set thrown in where it is
necessary.

Again, you may have an environment that is different than the general case.
But in the general case, *SM is the tool I prefer to use because it provides
me the most flexibility in a very complex, enterprise backup environment.

Let me also say that I enjoyed your description very much.  I've worked with
tape drives for 28 years, and I like visualizing what my backup product does
to the drive.

Bill Smoldt    SSSI
Storage Solutions Specialists, Inc.



<Prev in Thread] Current Thread [Next in Thread>