[clug] Linux Backups: dump vs ...

Sun Apr 24 00:49:49 GMT 2005

Actually if you read the original dump/ufsdump on solaris man pages  
carefully, they mentioned that to get consistent results you have to  
unmount the volume you were dumping.  Nobody ever did that AFAIK but  
rarely it would stuff up because the disk was still mounted.  The nice  
thing was the restore -i command which is what you don't get with tar,  
not to mention the solaris tar was severely broken.

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