unattended disk clone
chris at childeric.freeserve.co.uk
Sat Nov 4 00:19:33 GMT 2006
Adrian Wontroba wrote:
> It is a make file - so "$$" has become "$" by the time it is passed to a
> shell. It is part of a loop, with f set to /, /var, /home, etc. Much as
> you are doing.
Ah thanks, makes more sense :P
>> but I have to answer the prompt. I just tried
>> dump 0afL - / | restore rf -
>> and got a message "expected next file 16573, got 8756". I think this is
>> what is referred to in the -L option in dump's man page. I've tried
>> /.snap set to drwxrwx--- 2 root operator which is what the man page
>> says (0770?) and drwxrwxr-x which is what it is set to on an older but
>> untouched system but I still get the same message.
> That message from restore is what you get if a filesystem has changed
> sufficiently under dump's feet. For example, a file which was there
> when directories are being dumped no longer exists by the time dump
> gets round to the file. Which could be a symptom of snapshots not
> working on the filesystems you are dumping. The filesystems are
> UFS2? I believe that UFS2 inodes have 4 time fields, whereas UFS1 inodes
> have 3. fsdb will show you:
> [root at steerpike ~]# fsdb -r /dev/mirror/m1s1d
> ** /dev/mirror/m1s1d (NO WRITE)
> Examining file system `/dev/mirror/m1s1d'
> Last Mounted on /var
> current inode: directory
> I=2 MODE=40755 SIZE=512
> BTIME=Nov 5 04:24:15 2004 [0 nsec]
> MTIME=Oct 22 03:00:05 2006 [0 nsec]
> CTIME=Oct 22 03:00:05 2006 [0 nsec]
> ATIME=Nov 3 00:55:16 2006 [0 nsec]
> OWNER=root GRP=wheel LINKCNT=26 FLAGS=0 BLKCNT=4 GEN=99921a7
> fsdb (inum: 2)> quit
I tried fsdb and I only see the bottom 3. (thanks for the new command
bythe way). I also installed a brand new 6.2-BETA 3, noticing newfs -O2
during the install, and fsdb still only shows the last 3. There's
nothing in man fsdb about btime. Are you running RAID?
> Without snapshots, dumping and restoring a mounted filesystem will
> SOMETIMES provoke the "expected next" message, the only recourse
> for being totally sure being to unmount the filesystem before dumping
> it. Which isn't always easy.
> Does "background feck" work? That too is dependent upon snapshots.
Yep that's working, where feck=fsck :), i just tested it. So it looks
like it is UFS2 and snapshots is working. What about the fact that
running restore with -x never produces the "expected next" message but
so far -r always does?
I'm going to go away and test various combinations of read only/rw
filesystems and -L and -r and -x, options to dump and restore
More information about the Ukfreebsd