Keresek verziózó tömörítőt

Segédprogramok

Az a problémám, hogy van egy rakat képem, fotók, amiket menteni kéne úgy, hogy a korábbi verziók is megmaradjanak.

Ez a lépés már a második lenne. Arról a gépről amin matatok készül egy rsync-es mentés, és ezt kellene menteni. A verziózás azért kell, mert ha megsérül egy-két fájl, és azt úgy menti el, akkor hiába van mentés, a hibás verzió lesz lementve.

A képek nagy többségben raw fájlok, ezek normális esetben sose változnak. Ami változik, azok az apró paraméterfájlok.

Az általam kigondolt ideális megoldás az lenne, hogy ha le tudnám menteni a teljes könyvtárat splittelt formában, helyreállító rekordokkal, miegymással egyben(*), azaz a rar tökéletes lenne, ha tudna több verziót tárolni egy-egy fájlról. Ám úgy találtam, hogy nem tud. Az arj se. Pedig emlékszem, hogy csináltam ilyet, igaz az DOS alatt volt anno.

*) így rendszeresen tudnám ellenőrizni az adatok épségét.

  • 2595 megtekintés

( Exit | 2011. 04. 09., szo – 11:04 )

A verziókövetésre használhatnál verziókövetőt pl.: git-et vagy svn-t. Tömörítve tárolja a fájlokat és csak a diffeket menti el verzióváltáskor. Így bármikor bármelyik korábbi verziót előszedheted.

Ezen is elmélkedtem. Ami nem tetszik - csak az svn-t ismerem valamennyire -, hogy az új fájlok kezelése nekem kicsit izé.

Minden "mentéskor" futtassak rá egy svn add-ot? Aztán meg egy svn up-ot? Nem tűnik elegánsnak, bár lehet, hogy nincs más megoldás.

Milyen redundanciát tud? Az a gondom, hogy ha az svn repo megsérül (mert ami megsérülhet az meg is sérül), akkor:

- vagy esélyem sincs a sérült fájlok visszaállítására
- vagy az egész svn repo kakukk lesz

A rar -rr -rv kapcsolóival "önjavító" rarokat lehet csinálni, ami nekem szimpatikus megoldás.

Bár most támadt egy ötletem:

- jelenleg 130G-nyi fotót kell mentenem
- ez svn alatt se lesz nagyobb
- 1T-s külső diskre akarok archiválni(*)
- ezen kényelmesen elfér az svn repo és mellette egy mentés a repo-ról

Az archiválás menete:

- svnadmin verify
- ha ok, akkor archiválás, ha nem ok, riasztás
- svnadmin verify (csak a biztonság kedvéért)
- ha ok, akkor az svn repo mentése tetszés szerint, amúgy riasztás
- örömködés

*) Tudom hogy ez bűnös dolog. Ám e mellett van még két mentés, abból az egyik egy hónapra visszamenőlegesen.

A git úgy működik, hogy ott gyakorlatilag nincs külön repó és working copy. Ha egy mappád verziózva van, akkor van benne egy ".git" mappa a legfelső szinten és az a repó.

Talán így lehetne megoldani (tesztelést igényel, főleg hogy tényleg elbír -e ennyi anyagot a git repó):
Létrehozol egy üres git repót és a .git mappát átrakod a backup vinyóra.
A .git mappát a backup vinyóról belinkeled az archiválandó munkád legfelső könyvtárába.

Innentől úgy működik mint egy .git repó, de a verziózott repó a backup vinyón van a munka fájlok meg egyszeresen a gépen.

Szerk.: kipróbáltam (Win7-n), technikailag működik. Gyakorlatilag ilyen a felépítés:
D:\munkakönyvtár\.git egy mappa link (junction) -> F:\backupkönyvtár\.git mappára, ahol a backupkönyvtár egy frissen létrehozott git repó.

Ennyi. A d:\munkakönyvtár szépen kezelhető git-tel (add, commit stb).

Lehet, hogy mégsem a verziókezelők a megoldás a te esetedben (vagy meg kell nézni többet is). Igazából elég hatékonyan tudnak működni helytakarékosság szempontjából is, de nem ez a fő szempont, amiért használják őket. Svn-t használtam 100MB-os zippel (igaz ez alapban tömörített) és nekem az tetszett benne, hogy volt, hogy csak pár fájl változott a zipben és az svn csak egy pár kb-os diffet tárolt el a változásról. A git-ről biztosan tudom, hogy az gzip-peli a tartalmat magában a repóban is.

