rdiff-backup probléma

Segédprogramok

Sokszor futottam már bele problémába az rdiff-backup-pal...
Most viszont nem sikerül sehogy sem.

Ez a hiba:

Traceback (most recent call last):
File "/bin/rdiff-backup", line 30, in
rdiff_backup.Main.error_check_Main(sys.argv[1:])
File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 304, in error_check_Main
try: Main(arglist)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 324, in Main
take_action(rps)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 280, in take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 337, in Backup
backup_final_init(rpout)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 501, in backup_final_init
checkdest_if_necessary(rpout)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 920, in checkdest_if_necessary
dest_rp.conn.regress.Regress(dest_rp)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 71, in Regress
for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/rorpiter.py", line 277, in __call__
if self.finish_branches(index) is None:
File "/usr/lib64/python2.7/site-packages/rdiff_backup/rorpiter.py", line 229, in finish_branches
to_be_finished.end_process()
File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 319, in end_process
rpath.copy_attribs(rf.metadata_rorp, rf.mirror_rp)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/rpath.py", line 181, in copy_attribs
if Globals.eas_write: rpout.write_ea(rpin.get_ea())
File "/usr/lib64/python2.7/site-packages/rdiff_backup/rpath.py", line 1347, in write_ea
ea.write_to_rp(self)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/eas_acls.py", line 111, in write_to_rp
self.clear_rp(rp)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/eas_acls.py", line 91, in clear_rp
rp.conn.xattr.removexattr(rp.path, name, rp.issym())
IOError: [Errno 61] No data available

Az előző könyvtárral ugyanez volt a baj. Van benne vagy 2 évnyi mentés. Egyszer csak ezt elkezdte, a hét elején, és se a check destination, se az új backup nem megy rá. Elraktam egy old könyvtárba, mondván majd kezdek vele valamit, közben egy új üresbe elindítottam egy új mentést. Lement az első "full", majd a következő diffnél ez is ugyanezt a hibát produkálja.

Mindkét fájlrendszer lokális, xfs, egyébként nem változott semmi. Eddig ment.... Ilyenkor elgondolkozok rajta, hogy tényleg egy python-ban írt cucc-e a legmegfelelőbb backup készítésére.

  • 3314 megtekintés

( locsemege v | 2017. 11. 01., sze – 15:20 )

Én használok rdiff-backup-ot, bár nem látom az stderr-t, mert írtam fölé egy shell scriptet, amely ad egy valamelyest, minimális grafikus felületet. Amúgy nézd meg a dmesg-et, nem tartom kizártnak, hogy a háttértárral - gondolom HDD - van valami probléma, vagy a filerendszer sérült, esetleg valamikor nem volt lecsatolva.

Nekem a backup HDD-m btrfs, amiről mentek az jellemzően ext4. Eddig még sohasem tapasztaltam hibát.

rpm -q rdiff-backup
rdiff-backup-1.2.8-23.fc27.x86_64

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nincs gond a háttértárral, sem dmesgben, sem smartban nincs hiba.
Mint írtam, azért csináltam mentést új könyvtárba, hogy ne legyen ott az előző katyvasz. Az első mentés lement, a második már nem.
rdiff-backup-1.2.8-12.el7.x86_64
Egyébként valami python szarságra gyanakszok, ugyanis néha pl. a yum update is szokott adni ilyen IO hibát - nem csak ezen, más gépen is, random...
--
"Sose a gép a hülye."

Kerlek javits ki ha tevednek, de rdiff-backup nincs CentOS-ben. Valoszinuleg EPEL repo-bol tetted fel.
Az EPEL nem tartja meg a regi csomagokat (tobbek kozott ezert is sync-eljuk le oket) bar lehet hogy talalsz egy-ket syncelt mirrort akik igen.

