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@xxxxxxxxx> To: Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx> Date sent: Mon, 01 Mar 2010 16:48:53 -0600 Send reply to: Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx> <mailto:users- request@xxxxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe> <mailto:users- request@xxxxxxxxxxxxxxxxxxxxxxx?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@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxx mailto:msetzerii@xxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
