Menu
▾
▴
Re: [Dump-users] Unable to handle removed files via incremental dumps
|
From: Stelian P. <st...@po...> - 2004-02-05 15:58:39
|
On Thu, Feb 05, 2004 at 05:43:19PM +0200, Delian Krustev wrote:
> On Thursday 05 February 2004 12:48, Stelian Pop wrote:
> > You have to restore the level 0 dump every time too. Remember, level 1
> > dumps contain the differences between the 0-level dump and the 1-level
> > dump, so you will have to do something like:
> > dump 0uf /tmp/0-level.dump /fs
> > dump 1uf /tmp/1-level.dump /fs
> > ...
> > cd /mynewfs
> > restore rf /tmp/0-level.dump
> > restore rf /tmp/1-level.dump
> > ...
> > dump 1uf /tmp/1-level.dump /fs
> > ...
> > cd /mynewfs
> > rm -rf *
> > restore rf /tmp/0-level.dump
> > restore rf /tmp/1-level.dump
> > ...
> > etc...
> >
>
> I don't want to restore level 0 dump each time. It will be terribly
> slow. I prefer dumping from levels 0-9 in this case. This way I'll
> dump/restore level 0 only once on every 10 backups.
Indeed, it is better to use levels 0-9 in this case.
> What does the restoresymtable contain. Isn't it the info for inodes
> which have already been restored ? I've tried restoring only level one
> dumps, one after another and it seemed to work just fine.
It will be used in order to detect renames/deletions etc.
> >
> > dump version ? kernel version ?
> >
>
> dump-0.4b27-3 - from rh7.3
You need to update it, as you tried below.
> kernel 2.4.24 with patches from sistina, needed for snapshotting ext3
>
> > Try separating the two steps in order to see who exactly is failing
> > (dump or restore):
> > dump -0uf - /dev/vg1/snaphome > /dev/null
> > first, then:
> > dump -0uf - /dev/vg1/snaphome |restore -rufdv -
> > (note the addition of (d)ebug and (v)erbose flag).
> >
>
> I'll do that. First I would like to upgrade dump/e2fsprogs to the latest
> versions. I've succeeded with e2fsprogs{,-devel} 1.34. However dump-0.4b35 gives
> me a compilation error:
>
> make[1]: Entering directory `/usr/src/redhat/BUILD/dump-0.4b35/dump'
> i386-redhat-linux-gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -O2 -march=i386 -mcpu=i686 -pipe -I.. -I../compat/include -I../dump -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b35\" main.c -o main.o
> In file included from /usr/include/linux/types.h:5,
> from /usr/include/linux/fs.h:13,
> from main.c:69:
> /usr/include/asm/types.h:11: warning: redefinition of `__s8'
> /usr/include/ext2fs/ext2_types.h:11: warning: `__s8' previously declared here
> /usr/include/asm/types.h:12: warning: redefinition of `__u8'
> /usr/include/ext2fs/ext2_types.h:10: warning: `__u8' previously declared here
> /usr/include/asm/types.h:14: warning: redefinition of `__s16'
> /usr/include/ext2fs/ext2_types.h:37: warning: `__s16' previously declared here
> /usr/include/asm/types.h:15: warning: redefinition of `__u16'
> /usr/include/ext2fs/ext2_types.h:38: warning: `__u16' previously declared here
> /usr/include/asm/types.h:17: warning: redefinition of `__s32'
> /usr/include/ext2fs/ext2_types.h:45: warning: `__s32' previously declared here
> /usr/include/asm/types.h:18: warning: redefinition of `__u32'
> /usr/include/ext2fs/ext2_types.h:46: warning: `__u32' previously declared here
> /usr/include/asm/types.h:21: warning: redefinition of `__s64'
> /usr/include/ext2fs/ext2_types.h:23: warning: `__s64' previously declared here
> /usr/include/asm/types.h:22: warning: redefinition of `__u64'
> /usr/include/ext2fs/ext2_types.h:27: warning: `__u64' previously declared here
> main.c: In function `do_exclude_ino':
> main.c:1285: parse error before `unsigned'
> main.c:1286: `j' undeclared (first use in this function)
> main.c:1286: (Each undeclared identifier is reported only once
> main.c:1286: for each function it appears in.)
> make[1]: *** [main.o] Error 1
> make[1]: Leaving directory `/usr/src/redhat/BUILD/dump-0.4b35/dump'
> make: *** [all] Error 1
>
> I've looked at the source of main.c and I'm seeing variable definitions
> in the middle of a function, which I think is not an ANSI C (main.c not
> main.cpp) ..
Yup, known problem:
http://cvs.sourceforge.net/viewcvs.py/dump/dump/dump/main.c?r1=1.88&r2=1.89
Stelian.
--
Stelian Pop <st...@po...>
|
