I've run into a frustrating problem that affects only one of my backup clients. This particular client is configured as though it is two hosts to backuppc, such that part of its contents go to a compressed pool and the rest goes to an uncompressed pool. Both of the backups have started failing for reasons that are compeltely eluding me. Here's a slightly-trimmed backup log from one of the failures: (kindly ignore the fact that I'm backing up lame anime videos here...)
[begin log output] full backup started for directory /; updating partial #141 Running: /usr/bin/ssh -c blowfish -q -x -l root <hostname> /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --checksum-seed=32761 --ignore-times . / Xfer PIDs are now 28641 Got remote protocol 29 Negotiated protocol version 28 Checksum caching enabled (checksumSeed = 32761) Sent include: /export Sent include: /export/movies Sent include: /export/Music Sent include: /export/roms Sent exclude: /* Sent exclude: /export/* Xfer PIDs are now 28641,28642 create d 755 0/0 1024 . create d 755 0/0 512 export create d 755 1000/0 16 export/movies <snip> pool 744 101/101 183818240 export/movies/Anime/Aishiteruze Baby/[Lunar] Aishiteru ze Baby - 16 [D32F0AE9].avi pool 744 101/101 183558144 export/movies/Anime/Aishiteruze Baby/[Lunar] Aishiteru ze Baby - 17 [DE935E39].avi pool 744 101/101 183734272 export/movies/Anime/Aishiteruze Baby/[Lunar] Aishiteru ze Baby - 18 [9713D4BC].avi pool 744 101/101 183767040 export/movies/Anime/Aishiteruze Baby/[Lunar] Aishiteru ze Baby - 19 [67A452A4].avi pool 744 101/101 183699456 export/movies/Anime/Aishiteruze Baby/[Lunar] Aishiteru ze Baby - 20 [3A7810A3].avi Read EOF: Connection reset by peer Tried again: got 0 bytes finish: removing in-process file export/movies/Anime/Aishiteruze Baby/[Lunar] Aishiteru ze Baby - 21 [F48F3C55].avi Child is aborting Can't write 33812 bytes to socket Done: 12 files, 918624514 bytes Got fatal error during xfer (aborted by signal=PIPE) Backup aborted by user signal [end log output] I've tried cranking XferLogLevel up to crazy numbers, but the resulting output doesn't include anything that appears to be of interest here. My initial thought was that there must be something wrong with the files I'm trying to back up - maybe there's some crazy IO error happening - but that doesn't seem to be the case. Manually rsyncing the same data over the same network link works fine, and if I move the "Aishiteruze Baby" directory out of the way, the backup transfers some other files (more lame anime vids, naturally) and fails after a similar number of files and bytes transferred. The other backuppc-configured client that points at the host shows similar failures in its XferLog: full backup started for directory /; updating partial #157 Running: /usr/bin/ssh -c blowfish -q -x -l root <same host as above> /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --checksum-seed=32761 --ignore-times . / Xfer PIDs are now 6963 Got remote protocol 29 Negotiated protocol version 28 Checksum caching enabled (checksumSeed = 32761) Sent exclude: /afs Sent exclude: /backup Sent exclude: /mnt <snip> Xfer PIDs are now 6963,7001 create d 755 0/0 1024 . same 600 0/0 3899 .bash_history create d 755 0/0 512 .ssh same 644 0/0 394 .ssh/authorized_keys <snip> create d1777 0/0 8 export/VirtualMachines create d 755 1000/1000 13 export/VirtualMachines/Migrainepad pool 600 1000/1000 239730688 export/VirtualMachines/Migrainepad/Ubuntu-migrainepad-s001.vmdk pool 600 1000/1000 101777408 export/VirtualMachines/Migrainepad/Ubuntu-migrainepad-s002.vmdk Can't write 33792 bytes to socket exiting after signal ALRM Note that this one doesn't print quite the same set of messages - it doesn't print the "Done: ## files, ###### bytes" line. I'm at a loss for figuring out how to track this down. I've tried running BackupPC_dump by hand with variously high levels of verbosity, but haven't been able to find anything. What should I do next? The backup client in question is an OpenSolaris SXCE B82 box with rsync version 2.6.9 and ssh version "Sun_SSH_1.2" as distributed by Sun. Yes, this problem most likely relates to some craziness caused by my experimental OS, and I acknowledge that it's probably not even backuppc's fault. I'd still love some help tracking it down :-) Many thanks, - Benjamin Staffin ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