En downgrade helyett javasolnam az egysorors patch-et amit a srac irt (https://github.com/sol1/rdiff-backup/issues/20) vagy esetleg a workaround-ot amit a bugzillaban irtak (backup with --no-eas).

( elod v | 2017. 11. 02., cs – 21:00 )

Csak leírom, nyilván pici esélye van.
RAM hiba miatt dobált összevissza mindenféle hibát az rdiff backup. Azóta ECC memóriás gépre backupolok.

De, lehet (mondjuk csak protocol=1-el teszeltem, a 2-es passz).
Sőt, ha felteszed hozzá a burp ui-t, akkor csilli villi webes felületen is válogathatsz a fájlok között (parancssorból pedig simán a mentős szerveren megkeresed a fájlt, átküldöd egy gzip-en és ha Winről jött, akkor egy vss_strip-en.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Melyikre?

burp-ui-ban kijelölsz egy fájlt/mappát és alul a Download selected files.

A másikra: 


cat /var/spool/burp/HostNevetNemAdunkKi/current/data/t/D\:/install/VMware-converter-all-4.3.0-292238.exe | gunzip | vss_strip > ~/VMware-converter-all-4.3.0-292238.exe

Ez egy Wines gépről készült backup, engedélyezett tömörítéssel.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Azt lásd fenn.

Közben rájöttem, hogy számodra érdekes lehet a kliensen restore-olás, ott pl. regex-szel tudsz:

burp -a r -b 1 -r myregex
Restores all the files in backup number 1 that match the regular
expression 'myregex' back to their original location.

(Forrás: http://burp.grke.org/docs/manpage.html)

Erre nem is gondoltam, mert nálam paranoidra van állítva a cucc (kliens csak időzített mentést tud futtatni, nem restore-olhat, cserébe a szerver se kezdeményezhet restore-t) és kopp-kopp eddig minden visszaállításnál elég (és egyszerűbb) volt a szerverről 1-2 fájlt kikukázni és e-mailben átdobni.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

OK, mondjuk hogy ez ó lesz.
Viszont amit még nem találtam meg, hogy független tartalmakat hogy tudok backupolni, mondjuk más retention policyvel?
Pl. egy gépről akarok csinálni mentést:
- a rendszerről, hetente egyet, 1 hónapra visszamenőleg (kivéve a virtuális fájlrendszerek, illetve a service-ek work könyvtárai (pl. /var/www, /var/lib/mysql))
- /var/www-ről napi mentést, 2 hétre visszamenőleg
- mysqldump-pal valahova kidumpolt adatbázisokról napi mentést, 1 hónapra visszamenőleg
--
"Sose a gép a hülye."

Első nekifutásra én csinálnék rá három klienst: szerver-full, szerver-var, szerver-database, a kliensen pedig három kliens konfig fájlt, három megfelelő cname-el. Aztán a cron-ban beadod, hogy a megfelelő config fájllal fusson a megfelelő időben.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( uzsolt v | 2017. 11. 24., p – 15:03 )

Félig off: én is az rdiff-backup-ot használom, de a baj, hogy nem fejlesztik, és a python fejlődése visszafele nem kompatibilis, azaz a 3-as python már nem jó az rdiff-backup-nak. Félek, hogy a python2 előbb-utóbb kikerül a disztrók csomagkínálatából, ezáltal az rdiff-backup-ot is magával rántva.

Másrészt, saját esetemre érvényes: szerintem nekem backup-olni alapvetően kétféle dolgot kell: olyat, ami változik (vagy változhat), és olyat, ami nem változik. Előbbire nyilván példák dokumentumok, kódok, stb., utóbbira fényképek, pdf-fájlok, stb.
Én már nagyon azon gondolkodom, hogy az rdiff-backup-ot kiváltom: a változó dolgokra verziókezelő (jelenleg is beállított, saját gépen a fő repó, ami tükrözve van egy VPS-re és egy direkt backup-céllal megőrzött régi gépre), a nem (vagy nemigen) változó fájlokra pedig rsync, a biztonság kedvéért --backups opcióval.
Amit nyerek ezzel a móddal: a verziókezelés, sokszor nyilván az időpont nem elég, egy minimális changelog praktikus lehet sok esetben. Az rsync C-ben íródott, így talán kisebb az esélye, hogy elavulttá válik.
Amit vesztek: egy megváltozott fájl esetében nem a (reverse) diff lesz tárolva, hanem a régi verzió is (a --backup könyvtárában). Viszont nem gyakran változnak a fájlok, így egy idő után ki lehet törölni a régi verziókat.

Sztem lesz itt még fejlesztés: https://github.com/sol1/rdiff-backup
Amúgy meg én megnéztem sokmindent (a legújabb cuccokat nem), de ez volt az ami tudta azt amit szeretnék és nem valami óriási bonyolult bloatware.
Van csomagban azokon a rendszereken amiket használok, az is egy nagy előny.

(Szintén off)

♲♻♲