Differenciális mentés tarral

Linux-kezdő

Sziasztok!

Követekező kérdéssemmel fordulok hozzátok:

Differenciális mentést szeretnék készíteni egy mappáról a tar parancs segítségével. Mivel a mentésemet egy külső tárhelyre szeretném tenni, ezért titkosítani is szeretném, ezért célszerűnek látom "betarolni" a mentendő mappámat. Inkrementális mentést tudok vele készíteni, de jó sok google-zés után sem találtam számomra működő megoldást a differenciálissal kapcsolatban, holott több helyen is olvastam róla, hogy ez működik.

Építő jellegű válaszaitokat előre is köszönöm!

  • 8063 megtekintés

( Zahy v | 2013. 02. 14., cs – 20:42 )

első mentés:

tar c ...
touch MENTES

későbbi mentések:

tar c --newer-than MENTES ...
touch MENTES

Nincs túlbonyolítva, meg nem oldja meg azt, ha valamit pont az egyik mentés közben módosítasz (az adott fájl már le van mentve, de a mentés még nem végzett). Szóval nem kifejezetten szofisztikált de első közelítésre jó.

(Szerk: így első ránézésre olyan, mintha ilyen jellegű "newer" funkció a GNU-tar-ban nem létezne, csak a FreeBSD-féle tar-ban. De fenti több-kevesebb macerával átültethető gtar-ra is.)

Működik is, bár tényleg nincs --newer-than kapcsolóm.

~# tar -c --newer="2013-02-14 21:00" --file mentes-diff-teszt/3.tar diff-teszt/

Viszont (vagy én csinálok valamit rosszul?) ebben az esetben nem veszi figyelembe, ha törlődnek bizonyos file-ok. Esetleg meg kell adjak egy file nevet, amiben vezeti a változásokat, mint a -g kapcsolónál inkrementális mentés esetében? Vagy használjak más programot mentésre (a lényeg az, hogy a differenciákat más mappába helyezze, ne pedig a full backupomat írja felül)?

Köszönöm a segítségedet!

-N, --newer, --after-date DATE-OR-FILE
only store files newer than DATE-OR-FILE

--newer-mtime=DATE
compare date and time when data changed only

A differenciálra vonatkozó kérdésed nem értem, lehet hogy nem olvastam el elég figyelmesen. Azok a fájlok, amik közben törlődtek, nem lesznek benne de ez így jó is. A full backupodat miért írnád felül a diff. mentéssel?

Mindenféle extra nélküli megoldás.
cron.weekly = fullbackup.sh -> /backup/full/[DÁTUM(pl.2013-01-16)].tar.gz
cron.daily = diffbackup.sh -> /backup/diff/[NAPNEVE(pl.Monday)].tar.gz

Backup visszaállítása:
- full kicsomagol
- fájlok összehasonlít, ha nem létezik a diff-ben, töröl
- diff kicsomagol, létezőt felülír

\o\ |o| /o/

fájlok összehasonlít, ha nem létezik a diff-ben, töröl

szerintem nem jó meglátás, az a fájl se létezik az inkrementális archívumban, ami nem valtozott a full archiválás óta, azt pedig nem kell törölni az eredeti állapot visszanyeréséhez.

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

Jogos a két pont, ez így tényleg nem jó. Muszáj generálni egy listát az összes fájlról ami létezik a mentés időpontjában és ettől függetlenül menteni a változott fájlokat is. Én tudatlanként egy sima plaintext listát generálnék de biztos lehet valamilyen db szerű formátumba is. Tehát helyesen:
- full backup kicsomagol
- fájlokat végignéz, ha nincs a fájl a fenti megfelelő dátumú fájlistán, akkor töröl
- diff rácsomagol

\o\ |o| /o/

én a kicsomagolás + némelyek törlése methódust nem alkalmaznám a felesleges erõforráshasználat miatt.

inkább:
1: 


