[clug] Linux Backups: dump vs ...
michael.cohen at netspeed.com.au
Sun Apr 24 01:08:11 GMT 2005
rsync is not backup, because it does not provide a multi-level
recovery facility. So if you delete your important files just before
an rsync run, you also lose them from backup. A real backup solution
allows incremental backups to provide the ability to go back to
In my experience tape is a really poor medium for backup. Mostly
because its generally impossible to tell if the tape has error unless
you actually try to restore it - which is often far too late. Tape is
poor for long term storage as well due to it being susceptible to
magentic interferance - hdds have a magnetic shield around them which
provides some protection.
Mirroring is a poor choice also because the two disks share the same
machine and bus - if a lightning bolt hits your computer both disks
are likely to die together. This also have the same limitations as
before - no multilevel backups etc.
Best solution IMHO is a backup server with dedicated backup software
(Plenty of good backup software around - apt-cache search backup)
running periodic checksumming on the files to detect corruption early.
Short of this an external USB/FW hdd with proper backup software is
also a good solution which is quite cheap too.
On Sun, Apr 24, 2005 at 10:49:49AM +1000, Kim Holburn wrote:
> It's really a question of resources. For a home system, it is much
> cheaper to buy some extra disks and rsync maybe with the --backup
> option to catch deletions. If you are running a business/organisation
> then you might consider it necessary to backup to tape since disks
> aren't archival material (you can't leave them powered off for any
> length of time and you definitely can't drop them). Tape is overall
> much more expensive than disk but it is much more likely to last. The
> other thing you might try is mirroring the system disks. I have got
> very variable results with dd.
> I have a colleague who reckons bacula <http://www.bacula.org/> is good.
> We'll see.
> On 2005 Apr 20, , at 3:19 PM, Stephen Granger wrote:
> >I've been looking into some disaster recovery/backup options for our
> >redhat servers and dump was our first choice. However it seems that
> >maynot be the best solution on an ext(?) filesystem according to this
> >post below. Do other's share this opinion on dump? I've always found it
> >highly regarded on other unix's. This post is from a couple of years
> >on an early 2.4 kernel, maybe things have been improved upon?
> >I'm thinking a process of using kickstart and restoring from tars is
> >best way to rebuild a Redhat machine in under 30 mins. Any other
> >options? I prefer not to consider norton's ghost seems a bit too evil.
> >188.8.131.52. dump/restore: Not Recommended!
> >The dump and restore programs are Linux equivalents to the UNIX
> >of the same name. As such, many system administrators with UNIX
> >experience may feel that dump and restore are viable candidates for a
> >good backup program under Red Hat Linux. Unfortunately, the design of
> >the Linux kernel has moved ahead of dump's design. Here is Linus
> >Torvald's comment on the subject:
> >(the original thread)
> >From: Linus Torvalds
> >To: Neil Conway
> >Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
> >Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
> >Cc: Kernel Mailing List <linux-kernel At vger Dot kernel Dot org>
> >[ linux-kernel added back as a cc ]
> >On Fri, 27 Apr 2001, Neil Conway wrote:
> >>I'm surprised that dump is deprecated (by you at least ;-)). What
> >>to use instead for backups on machines that can't umount disks
> >Note that dump simply won't work reliably at all even in 2.4.x: the
> >buffer cache and the page cache (where all the actual data is) are not
> >coherent. This is only going to get even worse in 2.5.x, when the
> >directories are moved into the page cache as well.
> >So anybody who depends on "dump" getting backups right is already
> >playing Russian roulette with their backups. It's not at all
> >to get the right results - you may end up having stale data in the
> >buffer cache that ends up being "backed up".
> >Dump was a stupid program in the first place. Leave it behind.
> >>I've always thought "tar" was a bit undesirable (updates atimes or
> >>ctimes for example).
> >Right now, the cpio/tar/xxx solutions are definitely the best ones, and
> >will work on multiple filesystems (another limitation of "dump").
> >Whatever problems they have, they are still better than the
> >_guaranteed_(*) data corruptions of "dump".
> >However, it may be that in the long run it would be advantageous to
> >a "filesystem maintenance interface" for doing things like backups and
> > Linus
> >(*) Dump may work fine for you a thousand times. But it _will_ fail
> >under the right circumstances. And there is nothing you can do about
> >Given this problem, the use of dump/restore is strongly discouraged.
> >This post mentions a few solutions
> >For DR there is also
> >http://www.mondorescue.org/ it made it into this list
> >and then there is this one
> >Here's a tool to build a complete linux system in under 15 minutes
> >Oh... just for Debian :) though it does mention Kickstart for redhat.
> >Mr IBM doesn't mention too many down falls against dump
> >though mentions it's only good for ext2, ext3... the slow/poor
> >performing standard file systems that we are running. If we were to
> >switch to Reiserfs we couldn't use dump.
> >My favourite quote
> >"Go forth and back up"
> >linux mailing list
> >linux at lists.samba.org
> Kim Holburn
> Network Manager, National ICT Australia Ltd.
> Ph: +61 2 61258620 M: +61 417820641 F: +61 2 6230 6121 aim://kimholburn
> Email: kim.holburn at anu.edu.au - PGP Public Key on request
> Cacert Root Cert: http://www.cacert.org/index.php?id=16 ->
> Aust. Spam Act: To stop receiving mail from me: reply and let me know.
> Use ISO 8601 dates [YYYY-MM-DD]
> Democracy imposed from without is the severest form of tyranny.
> -- Lloyd Biggle, Jr. Analog, Apr 1961
> linux mailing list
> linux at lists.samba.org
More information about the linux