Ok, utánaolvastam, megtetszett, gondoltam milyen jó lesz majd svn-ező kollégákat azzal ugratni, hogy én még a zenéket is git-ben tárolom, no lássuk, haskell platform kell neki, uccu neki: 

# apt-get install haskell-platform
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:

(... egy képernyőnyi csomagnév ...) 

0 upgraded, 54 newly installed, 0 to remove and 0 not upgraded.
Need to get 81.6MB/85.9MB of archives.
After this operation, 473MB of additional disk space will be used.
Do you want to continue [Y/n]?

WTF?! Minek ennek 470+ mega? Minek ennek libgl1-mesa-dev?! Hát én bizony n-t nyomtam ;)

Nem használ. Ez egy metapackage, ami az összes "standard haskell libraries and tools"-t tartalmazó package-et hozza magával, amik közül az egyik a libghc6-opengl-dev ;)
Nekiállhatnék trial-and-error alapon kiválogatni, hogy mi az, mire tényleg szükség van, de ehhez nincs kedvem, most inkább hallgatom a zenét, mint valami geek toollal kezeljem ;)

debian, en igy szeretlek...
akarom mondani ezert ruhellem a deb alapu disztrokat, sot ugy altalaban a fuggosegekzelo csomagkezelest.
de leginkabb az idiota csomagolokat akik minden letezo szart beleforditanak a programokba aztan a fel vilagon dependel emiatt.

kedvenc emlekem mikor egy debian szerveren fel akartam rakni az mc-t, erre felrakta az X-tol kezdve a fel vilagot...

A'rpi

Igen, add, update, commit; valamit valamiért, ezekhez hozzá kell szokni.

Én így elsőre azt nézném meg, hogy jó-e így: git-tel (netán svn-nel) verziózás, ezt lehet másik gépről is; és a repót menteném. A mentést kéne megbízhatóra csinálni. Bár látom, közben más megoldás is körvonalazódik.

svn repóm sérült már meg; csak az érintett 1-2 fájl szállt el, minden más maradt, de lehet, hogy mázlim is volt. De nem erre bíznám a dolgot, hanem a mentésre.

( foci v | 2011. 04. 09., szo – 11:08 )

rsync --backup --backup-dir ?
--backup-dir `date +%Y%m%d`
pl.

( uid_2716 | 2011. 04. 09., szo – 14:41 )

Ez a lépés már a második lenne. Arról a gépről amin matatok készül egy rsync-es mentés, és ezt kellene menteni. A verziózás azért kell, mert ha megsérül egy-két fájl, és azt úgy menti el, akkor hiába van mentés, a hibás verzió lesz lementve.

Már az első mentést is a duplicity-vel csináld az rsync helyett. A mentett oldal tömörített, titkosított, integritásvédett lesz. (A duplicity a gpg-nek tovább tud adni opciókat; például a tömörítés szintje is szabályozható.) A mentés növekményes; a friss növekményt a duplicity a tárolt korábbi szignatúrák (hash-ek) alapján készíti el. Vagyis ha a forrás megsérül, akkor a legutóbbi szignatúrától el fog térni, így a növekményben szerepelni fog, így a régi verzió elérhető marad.

Ezzel két problémám van. Nem tudom ellenőrizni, hogy a duplicity-vel mentett cuccok épek-e (ha minden jól megy, akkor évekig lesz egy helyen, hetente ellenőrizni kéne az adatok integritását), illetve hogy minden inkrementális mentésnél csinál újabb fájlt akkor is, ha nem volt változás. Napi mentéssel (archiválással) számolva bő 300 olyan fájl lenne az archívumban ami felesleges. Bár ezzel még együtt tudnék élni.

Ha jól számoltam, akkor az S3-ba mentés havi 14-20 dodó lenne, ami egy év alatt már meghaladja egy külső disk árát. Ezért aztán kellene valami ellenőrzés.

Illetve van egy harmadik problémám, a duplicity-vel létrehozott fájlokat csak(?) a duplicity-vel lehet olvasni míg egy zip, tar, rar kb. bármi alatt olvasható.

