On 03/01/2010 11:29 AM, 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 > > > > > Many here have done this many times. Your risk assessment is acurate. As long as there are no writes pending, the dumps/backups or good. In disaster recovery, a cold backup is preferred over nothing, right? In the dozen or so times when I personally have had to restore broken systems from tape, whether that was Veritas, dump, tar, or cpio, the basics are the same: Re-install the system to base. Recover from tape. Reboot. Pray. If those steps are acceptable, then you are on track. Also, if you are interested in single file recovery, cold backups are actually the best for most things. These days, there are several interesting alternatives to cold backups. The best of those get between the operating system driver and the disk itself. When the first snapshot is triggered, the disk drivers are forced to write to temporary space for the duration of the snapshot, and then the changes are merged back in. From that moment on, the special backup software tags all disk blocks that get modified going forward. When the next snapshot is triggered, not only do the disk writes go to temporary space, but only the tagged blocks are replicated, thus giving a very near perfect incremental backup. As you can guess, this works with raw database partitions as well. Combine that type of snapshot with a memory dump of the system at the moment the snapshot is triggered, and you can migrate the system to any point in time a snapshot was performed. Move those critical applications to Virtual Machines, and you can 'live migrate' a system back to any point in time when a ' pause VM/memory dump/snapshot' occurred. Neat stuff! I give these examples only to show the progress in general from the cold backups of yesteryear to what is available and in use today. 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
