Which backup program should one use? Was Re: Risks of backing up live mounted filesystems using dump(8)

Michael D. Setzer II mikes at kuentos.guam.net
Mon Mar 1 23:30:11 UTC 2010



On 1 Mar 2010 at 16:48, Rick Sewill wrote:

Subject:        	Which backup program should one use?  Was Re: Risks 
of backing up
	live mounted filesystems using dump(8)
From:           	Rick Sewill <rsewill at gmail.com>
To:             	Community support for Fedora users 
<users at lists.fedoraproject.org>
Date sent:      	Mon, 01 Mar 2010 16:48:53 -0600
Send reply to:  	Community support for Fedora users 
<users at lists.fedoraproject.org>
	<mailto:users-
request at lists.fedoraproject.org?subject=unsubscribe>
	<mailto:users-
request at lists.fedoraproject.org?subject=subscribe>

> On Mon, 2010-03-01 at 10:29 -0800, Jeffrey Metcalf wrote: 
> > Hi,
> > 
> > I'm hoping I can start a brief thread discussing the potential risks involved with backing up live mounted (RW) ext2/3/4 filesystems using dump(8).  Here are the reasons I ask this:
> > 
> > 1.  My understanding is that it is safest to dump unmounted filesystems to ensure all buffers are flushed and all files on the device are consistent and up-to-date.  However...
> > 2.  Performing filesystem dumps can be a time consuming process and therefore taking the extra time to boot to level 1 and mount / RO to access utilities just adds additional work.  Booting to read-only media with utilities is just as time consuming.
> > 3.  If / is mounted RO, it is not possible to write records to /etc/dumpdates as would occur with /sbin/dump -u.  Obviously one can mount / RW to dump other filesystems, but it still seems awkward and time consuming to have to drop to level 1 anyway, which may be necessary to unmount and dump /home say.
> > 4.  Obviously dropping the runlevel to 1 or booting to RO media such as Fedora Live also prevents anyone other than root from using the system.
> > 
> > Clearly dumping backups of live mounted RW filesystems will not guarantee that file data written between dump passes are completely consistent, but I am looking to better understand the risks.  Clearly databases on filesystems being dumped should be closed and unmounted due to the extra software-level buffering that many databases perform, but if the mounted filesystems are generally idle, are there any gotchas one can expect when restoring such backups.  Also, my filesystems are all ext4 on Fedora Core 12.  Any additional protection that the journaling and journal checksum features can provide in this regard?
> > 
> > Cheers,
> > 
> > -J
> > 
> > 
> > 
> >       
> 
> This question brings up a question that has been bothering me.
> 
> Hopefully, leaving this question on the same thread, but changing 
> the subject line, is the appropriate method to ask my question.
> 
> I've been confused what backup program, dump or tar, to use.
> 
> At first, I was using dump to back up my partitions.
> 
> I switched to using tar after reading 
> http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/admin-primer/s1-disaster-rhlspec.html
> 
> but then I read the following
> http://dump.sourceforge.net/isdumpdeprecated.html
> 
> and now I don't know what to think.
> 
> I'd like to know what backup program, dump or tar, people use and why.
> 
> Please give reasons for your choices.  Please no flame wars.
> If my question starts a flame war, I would ask the moderators 
> to please close/delete the part of the thread I started.
> 
> I feel, which program I use for the backup program,
> doesn't matter if it gets the job done.
> 
> I am interested in hearing the advantages/disadvantages/pitfalls
> of dump vs tar.
> 
> I'd like to decide whether to stay with tar or go back to dump
> after seeing a reasonable discussion on this matter.
> 
> If leaving my question on the same thread, but changing the subject
> is wrong, please do what is appropriate to follow forum conventions.
> 
> 

First, I'm the current maintainer for the free g4l project that does disk 
images, and it is basically a front end that backs up mainly using dd with 
various options of compression and using ftp, cifs, sshfs, and recently nfs 
support. It can backup disk or partitions, but doesn't not do resizing directly.

I have built it using my Fedora systems over the years, and it can be added 
as an option to grub, which makes it easy to run. 

There are also other programs link g4u that do similar things.

Linux.com had a link recently on this.
6 of the Best Free Linux Disk Cloning Software
http://www.linuxlinks.com/article/20100220020013726/DiskCloning.html

The program is on sourceforge, but an even later version with SMP and nfs 
support recently added with newer kernels is at:

ftp://amd64gcc.dyndns.org/g4l-v0.33alpha18.iso

Good Luck. 

> -- 
> users mailing list
> users at lists.fedoraproject.org
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


+----------------------------------------------------------+
  Michael D. Setzer II -  Computer Science Instructor      
  Guam Community College  Computer Center                  
  mailto:mikes at kuentos.guam.net                            
  mailto:msetzerii at gmail.com
  http://www.guam.net/home/mikes
  Guam - Where America's Day Begins                        
+----------------------------------------------------------+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned:  19,471
Processing time:  32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

BOINC at HOME CREDITS
SETI      9,438,278.717995 | EINSTEIN  3,804,397.610851
ROSETTA   1,730,768.607714 | ABC         193,314.385493



More information about the users mailing list