Re: [Dump-users] Unable to handle removed files via incremental dumps

[Delian K. <kr...@kr...>]

On Friday 30 January 2004 17:05, Florian Zumbiehl wrote:
> Hi,
>
> > sync
> > dump -0 -f - /dev/hda1 -A archive_file |restore  -uvxf -
> > date "+%a %b %e %H:%M:%S %Y" > last_dump
> >
> > Later I'm doing a level 1 dump and writing over the level 0 dump
> > files:
> > dump -1 -T "`cat last_dump`" -f - /dev/hda1 -A archive_file.new \
> >
> >         |restore  -uvxf -
>
> [files deleted on the source are not deleted on the mirror in that
>  second step above]
>
> > Unfortunately the archive_file.new, created during the level 1 dump
> > contains only the added/changed files and nothing about the removed o=
nes.
> > It will be
>
> It _does_ contain information about the removed ones - though indirectl=
y.
> Dump is not about backing up files (=3Ddirectory entries and their asso=
ciated
> data) but about backing up inodes. By dumping all changed inodes (inclu=
ding
> directories) relative to some previous backup you automatically also re=
cord
> which inodes from a previous backup are not referenced any longer and t=
hus
> can be deleted upon restore of the incremental backup.
>
> The problem here is that inode numbers are not preserved by restore, wh=
ich
> is why restoring an incremental backup on top of a filesystem that was
> filled by other means than by restoring a level 0 dump does not work -
> incremental restore only works because restore keeps track of correspon=
ding
> inode numbers in /restoresymtable on the filesystem being restored.
>
> This is how I understand it - if I should be wrong, please correct me .=
=2E.
>
> So, after all it should work if you initially create the mirror using
> dump -0 | restore.

Probably You mean restore -r here.
I've tried that. You're right. It works. However the documentation states
that -r should  be used only on a fresh filesystem. Isn't it dangerous
if it's used on already populated one ?

Here's what I've done:
step1:
dump -0uf - /dev/hda1 |restore  -ruf -

step2:
dump -1uf - /dev/hda1 |restore  -ruf -
- edit the contents of /etc/dumpdates and delete the line for level 0 dum=
p
on hda1 and make the line for level 1 to be the line for level 0
- delete a file
dump -1uf - /dev/hda1 |restore  -ruf -

Step 2 could be performed multiple times just after itself then.


>
> As an alternative to dump I'd recommend rsync which is made exactly for
> this kind of task. However, take care to disable checksumming for
> local copying - maybe that rsync does that automatically, though ...
>

I'm currently using rsync. However even
find . |wc -l
takes huge amount of time when we talk about let's say one million files.
Find/rsync uses stat for each file. I'm not sure whether the kernel keeps
a copy of the FAT(don't know how it's called for ext2/3) in memory, but
even in that case the context switches between the kernel and userspace f=
or
each stat seems expensive and unnecessary, when we could read that inform=
ation
directly from the FAT. That's what dump does, right ?

> Cyas, Florian
>

Thanks for the response,
Delian Krustev