Risks of backing up live mounted filesystems using dump(8)

[Jeffrey Metcalf]

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