Re: [PLUG] RAID Backup Server

"William H. Magill" <magill@mcgillsociety.org> · Tue, 1 Nov 2005 10:46:41 -0500

On 01 Nov, 2005, at 08:04, Edmund Goppelt intoned:

On Mon, Oct 31, 2005 at 11:52:56PM -0500, William H. Magill wrote:
Backup of individual files is solely for their recovery in case of
deletion.
Backup of a "System" requires that you be capable of restoring the
SYSTEM to working order as of when the last backup was taken. A
System is composed of many files.

I'm not sure I understand your point here. Are you saying that it's
impossible to do a bare metal restore using individual files? If you
are, that's not been my experience (see below).

Not at all. It's just an issue of time.
Nominally, "bear-metal" refers to restoring the OS structure only.
Application restore may or may not be included.
However, "bare-metal" restores themselves come in different sizes and
shapes. A "ghosted" image restores faster than a complete rebuild and
configure from "source" media (no, not necessarily recompiling).
A restore to an OS release that is 2 or 3 levels behind is different
than restoring to latest updates. ... lots of variables.
And if you're not dealing with files, what units of storage are you
dealing with? Partitions?

Minimally, yes. Rather, "the contents of storage devices," independent
of any particular format.
Back in the days of VMS (DEC's proprietary system), DEC's backup 
software

allowed one to make a "disk image backup." This "disk image" was used

to do bear-metal restores. All that was required was that the disk be

prepped with labels, no formatting was necessary as the restore would

reconstruct whatever format was on the image.

[OS X has a similar capability, called a "disk image" which 
theoretically

could be used in a backup script to accomplish the same thing. I think.

However, "ghosting" of PC systems is probably the most common

version around today.]
DEC's "volume level" restoration always operated at the write speed of
the disk as it took place without the necessity of creating each and
every individual file's catalog entry. The process was much faster
than restoring by individual file. ("Obviously," the number of writes
to create and update the catalog entry is more than the number of
writes needed to restore the file alone.)
As I recall you used to work for Penn which has lots of
resources--both money and people. I'm in a different situation: it's
just me and I have to watch every penny.

Correct, almost 30 years in both the Engineering School and the
Vice Provost for Computing's organization.
I realize you may not be used to working under such constraints, but
I'd love to hear your thoughts. How do you think I should go about
backing up my 8 or so systems?

That was the point of Mark's list of questions.
Your solution may be quite optimal for your situation.
Without going through the exercise, you won't know.
One must completely ignore the possible cost until the scope of
the problem is outlined and potential solutions defined.
Once the scope of the problem, i.e. goals to accomplish, is defined,
those goals must be prioritized. If recovery of accidentally
deleted files is the highest priority, if Archival Storage of
customer data is highest, if protection against catastrophic System
failure is the highest, if minimizing down-time is highest -- so be it.
Once that list of priorities is defined, one looks at potential 
solutions,

again ignoring the cost.
Once various potential solutions are defined, you determine which of 
those

solutions meets the most important of your goals... THEN you cost it 
out.
If costs are a significant constraint, then you know immediately what
your "chosen solution" will actually accomplish, and what it will not.
Keep in mind that this is an iterative process. Once the proposed 
solution

is costed out and you have to start deleting from your prioritized list,

you have to return to the exercise of determining your priorities. Are

your original requirements more important than the reduced list?
But in the end, you will know just what your solution will accomplish
and what it will "cost" in terms of unfilled requirements.
There is no such thing as a "one size fits all" backup solution.
Every enterprise defines its own "scope." Every solution has pros and 
cons.
You often wind up trading off minimizing downtime for Archival Storage
capabilities. Tape is STILL the cheapest Archival media, but it SLOW.
"Bricks" (removable disks) can replace tape, but they are expensive.
... etc. [Note, that the cost of tape vs disk for archival storage
is really only existent in the small-to-medium "size" market. Once you
get to a certain size, the inability of tape to restore in a timely
fashion clearly outweighs its cost benefits. In the "large" market,
tape is virtually unusable for a multitude of reasons, not the least
of which is the simple "capacity of the tape" issue.]
If you were a financial oriented enterprise, where the cost of minutes
of downtime were measured in thousands of dollars, the fact that is
going to take 30 minutes to do a bear-metal restore, can easily be
costed out as 30,000ドル! A substantial budget one can use for replicating
systems and keeping them around as "hot standbys," even if they are not
used for months or years at a time!
The primary issue is -- how long is it going to take you to return
things to the way they were "before" you lost the system? A 1-TB
data store takes A LONG TIME to restore!

This has not been my experience. It took me about 4 hours to do a
bare metal restore of my main web/database server recently.
The 1 TB refers to the storage capacity available for backups. Most
of my systems use less than 80GB.

Right. I was talking about how long it DOES take to restore a 1-TB
"system."
"What happens when the architect gets hit by a bus?"

At this point, backups become somebody else's problem.

Only true for the proprietorship case.
If it's a partnership, it falls to the partner.
If its a corporation, it falls to the rest of the IT organization.
"Somebody else" can be a significant problem.
Business continuation ability is a big question.
Small businesses are at particular risk because they operate either
as a proprietorship or a partnership where one partner does one thing,
while the other does something else.

T.T.F.N.
William H. Magill
# Beige G3 [Rev A motherboard - 300 MHz 768 Meg] OS X 10.2.8
# Flat-panel iMac (2.1) [800MHz - Super Drive - 768 Meg] OS X 10.4.1
# PWS433a [Alpha 21164 Rev 7.2 (EV56)- 64 Meg] Tru64 5.1a
# XP1000 [Alpha 21264-3 (EV6) - 256 meg] FreeBSD 5.3
# XP1000 [Alpha 21264-A (EV 6.7) - 384 meg] FreeBSD 5.3
magill@mcgillsociety.org
magill@acm.org
magill@mac.com
whmagill@gmail.com

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug 