On Tue, Jun 30, 2009 at 08:45:20PM +0200, Marc Schlinger wrote:
> I'm still going futher in testing coda.
> I'm having trouble on restoring a dump, whereas this morning i didn't  
> have any problems.
...
> Now i try to restore the dump.:
> # volutil restore -f  /tmp/test-F-19h07m20-300609 /vicepa
> V_BindToServer: binding to host igor.alpha.agorabox.org
> ReadDump: Error RPC2_SEFAIL2 (F) in CheckSideEffect
>
> # tail -n2 /vice/srv/SrvLog
> 19:08:48 ReadStuff: ReadDump failed RPC2_SEFAIL3 (F).
> 19:08:48 Error reading dump header; aborted

I generally found that restoring backup volumes isn't as useful as it
may seem. First of all, the restored volume is a non-replicated,
read-only volume without resolution logs, identical to the backup
snapshot that was taken by running volutil backup and there is no way to
tweak the restored volume back to a full read-write replica so you end
up having to copy all the data from the restored backup to a new volume.

It also isn't possible to restore into an existing volume, which is
probably why your restore is failing. When no volume name or id is
specified it tries to use the original backup volume's name and id which
in this case already exist.

I've relied on server replication to handle single server hardware
failures, and only have needed backups to restore occasional files that
users accidentally deleted. For that case it is often much simpler to
just convert the volume dump to a tar archive with codadump2tar and pull
the file from there.

Actually even for restoring a volume piping the dump through
codadump2tar and extracting it into the new replicated volume tends to
be easier than restoring the backup volume and then copying everything.
In both cases the ACLs are the hard part, they are missing in the
codadump2tar case, but most ways of doing the copy from the backup
volume don't copy acls either.

Jan