-- Update: benéztem, a verify tényleg azt ellenőrzi amit kell. Szimuláltam is bithibát és frankón észrevette.

A másik két problémával még barátkozom.

( Aadaam v | 2011. 04. 09., szo – 18:41 )

Hulye kerdes, de zfs?

Eletbe nem hasznaltam, de verziozas, meg nagy fajl kezeles van benne... :)

( joco01 v | 2011. 04. 09., szo – 19:18 )

Én dolgozok egy backup projekten, ami pont ezt tudja. Ugyanis én is paranoiás vagyok, nem csak egy sima duplikátum másolat kell mindenből, hanem meg akarok győződni, hogy a fájlok nem romlanak el, sem a forrásban, sem a backupban. A programom a cél mappában tárolna minden forrás fájlt, bizonyosakat tömörítve, másokat nem, korábbi verziókat is mindenből, plusz a fájl hash-eket is egy indexben. Be lenne állítva, hogy bizonyos fájlok esetén nem normális, ha megváltozik, és akkor szólna, ha mégis.

--
joco voltam szevasz

( tovis v | 2011. 04. 09., szo – 19:23 )

arj add chapter?

* Én egy indián vagyok. Minden indián hazudik.

Oké, viszont mik azok a chapter-ek? A fejezet fordítás nekem nem sokat mond, és messze esik az általam várt "verzió"-tól.

Update: áh, végre megtaláltam, értem már. Majdnem az, ami nekem kell. Az egyetlen dolog ami zavar, az a 250-es limit, amin viszont alighanem tudok annyit segíteni,hogy csak akkor mentek, ha a tree megváltozott. Ez átlag hetente van, így majd' öt évig is eltarthat mire elfogynak a chapterek.

Update2: egy kis apróság van ami zavar, mégpedig hogy tesztelésnél csak az utolsó chapter-t teszteli, és hirtelen nem találtam meg, hogy hogyan tudnám az összeset leteszteltetni vele.

Csak emlékezetből mondom! Az arj "fejezetes" tároláskor, az újabb és újabb fejezetekben a változásokat tárolja (legalább is én így használtam).
Egyébként, nem tudom mennyiben, mennyire feladat a tömörítés, arra gondolok, hogy az arj elsődleges feladata a tömörítés, ezek a chapterek amolyan kényelmi szolgáltatások. Ilyen "chapteres" tárolást akár tar -al és rsync -el is létrehozhatsz, a sima tar ráadásul gyorsabb is lehet (persze ez függvénye a méret/CPU sebesség/diszk sebsség -nek).

Ha jól látom a -jb kapcsolót próbáld ki (jb*: select all chapter backup files).

* Én egy indián vagyok. Minden indián hazudik.

( hokuszpk | 2011. 04. 09., szo – 21:43 )

szvsz a rar tud tobb verziot tarolni. a koltozes miatt most nem tudom megnezni, de a windowsos rar-ban tuttira a backup fulon van olyan hogy aszondja 'keep previous file versions' ; akkor a linuxosban mert ne lenne ?

Ennyire szerencsére még nem épültem le :) Nálam a 3.93-as van fent, és az nem tudja (Debian stable), úgyhogy újítok egyet valahonnét.

Update: teszteltem kicsit. Fura a működése. Addig nincs gond, amíg nem használok volume-okat. Viszont amint használni kezdem, az update parancs (u) mintha belezavarodna a fájlnevekbe, felül akarja írni az új volume-ot, ahelyett hogy update-elné.

( dragi v | 2011. 04. 11., h – 00:06 )

rdiff-backup? Pythonban irt cucc, rsync libet használ a háttérben, de csak a diffet menti .gz-ben, tehát akár kézzel is visszamásolható.
Igaz alapban nem verzió, hanem dátum alapú.

Az rdiff-backup-ot és a duplicity-t ugyanaz a csóka írta (Ben Escoto, legalábbis eredetileg). Én rendszeresen az rdiff-backup-ot használom. Az azonban, ahogy említed, attribútumok alapján keresi a változott file-okat, nem tartalom alapján, illetve a mirror / növekmények integritása nincs védve az alkalmazás szintjén. Ezért ajánlottam a duplicity-t.

( mspike | 2011. 04. 11., h – 10:09 )

elokerult az svn, es a git tobbszor... ha jol tudom, ezek szoveg fileokra lettek kitalalva... nem ?