| 1 |
Rasmus Andersen wrote: |
| 2 |
> |
| 3 |
> If you do backup live filesystems/data then dump is on par with dd; both |
| 4 |
> read from the underlying device and might bypass the kernel's page cache. |
| 5 |
> Ie., there might be unwritten data cached thats not on disk yet. |
| 6 |
> Tar/rdiff-backup/etc reads through the pagecache and avoids this problem. |
| 7 |
> |
| 8 |
> The dump people talk a bit about this themselves on |
| 9 |
> |
| 10 |
> http://dump.sourceforge.net/isdumpdeprecated.html |
| 11 |
> |
| 12 |
> Note I dont want to dis dump, backing up live filesystems is just tricky |
| 13 |
> (depending on your consistency requirements :) and dump adds another |
| 14 |
> level to that. |
| 15 |
> |
| 16 |
> |
| 17 |
> |
| 18 |
|
| 19 |
Understood - I have seen that article too. I must say, I've mainly had |
| 20 |
experience with 'dump' on Freebsd and 'xfsdump' on Linux, and never had |
| 21 |
restore issues with *either* of these. Now I'm not sure whether these |
| 22 |
are supposed to be better than 'dump' on Linux aimed at ext2|3 |
| 23 |
filesystems - certainly Freebsd's 'dump' has an option to tell it that |
| 24 |
it is dumping a 'live' filesystem, and the man pages for xfsrestore have |
| 25 |
notes concerning what happens when restoring an (xfs)dump from a 'live' |
| 26 |
filesystem - so they may well be! |
| 27 |
|
| 28 |
On the other hand I've certainly routinely seen cases of people using dd |
| 29 |
(rsync, cpio, tar etc) and coming to grief at restore time. I am |
| 30 |
reluctant to suggest that folks use xfs and hence get access to xfsdump, |
| 31 |
as one of the nice things about Linux is the choice of a variety of |
| 32 |
filesystems - but it is pretty important to get able to backup of (for |
| 33 |
instance ) / ... and you usually don't have much option other than doing |
| 34 |
it live! |
| 35 |
|
| 36 |
regards |
| 37 |
|
| 38 |
Mark |
| 39 |
|
| 40 |
-- |
| 41 |
gentoo-user@l.g.o mailing list |
Archives