Re: Advice on external backup of a Linux server.

• Previous message: Gill, Jack: "Repartition Hard Drive?"
• Maybe in reply to: Arthur Pemberton: "Advice on external backup of a Linux server."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 10 Feb 2005 12:47:35 -0800
To: fedora-list@redhat.com

Arthur Pemberton <dalive@flashmail.com> writes
>
> I'd like to pull on the collective here in posing this question. What's
> the best solution for an unattended backup medium for a Linux server? I
> was looking at a USB externall HDD - but seems to me that the HDD would
> have to be turned on for the backup to done. I also looked at a Network
> Attached Storage (NAS) solution, but these started at $250.
>
> Any on the cheap ideas compatible with FC3?

rsnapshot is an interesting alternative.

Backuppc has been mentioned. The upside is that users can restore their
files from a web page. The downside is that, potentially, so can the
bad guys. It is not safe to have a backup "server" actually service
externally initiated internet requests, and users that need files
restored often made other mistakes needing correction, too. The backup
server should ssh/rsync outbound to clients and pull data. When restores
are needed, a sysadmin should push restored files back to the client.
If you are rotating backup drives into a fire-resistant safe, you
cannot automate the restore process completely.

Note that 2.6.x kernels are missing the IDE hotswap features Alan Cox
put in the later 2.4.x kernels. If you want to use cheap IDE drives
in swap cages, you should check out my notes on Linux backup at
http://www.keithl.com/linuxbackup.html .

Single file restores from a rsync-style archive are easy, even if they
are not driven by a GUI. The actual restore is by itself is a small
interruption to a system administrator's schedule. The time needed
for moving files is dwarfed by the time the sysadmin needs to spend
figuring out *why* the file was deleted, and what the consequences are
of restoring it. Often, the need for a restore is indicative of a
larger problem, and you should treat the cause and not just the symptom.
Human judgment, and perhaps some user training, is often needed.

I manage another open-source alternative, "dirvish", originally written
by jw schultz. See http://www.dirvish.org for more info, including
pointers to a three part series in Sys Admin magazine about dirvish,
finishing up in this month's March 2005 issue.

My focus is on full automation of daily (or more often) backups,
security, and whole-system recovery. While restoring files for users
eats up time, whole-system recovery can cause enormous unscheduled
downtime and business interruption. This is the part that should
be highly automated, prepared in advance, and reliable; the sysadmin
should have the tools necessary to evaluate the damage, choose a
recovery alternative, and quickly rebuild a drive or a system.
While we are just starting down that road, you should join us if
the destination interests you.

Keith

-- 
Keith Lofstrom          keithl@keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

• Previous message: Gill, Jack: "Repartition Hard Drive?"
• Maybe in reply to: Arthur Pemberton: "Advice on external backup of a Linux server."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]