FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 03-01-2010, 10:30 PM
"Michael D. Setzer II"
 
Default Which backup program should one use? Was Risks of backing up live mounted filesystems using dump(8)

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@gmail.com>
To: Community support for Fedora users
<users@lists.fedoraproject.org>
Date sent: Mon, 01 Mar 2010 16:48:53 -0600
Send reply to: Community support for Fedora users
<users@lists.fedoraproject.org>
<mailto:users-
request@lists.fedoraproject.org?subject=unsubscrib e>
<mailto:users-
request@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@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@kuentos.guam.net
mailto:msetzerii@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@HOME CREDITS
SETI 9,438,278.717995 | EINSTEIN 3,804,397.610851
ROSETTA 1,730,768.607714 | ABC 193,314.385493

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

Thread Tools




All times are GMT. The time now is 03:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org