[sf-lug] Backups are important
asheesh at asheesh.org
Wed Nov 21 02:57:04 PST 2007
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
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
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
>> 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
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.
Remember the... the... uhh.....
More information about the sf-lug