Good day, I would like to request you assistance, since I'm trying to understand the behavior of one of our backuppc instances and, if ever possible, find a way to solve it.
The set-up is a Linux server that is supposed to back up the contents of
a Windows 7 client via rsync over ssh. Now, we used to have rsyncd as
transfer method, but I had the feeling – and had also read so somewhere
– that rsync over ssh might work better.
In any case, the connectivity (a VPN tunnel over a 32Mbit ADSL
connection) is given:
> Pings to client-ssh have succeeded 17 consecutive times.
The issue we see is that backuppc (or is it rsync) is constantly
aborting the backups at some point in time:
> Read EOF:
> Tried again: got 0 bytes
> finish: removing in-process file Data/*****/-Mission 10-2008/SND_0010.wav
> Can't write 4 bytes to socket
> Child is aborting
> Done: 42548 files, 3445689196 bytes
> Got fatal error during xfer (aborted by signal=PIPE)
> Backup aborted by user signal
> Not saving this as a partial backup since it has fewer files than the prior
> one (got 42548 and 42548 files versus 342338)
The files at which it fails are always different ones. So it doesn't
appear to be a filesystem issue. Also, while the backup aborts at some
point, an ssh connection to the host is staying up without any isssues.
This is the command that gets sent by backuppc:
> /usr/bin/ssh -C -o ServerAliveInterval=15 -q -x -l User client-ssh
> /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D
> --links --hard-links --times --block-size=2048 --recursive --append-verify
> --bwlimit=16000 --ignore-times . /cygdrive/d/
The client has several partitions which we define as rsync shares:
> $Conf{RsyncShareName} = [
> '/cygdrive/d',
> '/cygdrive/g',
> '/cygdrive/h',
> '/cygdrive/c',
> ];
And the timeout is ludicrous:
> # DR: this is 72 hours, I do not think that this makes any sense.
> # No single file can reasonably take that long
> $Conf{ClientTimeout} = '259200';
Now, the other issue I have, or maybe I'm simply failing to understand,
is resuming backups. It doesn't appear to do that, ever. Each new
attempt at a full or incremental backup always starts from scratch. Is
that normal? I thought that running a backup several times would always
resume from where it had left of, so that in time – even with several
failing backup attempts – one would get at a complete backup in the end.
I've experimented with rsync options, like *checksum* or
*append-verify*, but whereas the first makes rsync throw an overflow
exception, the second one doesn't seem to have any effect on the
behavior of not resuming prior backups.
> # checksum, see
> http://unix.stackexchange.com/questions/48298/can-rsync-resume-after-being-interrupted
> # limiting bandwith to about 16Mbit (connection is 32Mbit down)
> $Conf{RsyncArgsExtra} = [
> #'--checksum', # causes overflow
> '--append-verify',
> '--bwlimit=16000'
> ];
Note that we also back up a Unix client to the same server, with much
more data in this case, but not a single issue so far. It somehow leads
me to believe that it would be the Windows OS closing down the
connection at some point, but I don't really know where to look.
Best regards,
David
--
TenTwentyFour S.à r.l.
W: www.tentwentyfour.lu
T: +352 20 211 1024
F: +352 20 211 1023
9, avenue des Hauts-Fourneaux
L-4362 Esch/Alzette
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________ 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/
