On Thu, May 14, 2015 at 10:33 AM, <fred AT damen DOT org> wrote:
>>>> Both computers are on the same LAN. There should be no firewalls between
>>> them
>>> except on the BackupPC server(linux) and client (windows).
>>
>> I think even the windows host firewall can have a state timeout.
> On windows is this a global parameter? I do not remember seeing it when I
> opened the port for rsync.
I don't know that much about windows. If you are protected from the
internet by some other firewall I'd try turning off the windows
firewall for an incremental run to see if it changes anything.
>>
>> No, it sends an equivalent of the whole directory tree, then both
>> sides walk it sending the differences. In the incremental case, it
>> will skip files where the name/length/timestamp match the previous
>> copy. When backuppc does a full, it adds the --ignore-times option to
>> rsync, forcing it to read everything and compare block checksums.
>> Normally an incremental run with few changes will complete quickly.
>> Do you have a large number running concurrently?
> I only ever see two or three marked as 'currently running' at a time when
> looking at the host summary. This is always happening, incr fails and full
> completes. How can I see this 'whole directory tree' that is sent from the
> client being backed-up?, the XfreLOG starts with a list of 'got' an individual
> file. I assume 'got' means uploaded to BackupPC storage.
You can't 'see' the directory tree - it is an internal rsync operation.
> (I hope the first sentence here is inaccurate, i.e., the rsync on the BackupPC
> side should not be sending / updating files to/on the backuped client. Please
> confirm.)
Both sides walk the tree for the comparison - the differences are only
sent in the direction specified. The point is that in an incremental
the server side can skip matching files with just the directory info
(technically, some is from the inode...) where in a full, the client
will send block checksums for every file.
>>> >From the fact that the incr backup was started immediately after the full
>>> backup, I would expect to see a very small XferLOG. In which I could
>>> imagine
>>> there being a long time between rsync on the client finding and reporting a
>>> file to be backed-up. With the size of the XferLOG (thousands of lines) I
>>> find
>>> it hard to imaging that there was silent period causing a timeout.
>>
>> Is the number realistic? Maybe you have odd timestamps/ownership or
>> something that the server can't match.
> If the timestamps/ownerships appear to have changed, i.e., the comparison
> fails, shouldn't the incr perform the same as the full, with a few
> milliseconds added in between each file check?
I'm not sure about that. I'd guess that the timestamp/ownership are
already in the received tree listing so the client doesn't have to
send anything new. I've heard of situations with rsync in other
contexts where the receiver had a problem matching the times exactly
and would list the files as updated on every run, but that may have
been where the destination was a FAT filesystem and I don't know if it
can happen in backuppc. But you should be able to tell by looking at
the timestamps on those files whether they should have been included
in an incremental run or not.
So far the only thing we know for sure is that you get a sigpipe - and
that just means that the other end of the connection has exited or the
tcp connection is broken. Nothing makes much sense yet about the
underlying reason.
--
Les Mikesell
lesmikesell AT gmail DOT com
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