for file in full.tgz inc*.tgz; do
  while read filename; do
    tar xvzf $file -C ./ahova_ki_kell_csomagolni/ "$filename"
  done < ./ezeket_kell_kicsomagolni.txt
done

ez szintén erõforrásigényesebb a kelleténél, mert többször nyitja meg az archívum fájlokat.

2:
generálunk egy listát a törölt fájlokról az inkrementális archivalások elõtt: 


for file in full.tgz inc*.tgz; do
  tar tf $file | while read filename; do [ ! -e "$filename" ] && echo "$filename"; done
done | sort -u > ./torolt_fajlok.txt

és restore-nál megadjuk a feketelistát a tar-nak:
(úgy látom, sajnos fehérlistát nem kezel) 


for file in full.tgz inc*.tgz; do
  tar xvzf $file -C ./ahova_ki_kell_csomagolni/ -X ./torolt_fajlok.txt
done

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

ja bocsánat, kezel fehérlistát :)
akkor archiválás során fehérlistát generálunk: 


find ./archivalando -print0 > ./letezo-fajlok.txt
tar cvzf inc${cnt}.tgz -T ./letezo-fajlok.txt

restore-nál csak ezt kell megadni 


for file in full.tgz inc*.tgz; do
  tar xvzf $file -T ./letezo-fajlok.txt
done

azért mentségemre szóljon, hogy az exclude listát soralapú fájlként várja,
az include listát meg null-terminated sztringekként.

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

Szerintem félre értettük egymást. Következő gondom van ezzel a megoldással: amikor készítek a full backupomról egy diff. mentést, akkor azokat menti, amik újak (természetesen ez a cél), de amit a felhasználó törölt a könyvtárából, azok ugyanúgy visszaállítódnak, mert a full backupban ki lett mentve. Így az ügyfél egy időpontra való visszaálláskor jogosan teszi fel azt a kérdést, hogy mit keresnek itt ezek a fileok, mikor én ezeket már régen kitöröltem. Vagy rosszul gondolom?

( bujdi | 2013. 02. 14., cs – 22:09 )

GNU Tar esetén ez is működik:

Első mentés:
tar -g /root/backup/etc-incremental-tar-magic -cpj /etc/ |
gpg -e -r user1 -r user2 -r userN > $data/etc-initial-`date +%Y-%m-%d-%s`.tar.bz2.gpg

Inkrementális mentések esetén a fenti parancsot ismételni kell.

Ismételt backuphoz pedig a rm magic-file után full backup lesz és újra létrejön a state tracker file.

van a -G opció kicsomagoláshoz, ez törli is a fileokat.

tar xzGf full.tgz
tar xzGf incr1.tgz
tar xzGf incr2.tgz...

Én úgy csinálom, hogy minden vasárnap generálódik egy új könyvtár, ezáltal nem lesz ott .snar file, tehát full mentés hetente 1x, és közben akárhányszor ráindítom a mentést, az előzőhöz képest mennek le a változások.

Lehet trükközni, hogy a full mentés utáni .snar file-ot használod mindig referenciának, és akkor a következő mentések mindig a full-hoz viszonyulnak, így egy kicsit könnyebb visszaállítani, viszont több helyet foglal.

( bujdi | 2013. 02. 14., cs – 22:12 )

Szerk: nem olvastam el elég figyelmesen mit is kérdeztél. Mea culpa.

( dj | 2013. 02. 18., h – 12:45 )

Kicsit off.
Miért kell feltétlenül a differenciális mentés? Illetve miért jobb, mint pl. az inkrementális? Csak azért, mert egy mentésből visszaállított könyvtárban benne van egy régebben törölt fájl a kissebbik rossz, mintha pl. tőlem már kérték, hogy egy hónappal ezelőtt törölt fájlt állitsak vissza. Mivel nálam alap a több hónapra visszamenő inkrementális mentés, ezért ez nem volt gond. Mindig elmondom az ügyfélnek, hogy mit meddig tudunk visszaállítani, ehhez tartjuk magunkat.

