[EMAIL PROTECTED] said:
| I'm in the process of re-initializing Coda after installing new 9GB
| disks on the servers, and upgrading to coda-5.2 with kerberos enabled.
| I made dump files of the volumes I wanted to keep, and attemtped to
| restore them today.
| Since the restore documentation isn't quite clear, (it refers to a
| 'restorevolumes' script, which I couldn't find anywhere), I used
| 'createvol_rep' to create the volume home.troybenj on both servers. I
| then purged the home.troybenj.1 volume on the second server, and
| restored the dump file to a volume named home.troybenj.1 with correct
| ID for the volume I just purged (2000002, I think)
AFAIK backup volumes are read-only volumes without version vectors, and
therefore cannot be used to replace rw-volumes of a replicated group.
I am actually intrigued that it `partially worked' at all. Maybe the
differences are not that big.
Our current recovery strategy is as follows:
** When still having part of a replicated group.
Get the following information about all lost replicas, from /vice/vol/
BigVolumelist and /vice/vol/VRList.
volumename (with the correct .n extension)
groupid (aka. the replicated volume id from the VRList)
rw-volid (rw-volume id, the underlying read-write volume id,
second column in BigVolumeList, strip the initial 'I')
Reinitialize the lost server, start the server and when it writes
`fileserver started' to the log, isolate it using
'filcon isolate -s <server>'
Recreate all volumes using 'volutil create_rep', using the previously
gathered information for the arguments.
Remove the isolation 'filcon clear -s <server>'.
Using a client, resolve the missing files back to the reinitialized
server.
---
As you can see we normally leave at least one server of a replicated
group in the `old state'. Do a full resolve, and then upgrade the last
server.
** When all replicas are lost.
Here we need to go to the backup tapes. After (re)initializing the
servers, and creating empty volumes. We restore the backup into a
new volume and mount it in the Coda tree.
Then using f.i. cpio, we copy the data from the readonly backup volume
into the new replicated volume.
Last time I used the following script to copy all files and mountpoints
from a (subtree) of one volume into a new volume. It doesn't handle ACLs.
=========================================================
#!/bin/sh
newvolume=/coda/project/releases
echo "Copying files from $PWD to $newvolume"
volmunge -f . | cpio -pVmd $newvolume
echo "Moving mountpoints from $PWD to $newvolume"
for mtpt in `volmunge -m .`
do
volname=`cfs lv $mtpt | grep named | sed 's/.*"\(.*\)"$/\1/'`
echo $volname
# cfs rmm $mtpt
cfs mkm $newvolume/$mtpt $volname
done
=========================================================
But it could be that you don't need the mountpoints step when coming
from a backup volume, they are not traversed, and show up as
`copy-able symlinks'.
Jan
