After starting a backup it goes for some time before failing, which is what I'm finding hard to understand. I created a fresh test backup that worked flawlessly, it was just a couple of files, but for the whole drive it fails after a while, in this case it received nearly 42 gigabytes before failing
Here's the error:
rsync_bpc: connection unexpectedly closed (41767840413 bytes received so far) [receiver]
Done: 575 errors, 35874 filesExist, 48740738296 sizeExist, 917361234 sizeExistComp, 0 filesTotal, 0 sizeTotal, 4847 filesNew, 4315933366 sizeNew, 1647882560 sizeNewComp, 3812035 inode
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [receiver=3.1.3.0]
rsync_bpc: connection unexpectedly closed (83450982 bytes received so far) [generator]
DoneGen: 757 errors, 6871 filesExist, 596374878 sizeExist, 111756468 sizeExistComp, 472313 filesTotal, 198835601740 sizeTotal, 0 filesNew, 0 sizeNew, 0 sizeNewComp, 3789404 inode
rsync error: unexplained error (code 255) at io.c(226) [generator=3.1.3.0]
rsync_bpc exited with fatal status 255 (65280) (rsync error: unexplained error (code 255) at io.c(226) [generator=3.1.3.0])
recv >f+++++++++ rwx------ 197609, 197121 16029455 *filepath*/11Sec_2021May_0122.png
Xfer PIDs are now
xferPids
Got fatal error during xfer (rsync error: unexplained error (code 255) at io.c(226) [generator=3.1.3.0])
cmdSystemOrEval: about to system /bin/ping -c 1 *ipaddress*
cmdSystemOrEval: about to system /bin/ping -c 1 *ipaddress*
CheckHostAlive: ran '/bin/ping -c 1 *ipaddress*'; returning 5.456
Backup aborted (rsync error: unexplained error (code 255) at io.c(226) [generator=3.1.3.0])
__bpc_progress_state__ fail cleanup
BackupFailCleanup: nFilesTotal = 472313, type = full, BackupCase = 3, inPlace = 1, lastBkupNum =
BackupFailCleanup: inPlace with some new files... no cleanup and marking partial
__bpc_progress_state__ fsck
Running BackupPC_refCountUpdate -h drive -f on drive
cmdSystemOrEval: about to system /usr/share/backuppc/bin/BackupPC_refCountUpdate -h main_cdrive -f
Xfer PIDs are now 62150
xferPids 62150
This was all working before I added in an extra drive to my pool, there were some missteps I took in that process and I think I lost some backup files. So during BackupPC_fsck I get missing pool file errors and unable to open errors, along with unable to read attribute errors. The can't open errors popup during backup aswell and they are likely the cause of the 575 errors.
R bpc_attrib_dirRead: can't open /var/lib/backuppc/cpool/f4/d0/f5d0f9b273dbeee4c54c4d7ed575d20a
R bpc_attribCache_loadPath: bpc_attrib_dirRead(/var/lib/backuppc/pc/main_cdrive/177, f%2fcygdrive%2fc/fUsers/fDillon/fDocuments/fAdobe/fPrelude/f9.0/fProfile-Dillon/fLayouts/attrib) returned -1
Actually just noticing all these paths have have f in front of them, not sure why that is?
With that said, as mentioned it does work on shorter connections, even for the host that's failing; when I restored 4 files a few days ago, they restored without a problem. So I just don't understand how it can work for 40 gigabytes and then fail. This is also over the course of hours, but that's nothing new.
Another thing to note is that the host is on Windows using cygwin. When I was troubleshooting the problem, I updated rsync on the host to 3.2.4 for cygwin, which is not the same version as rsync-bpc 3.1.3 on the server, however I can't seem to find a way to downgrade the cygwin rsync, could it be a rsync version mismatch problem?
The firewall settings have not changed since I could do this backup in full, however windows 10 has been updated. The server is running on Ubuntu, which I may have also updated since it was working, I can't remember.
Is there any solution or any further troubleshooting steps I can take? I did follow this answer, but it didn't seem to have any errors, also bear in mind that that was done with ordinary rsync 3.1.3 not rsync-bpc.
Update: more backups have been attempted, but none have yet to be succesful other than the test backup I set up. I'm seeing code 12, 19, 20 and 255 pop up for rsync. The backups still run for some time before failing, the latest ran for ~4 days before failing.
