[sf-lug] Backups are important

[Asheesh Laroia]

On Wed, 21 Nov 2007, Rick Moen wrote:

> Quoting Asheesh Laroia (asheesh at asheesh.org):
>
>> It's easy enough to have backup software that says:
>>
>> "In case of emergency on your main drive, where you think your backup
>> drive still works, do these steps:
>>
>> 1. Plug your backup drive into someone else's computer
>> 2. Run our graphical backup tool to browse your bacukps' content
>
> I've frequently been in situations having to do bare-metal (or other)
> restores where that would be not feasible or helpful, or at best would
> slow down the process badly and require additional hardware and software
> that were otherwise not necessary or useful.

I don't know of a situation where both of these are true: 1. The backup 
drive is not damaged, and 2. You cannot read the backup drive with the 
same software that created it on a different computer; given also 3. The 
backup drive is software-wise and hardware-wise compatible with the new 
machine (which is true for e.g. ext3 filesystems stored on USB disks that 
will be read by systems running some modern Linux system on some modern 
PC).

Now sometimes (1) isn't true.  But generally, if (1)+(2) have some chance 
of being true, which yields (3), then you can use the probability that it 
works as part of an expected value calculation.

You would have to install "additional...software" on the someone else's 
computer, in this case TimeVault, it's quite true.  You could do that from 
a live CD, I suppose, and install it to the ramdisk, if you wanted 
to avoid touching the other guy's hard disk.

>> 1. Install Ubuntu on your computer (or new drive)
>
> Wow, I have to install an entire OS and desktop environment just so I
> can do a simple restore?  Are you paying my consulting rate for my extra
> time spent on each such machine (two-hour minimum)?  Are you also going
> to reimburse the other costs of my additional downtime?

You're a professional.  This isn't the right solution for you.  I'm not 
really suggesting it for you.

Here's the thing: WHile it's a two-hour minimum for each machine for you 
to waste time with these GUI backup tools' long dependency chain, it's a 
probably at least a one-month job to teach solid command-line 
understanding to someone lacking the kind of experience we have.  The 
instructions I gave (1. install ubuntu on a blank disk; 2. install a 
package in the repository) are something I can teach to pretty much anyone 
who was already smart enough to click through the backup program's 
dialogs.

So I *am* suggesting it for a different userbase than you: namely, people 
who haven't undergone that long training process that results in grokking 
command-line thingamabobs.  People like my mom, or people still learning 
the ins and outs of command line fun through the SF-LUG group; they 
deserve proper backups, too, after all.  It's always true that restoring 
from a backup will come at some cost; either it was up-front time or money 
to make the backup usable live so that there's no downtime, or it's 
after-the-fact time to restore the backup, or it's after-the-fact money to 
get someone else to, or it's some combination.  That's why I suggest a 
cost-benefit analysis.

>> So Rick, tell me what's wrong with GUIs, then?
>
> This would be an easier question to answer if I held, let alone
> expressed, the view that something is "wrong with GUIs".

Sorry, I mis-stated your claim!  I don't mean to put words into your 
mouth.  I'll be more precise.

What I meant was, what's wrong with *requiring* a GUI for some backup 
tools?  You wrote earlier:

> This is why "I need my backup software to be 100% graphical" is the sure 
> sign of someone who hasn't bothered to think through the restore 
> process.

This is what I disagree with.  Instead, I state the following:

100% graphical backup software can be a good choice even for people who 
have bothered to think through the restore process.

I illustrate this claim with an examples: In the case that the graphical 
restore software has a 90% chance of working, at the cost of just two of 
their own hours the user reduces his expected cost from the disk disaster 
dramatically if they would otherwise have had to spend lots of money on 
experts to do the recovery or time to recreate the data.  (Note further 
that the use of graphical tools do not prevent command-line experts, or if 
necessary hackers of the source code of the graphical tool, from doing the 
recovery.)  In situations like the above, the 100% graphical software can 
lie on the right side of the cost-benefit analysis.

That seems to me to contradict your claim.  However, maybe I'm wrong about 
that; if so, sorry to make a lot of noise for no reason!

>> I'm happy to explain why I'm happy with my remote hard disk + rsync backup
>> setup from other people on the list who are interested in such setups;
>
> rsync is a great tool.  By the way, how many generations of backup do
> you keep, and are they housed in a building distant from the one that
> houses the machine itself?  (You'd feel a little sheepish if the same
> fire, smoke, or water damage, or the same thief, got both at once.)

Every night a backup job runs that backs up the whole filesystem for 
filesystems I care about.  (It uses incremental storage via hard links.) 
Once that completes, the system removes any backups that are more than a 
week old, except if by removing that job the system would remove the last 
existing backup.  This means that during normal system operation I can go 
back as little as a day and as much as a week, and I can always get the 
latest backup if it's older than a week.

As for "distant", the backups of the machine in my parents' basement (in 
Rochester, NY) are stored in Tokyo; the machine in Tokyo is backed up to 
San Francisco; the machine in San Francisco is backed up to somewhere else 
in San Francisco.  (I don't back up already-backed-up data, so there is 
only one live copy + one backup; sorry if the repetition of location names 
doesn't make that clear.)  There are some other smarts that are niceties, 
not necessities, like live hot-syncs of email happening between Rochester 
and Tokyo every minute so that if one machines goes down I can tell my 
parents to point their IMAP client at a different one.

-- Asheesh.

--
Remember the... the... uhh.....