Én abból indulok ki, hogy ha például visszamentésnél 30 inkerementumom van, akkor az összeset le kell húzzam hozzá és ráereszteni a full backupra. A másik, ha én egy hétig vállalom a visszaállítást, akkor differenciálnál nyugodt szívvel törölhetem az elavult változásokat. Nekem kényelmesebbnek tűnik így eljárni, de elfogadom az ellenvéleményeket.

Ha jo mento eszzkozod van, akkor nem kell tudnod arrol, hogy ki mit mikor huz le. En peldaul a duplicitynel csak megadom, hogy melyik fajl mikori allapotat allitsa helyre, o kitalalja, hogy melyik inkrementalis/differencialis/full mentest fogja lehuzni, kicsomagolni, es helyreallitani, nekem meg csak eszembe se kell jusson elgondolkodni rajta.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igen, pont ez az. Hányszor kellet használnod a teljes visszaállítást? Nekem még az elmúlt 1X év alatt egyszer sem, szerencsére. De olyan, hogy egy véletlenül, vagy szándékosan törölt fájlt állítsak vissza, az már többször is. Differenciális mentésnél ezt a lehetőséget feláldozod, hogy egy esetleges full recovery esetén nyerjél pár percet, órát. Persze simán lehet ez napok is, de gondolom ilyen esetekben nem a tar-ral bűvészkedünk.

Lehet tarral is buveszkedni, pl a a duplicityben pont az a csodalatos, hogy csak a megfelelo mentes megfelelo koteteit banyassza le a halorol, hogy a kert fajlt eloallitsa (nyilvan ha kotethataron van a fajl, akkor ket kotetet szed le, ha nem, akkor csak egyet)
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ha már elkanyarodtunk a tar-tól, akkor a duplicity helyett inkább rdiff-backup. Kb. fél éve váltottam rá, mert a duplicity backendek közül több egyáltalán nem működött, ami meg igen (ftp), az meg megbízhatatlan volt, ha interneten keresztül, és nem lanon kellett átzavarni.

Milyen disztro, hanyas duplicity? A 0.6.15 elotti duplicityk sajnos bugosak, utana jott be valamikor a paramikos SSH backend, illetve javult egy csomot az rsync backend is. 19-20-21 nekem csont nelkul ment SSH-n es rsync-en at is.

Az rdiff-backupot en nem szeretem oszinten szolva. Semmi baj vele, nekem ellenerzeseim vannak vele kapcsolatban, ennyi.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ubuntu 12.04 a csomagból rakott duplicityvel. Nem emlékszem, hányas verzió, de volt már benne SSH backend, csak ~200G adatnál interneten keresztül egyszer sem sikerült lefutnia, pedig több hétig próbáltam. Az ftp backend hellyel-közzel működött, kínomban csináltam egy vpn-t, és az felett használtam ftp-vel. De azért 10 alkalomból 3-szor az ftp-nek is sikerült megállnia. Amióta rdiff-backupot használok (ssh felett), mindössze egyszer nem futott le a mentés, amikor egy költözés után elfelejtettem hozzáadni az ssh kulcsot ahhoz a userhez, aki a túloldalt fogadja az adatokat.

Azt viszont el kell ismerjem, hogy a gpg-vel titkosítás / csak a kliens oldalon olvasható archívum hiányzik az rdiff-backupból. Hiába ment az ember titkosított fájlrendszerbe, az nem ugyan az.

Ezert mondtam, hogy szamit a verzio. A regebbi duplicity-k kozvetlenul az ssh programmal kommunikaltak pexpect-tel, az ujak pedig mar egy nativ pythonos implementaciot hasznalnak, ami sokkal stabilabb es sokkal masszivabb, nem hal meg. A pexpectes nekem is lutri volt, hogy lefut/nemfut, de amiota a paramiko backendest hasznalom, azota nincs gondom vele. Tisztabb, szarazabb, biztonsagosabb. :-)

Mi mondjuk nem hasznalunk gpg titkositast, de igen, a duplicitynek ez a legnagyobb elonye.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal