După ce am început o copie de rezervă, trece ceva timp înainte de a eșua, ceea ce îmi este greu de înțeles. Am creat o copie de rezervă de test proaspătă care a funcționat impecabil, au fost doar câteva fișiere, dar pentru întreaga unitate eșuează după un timp, în acest caz a primit aproape 42 de gigaocteți înainte de a eșua
Iată eroarea:
rsync_bpc: conexiune închisă în mod neașteptat (41767840413 octeți primiți până acum) [receptor]
Efectuat: 575 de erori, 35874 fișiereExist, 48740738296 sizeExist, 917361234 sizeExistComp, 0 fișiereTotal, 0 sizeTotal, 4847 fișiereNou, 4315933366 sizeNew, 16478882560de20Comp, 5381de20
eroare rsync: eroare în fluxul de date a protocolului rsync (cod 12) la io.c(226) [receptor=3.1.3.0]
rsync_bpc: conexiune închisă în mod neașteptat (83450982 octeți primiți până acum) [generator]
DoneGen: 757 erori, 6871 fișiereExist, 596374878 sizeExist, 111756468 sizeExistComp, 472313 fișiereTotal, 198835601740 sizeTotal, 0 fișiereNou, 0 sizeNew, 0 sizeNewComp, 378de940
eroare rsync: eroare inexplicabilă (cod 255) la io.c(226) [generator=3.1.3.0]
rsync_bpc a ieșit cu starea fatală 255 (65280) (eroare rsync: eroare inexplicabilă (cod 255) la io.c(226) [generator=3.1.3.0])
recv >f++++++++++ rwx------ 197609, 197121 16029455 *filepath*/11Sec_2021May_0122.png
PID-urile Xfer sunt acum
xferPids
A primit o eroare fatală în timpul xfer (eroare de sincronizare: eroare inexplicabilă (cod 255) la io.c(226) [generator=3.1.3.0])
cmdSystemOrEval: pe cale de a ajunge la sistem /bin/ping -c 1 *ipaddress*
cmdSystemOrEval: pe cale de a ajunge la sistem /bin/ping -c 1 *ipaddress*
CheckHostAlive: a rulat „/bin/ping -c 1 *ipaddress*”; revenind 5.456
Backup anulat (eroare rsync: eroare inexplicabilă (cod 255) la io.c(226) [generator=3.1.3.0])
__bpc_progress_state__ eșuează curățarea
BackupFailCleanup: nFilesTotal = 472313, type = full, BackupCase = 3, inPlace = 1, lastBkupNum =
BackupFailCleanup: inPlace cu câteva fișiere noi... fără curățare și marcare parțială
__bpc_progress_state__ fsck
Rulează BackupPC_refCountUpdate -h drive -f pe unitate
cmdSystemOrEval: pe cale de a ajunge la sistem /usr/share/backuppc/bin/BackupPC_refCountUpdate -h main_cdrive -f
PID-urile Xfer sunt acum 62150
xferPids 62150
Toate acestea funcționau înainte de a adăuga o unitate suplimentară la piscina mea, au fost niște pași greșiți pe care le-am făcut în acest proces și cred că am pierdut câteva fișiere de rezervă. Așadar, în timpul BackupPC_fsck, primesc erori de fișiere de pool lipsă și erorile incapabile să deschid, împreună cu erorile de atribut imposibil de citit. Nu se poate deschide fereastra de eroare în timpul copiei de rezervă și probabil că acestea sunt cauza erorilor 575.
R bpc_attrib_dirRead: nu se poate deschide /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-outedsillon -/1fLat)
De fapt, doar observând toate aceste căi au f în fața lor, nu sunteți sigur de ce?
Acestea fiind spuse, așa cum am menționat, funcționează pe conexiuni mai scurte, chiar și pentru gazda care eșuează; cand am restaurat 4 fisiere in urma cu cateva zile, s-au restaurat fara probleme. Deci pur și simplu nu înțeleg cum poate funcționa pentru 40 de gigaocteți și apoi eșuează. Acest lucru este, de asemenea, de-a lungul orelor, dar nu este nimic nou.
Un alt lucru de remarcat este că gazda este pe Windows folosind cygwin. Când depanam problema, am actualizat rsync pe gazdă la 3.2.4 pentru cygwin, care nu este aceeași versiune cu rsync-bpc 3.1.3 pe server, totuși nu găsesc o modalitate de a downgrade cygwin rsync, ar putea fi o problemă de nepotrivire a versiunii rsync?
Setările paravanului de protecție nu s-au schimbat de când am putut face această copie de rezervă în întregime, totuși Windows 10 a fost actualizat. Serverul rulează pe Ubuntu, pe care s-ar putea să l-am actualizat și eu deoarece funcționa, nu îmi amintesc.
Există vreo soluție sau alți pași de depanare pe care să-i pot face? Am urmat acest raspuns, dar nu părea să aibă erori, de asemenea, rețineți că asta s-a făcut cu rsync 3.1.3 obișnuit, nu cu rsync-bpc.
Actualizare: s-au încercat mai multe copii de siguranță, dar niciuna nu a avut încă succes, în afară de backup-ul de test pe care l-am configurat. Văd codul 12, 19, 20 și 255 pop-up pentru rsync. Backup-urile încă rulează ceva timp înainte de a eșua, cea mai recentă a rulat timp de ~4 zile înainte de a eșua.
