unattended disk clone

Chris Whitehouse 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 mailing list