unattended disk clone

[Adrian Wontroba]

On Fri, Nov 03, 2006 at 12:04:32AM +0000, Chris Whitehouse wrote:
> >This fragment from a make file (don't ask!) works without asking
> >questions:
> >dump -L -C 32 -0 -f- $$f | (cd /mnt$$f; restore -r -f- ) ; \
> 
> What does $$f do? $$ is the pid of the invoked shell from man sh(1).

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.

> and similar for /var, /tmp, /usr, which has worked completely reliably 
> 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

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.

Another sign of snapshots "working" is that there are filesystem size
dependent pauses at the beginning and end of dump. On big filesystems
creating or deleting a snapshot takes a long time.

Does "background feck" work? That too is dependent upon snapshots.

> Am I still missing something? Otherwise I either have to live with not 
> quite automatic or warning messages. I will probably opt for the former, 
> or maybe try rsync.

I think I'd go for full automation, preferably without warnings.

Rsync might be faster - copying just the changed (bits of) files.

-- 
Adrian Wontroba
samba: v "to rub navels"