I was able to make a full backup without any problems. It runs smoothly over
1381 minutes.
I am now waiting for the next incremental backups.
Am 07.03.2016 um 18:00 schrieb Nicolas Göddel:
> I captured the network packages with tcpdump. There are the last rows if it
> helps you:
>
> 17:15:47.974113 IP 192.168.1.13.52202 > 192.168.1.13.rsync: Flags [P.], seq
> 872185:905151, ack 32293747, win 19047, options [nop,nop,TS val 1217113361 ecr
> 1217092736], length 32966
> 17:15:48.012397 IP 192.168.1.13.rsync > 192.168.1.13.52202: Flags [.], ack
> 905151, win 651, options [nop,nop,TS val 1217113371 ecr 1217113361], length 0
> 17:16:25.792430 IP 192.168.1.13.rsync > 192.168.1.13.52202: Flags [.], seq
> 32293747:32359230, ack 905151, win 651, options [nop,nop,TS val 1217122816 ecr
> 1217113361], length 65483
> 17:18:17.188110 IP 192.168.1.13.52202 > 192.168.1.13.rsync: Flags [P.], seq
> 905151:937925, ack 32293747, win 19047, options [nop,nop,TS val 1217150664 ecr
> 1217122816], length 32774
> 17:18:17.188139 IP 192.168.1.13.rsync > 192.168.1.13.52202: Flags [.], ack
> 937925, win 519, options [nop,nop,TS val 1217150664 ecr 1217150664], length 0
> 17:18:26.112415 IP 192.168.1.13.rsync > 192.168.1.13.52202: Flags [.], seq
> 32293747:32359230, ack 937925, win 519, options [nop,nop,TS val 1217152896 ecr
> 1217150664], length 65483
> 17:18:38.498664 IP 192.168.1.13.52202 > 192.168.1.13.rsync: Flags [P.], seq
> 937925:970705, ack 32293747, win 19047, options [nop,nop,TS val 1217155992 ecr
> 1217152896], length 32780
> 17:18:38.536389 IP 192.168.1.13.rsync > 192.168.1.13.52202: Flags [.], ack
> 970705, win 388, options [nop,nop,TS val 1217156002 ecr 1217155992], length 0
> 17:18:43.795400 IP 192.168.1.13.52202 > 192.168.1.13.rsync: Flags [P.], seq
> 970705:1004881, ack 32293747, win 19047, options [nop,nop,TS val 1217157316
> ecr
> 1217152896], length 34176
> 17:18:43.832389 IP 192.168.1.13.rsync > 192.168.1.13.52202: Flags [.], ack
> 1004881, win 121, options [nop,nop,TS val 1217157326 ecr 1217157316], length 0
> 17:29:15.660423 IP 192.168.1.13.52202 > 192.168.1.13.rsync: Flags [P.], seq
> 1004881:1020369, ack 32293747, win 19047, options [nop,nop,TS val 1217315283
> ecr
> 1217152896], length 15488
> 17:29:15.660445 IP 192.168.1.13.rsync > 192.168.1.13.52202: Flags [R], seq
> 3811472093, win 0, length 0
>
> This happened after manually triggering an incremental backup.
>
> Am 07.03.2016 um 16:58 schrieb Nicolas Göddel:
>> Is there a point where I can begin debugging that issue? Is it not getting
>> better at the moment and I need my daily backups. Is it possible to use rsync
>> without the daemon and network communication? For example with 'rsync' as
>> XferMethod?
>>
>> Am 02.03.2016 um 14:35 schrieb Nicolas Göddel:
>>> Am 02.03.2016 um 14:08 schrieb Stefan Peter:
>>>> Dear Nicolas Göddel
>>>> Am 02.03.2016 um 11:41 schrieb Nicolas Göddel:
>>>>> Hi,
>>>>>
>>>>> thank you. I did an incremental backup with verbose output. The last few
>>>>> lines
>>>>> in the log are these:
>>>>>
>>>>> attribWrite(dir=fbenutzer/.Trashes/501/Recovered files
>>>>> #1/com.apple.iBooksAuthor_409_SFED_368025537_2/SpookySpooky.ibooks/OPS/assets/thumbs/content13)
>>>>> -> /var/lib/backuppc/pc/suw03/new/fbenutzer/f.Trashes/f501/fRecovered
>>>>> files
>>>>> #1/fcom.apple.iBooksAuthor_409_SFED_368025537_2/fSpookySpooky.ibooks/fOPS/fassets/fthumbs/fcontent13/attrib
>>>>> Done: 0 files, 0 bytes
>>>>> Got fatal error during xfer (aborted by signal=PIPE)
>>>>> Backup aborted by user signal
>>>>> dump failed: aborted by signal=PIPE
>>>> This didn't reveal additional information, so I would propose to have a
>>>> look at the other end of the backup.
>>>>
>>>> According to the first mail you wrote, you are using the rsyncd transfer
>>>> method. So, according to my experience, signal=PIPE errors most of the
>>>> time are caused by timeouts. Although the rsyncd has no default I/O
>>>> timeout, most default rsyncd.conf files use something along the lines of
>>>> 600 seconds.
>>>>
>>>> Can you check your /etc/rsyncd for a timeout=... parameter?
>>>> If you find one, double the amount, restart rsyncd and retry your backup.
>>> I already added the line timeout=604800 to /etc/rsyncd.conf and restarted
>>> rsync
>>> by myself as daemon.
>>>> If there is no timeout to be found in rsyncd.conf, it may be specified
>>>> on the command line of the rsyncd startup script. A 'ps faxw|grep rsync'
>>>> should reveal it.
>>> rsync was started using the command: rsync --daemon
>>>> If this does not help, finding the logs for rsyncd may shed some more
>>>> lights on the problem. Because AFAIK there is no standard rsyncd.conf
>>>> for Debian/Ubuntu, check your config file for 'log file' and 'syslog
>>>> faclities' entries. These define where rsyncd will put the log files.
>>>> You can find out more about these entries by issuing "man rsyncd.con".
>>> I also set up a user defined log file. These are the lines from the manual
>>> test
>>> today:
>>>
>>> 2016/03/02 10:35:38 [27279] name lookup failed for 192.168.1.13: Name or
>>> service
>>> not known
>>> 2016/03/02 10:35:38 [27279] connect from UNKNOWN (192.168.1.13)
>>> 2016/03/02 09:35:38 [27279] rsync on . from backuppc@UNKNOWN (192.168.1.13)
>>> 2016/03/02 09:35:38 [27279] building file list
>>> 2016/03/02 10:35:57 [27286] name lookup failed for 192.168.1.13: Name or
>>> service
>>> not known
>>> 2016/03/02 10:35:57 [27286] connect from UNKNOWN (192.168.1.13)
>>> 2016/03/02 09:35:57 [27286] rsync on . from backuppc@UNKNOWN (192.168.1.13)
>>> 2016/03/02 09:35:57 [27286] building file list
>>> 2016/03/02 09:35:58 [27279] rsync: [sender] write error: Broken pipe (32)
>>> 2016/03/02 09:35:58 [27279] rsync error: error in socket IO (code 10) at
>>> io.c(820) [sender=3.1.1]
>>> 2016/03/02 10:08:09 [27286] UNKNOWN send Mitarbeiter/xxx/001
>>> Privado/Stunden/Time sheet_neu .xlsx 26183 13967
>>> 2016/03/02 10:08:09 [27286] UNKNOWN send Mitarbeiter/xxx/002
>>> Webseiten/Ebook.xxx/Bilder/Beispiele/Vorher_Nachher.jpg 591907 592023
>>> 2016/03/02 10:23:48 [27286] rsync: [sender] write error: Connection timed
>>> out (110)
>>> 2016/03/02 10:23:48 [27286] rsync error: error in socket IO (code 10) at
>>> io.c(820) [sender=3.1.1]
>>>
>>> Because rsync has a little problem with the current timezone the date is
>>> somehow
>>> confusing.
>>> See also: https://bugzilla.samba.org/show_bug.cgi?id=2607
>>>> With kind regards
>>>>
>>>> Stefan Peter
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>> Monitor end-to-end web transactions and take corrective actions now
>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>> _______________________________________________
>>>> 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/
>
--
——————————————————————————————————————————————
Homepage: http://freakscorner.de
Facebook: http://www.facebook.com/Bastelkeller
Twitter: http://twitter.com/freaks_corner
Youtube: http://youtube.com/tubenic86
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
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/
|
