i have found that the default timeout will not work over even a fast WAN. i
have an MPLS network with ping times averaging about 180ms and i could not
get a reliable incremental without putting that hosts timeout at 300ms.
please let me know if that helps
On 10/17/07, Les Mikesell <[EMAIL PROTECTED]> wrote:
>
> List Receiver wrote:
> > I've got a BackupPC 3.0 system in place that is backing up a couple
> dozen hosts. Most of the hosts are Windows boxes running Rsyncd, and they
> backup just fine. One of my hosts, however, can't seem to complete an
> incremental run for the life of it. A full run completes, but takes a long
> time to do so (almost a full 24 hours). Basically every incremental run
> times out or is interrupted by the hosts Internet connection (it's backed up
> over a WAN link to the BackupPC server).
> >
> > This system *used* to do incremental backups just fine, but one day, it
> quit. I've upgraded the rsyncd code to the latest available on SF, I've
> restarted the service a few times, I've watched the system with Task Manager
> while the backup is running and not noticed anything using high
> resources. Rsyncd acts as though it's disk-bound, by which I mean that it
> occupies very little CPU time or memory while it pulls the list of changed
> files together. Kernel time on the system during the generation process is
> almost non-existant, though. Once the backup run actually generates a
> transfer PID, the usage drops even lower. It's like there's a 200ms timeout
> between each command that rsyncd receives and fulfills.
> >
> > Has anyone seen anything like this before? Any idea how I should go
> about troubleshooting it?
> >
>
> This sounds like something unique to your wan link. Is it possible that
> it times out and drops idle connections? Rsync transfers the entire
> directory listing first, then the server walks through the whole list
> and on incrementals it only transfers anything when differences are
> found in the directory contents. If you have a large set of files with
> few changes you might have long periods of idle time and some network
> devices like nat routers may drop idle connections after timeout period
> - usually these are long, but perhaps something is misconfigured.
>
> --
> Les Mikesell
> [EMAIL PROTECTED]
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> BackupPC-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/backuppc-users
> http://backuppc.sourceforge.net/
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
BackupPC-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
