[clug] Linux Backups: dump vs ...

Sun Apr 24 01:08:11 GMT 2005

Kim,
  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
  individual states.

  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.

  Michael.

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:
> 
> >Hi
> >
> >I've been looking into some disaster recovery/backup options for our
> >redhat servers and dump was our first choice. However it seems that  
> >dump
> >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  
> >ago
> >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  
> >the
> >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.
> >
> >http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/admin-primer/s1- 
> >disaster-rhlspec.html
> >
> >#########################
> >8.4.2.3. dump/restore: Not Recommended!
> >
> >The dump and restore programs are Linux equivalents to the UNIX  
> >programs
> >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)
> >http://www.uwsg.iu.edu/hypermail/linux/kernel/0104.3/index.html#507
> >
> >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
> >>regularly?
> >
> >
> >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  
> >guaranteed
> >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  
> >have
> >a "filesystem maintenance interface" for doing things like backups and
> >defragmentation..
> >
> >		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  
> >it.
> >
> >Given this problem, the use of dump/restore is strongly discouraged.
> >#########################
> >
> >This post mentions a few solutions
> >https://www.redhat.com/archives/redhat-list/2004-August/msg00464.html
> >
> >For DR there is also
> >http://www.mondorescue.org/  it made it into this list
> >http://www.os-global.com/dr.htm
> >
> >and then there is this one
> >http://www.rsnapshot.org/
> >
> >Here's a tool to build a complete linux system in under 15 minutes
> >http://www.informatik.uni-koeln.de/fai/
> >Oh... just for Debian :) though it does mention Kickstart for redhat.
> >
> >
> >Mr IBM doesn't mention too many down falls against dump
> >http://www-106.ibm.com/developerworks/linux/library/l-roadmap8/
> >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"
> >
> >Steve
> >-- 
> >linux mailing list
> >linux at lists.samba.org
> >https://lists.samba.org/mailman/listinfo/linux
> >
> -- 
> 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   
> callto://kholburn
> Cacert Root Cert: http://www.cacert.org/index.php?id=16 ->  
> http://www.cacert.org/cacert.crt
> Aust. Spam Act: To stop receiving mail from me: reply and let me know.
> 
> Use ISO 8601 dates [YYYY-MM-DD]  
> http://www.saqqara.demon.co.uk/datefmt.htm
> Democracy imposed from without is the severest form of tyranny.
>                           -- Lloyd Biggle, Jr. Analog, Apr 1961
> 
> -- 
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux