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

[Dave Mitchell]

On Tue, Mar 02, 2010 at 02:40:14PM +1100, Cameron Simpson wrote:
> On 01Mar2010 21:30, Mike McCarty <Mike.McCarty at sbcglobal.net> wrote:
> | Yes, it is. I suspect he meant a files based backup. With
> | dump, what one gets is a dump of the file system itself,
> | as opposed to the data it contains. With a files based
> | backup, one gets a copy of the data saved, but not the
> | file system. So, for example, using tar, or cpio, one can
> | back up a system using ext3, and recover to a system which
> | uses reiserfs. One cannot do that with dump and restore,
> | which store the file system itself. The dump and restore
> | work at a lower level than files based backup.
> 
> I was pretty sure restore pulls "files" from the dump and writes to an
> arbitrary filesystem (eg xfs or reiser etc). Dump accesses the filesystem
> directly, but restore doesn't have that issue.

Yes, you are correct. Furthermore, although dump accesses the raw device
directly (and thus needs to know the specifics of ext*), the output of
dump is *not* tied to the file system format; it is instead a (fairly)
neutral format that consists of a series of records containing first, all
directory information, followed by the data and metadata for each file
being backed up (ordered by inode number). So, a file which is fragmented
and spread out across a disk will appear in the dump output as a single
blob.

Having all the directory info at the start of the dump means that it's
possible to quickly scan a backup to see if it contains the file(s) you're
looking for. restore even has an interactive mode for that purpose.

-- 
But Pity stayed his hand. "It's a pity I've run out of bullets",
he thought. -- "Bored of the Rings"