On Tue, Jan 30, 2001 at 01:28:15PM -0500, Stephan Koledin wrote:
> I'm currently having a problem with my nightly backups/dumps. All other
> volumes work fine, but backup seems to be consistently having problems
> with one particular volume:
> 
> 01:30:15 Dumping 7f000009.2000013 to /backup1/30Jan2001/rachael.dorc.foolhq.com-7f000009.2000013 ...
> 01:38:23 WriteDump: Error RPC2_SEFAIL3 (F) in CheckSideEffect

SEFAIL3 is normally to be triggered by diskerrors, more specifically
write to disk errors.

> The one unique characteristic of this volume that comes to mind
> immediately is that I have several .iso images stored here (ie several
> files > 600MB). The cloning process works fine, but it gets stuck on the
> dump as seen above. All other volumes dump properly. Any ideas on why
> this is occuring?

Ok, the total size of the volume dump is then probably larger than 2GB,
so it sounds like either the FS that doesn't handle large files (32bit
limitation), or SFTP is doing something wrong (it might need to use
special 64-bit syscalls such as lseek64 etc.)

> It also looks like VolDump is reporting the wrong volume id  in the
> error messages. For 7f000009.2000013, it reports a failure on 2000014:
> 01:38:23 VolDump (3a06a1b4) failed on 2000014 with Unknown RPC2 return code 200

We never backup the 'live' volume, but rather the read-only clone that
was made. If you do volutil info 0x2000013 it will probably show that
the backup volumeid is 0x2000014.

> On a related note, is there any way to control whether backup dumps all
> copies of replicated volumes? My servers are in sync most of the time,
> so it seems a bit unnecessary to store two identical copies of a volume.
> Perhaps backup could do a check to see if they are both the same, and if
> so, just dump one of them? This would save a lot of storage space,
> especially for large volumes that are pretty static. How do other people
> handle this?

I'm thinking of adding something to block backup from making any calls
to specified servers. That way I can work on debugging alternative
backup tools, i.e. use the regular backup on replicas 1 and 2, but start
backing up the third replica using f.i. Amanda.

Jan