2022. november 30., szerda

Gyorskeresés

Én és az off-site backup

Írta: | Kulcsszavak: offsite . backup . linux . rsync . dirvish

[ ÚJ BEJEGYZÉS ]

A bejegyzés folyamatosan bővül, egyelőre nem fog kiderülni, hogy ki a gyilkos.
Version history:
2012. 10. 17 - initial release :)

Mi is ez?...

Valószínűleg nem én vagyok az egyetlen, akinek veszett már el adata hardver- vagy user hiba miatt és valószínűleg másnak is eszébe jutott már, hogy mentéseket készítsen, hogy az efféle adatvesztés lehetőségét csökkentse.

A helyi backup problémáját nagyjából megoldottnak tekintem, a dirvish minden hajnalban készít egy mentést a fontosabb dolgokról egy RAID5 tömbre. A mentést okosan csinálja, az új vagy megváltozott file-okat ténylegesen elmenti, ami meg előző nap óta nem változott, azt simán hardlinkeli az előző napi mentésből, így az ember viszonylag kis helyen tud tárolni sok-sok napi backupot, így ha egy file korábbi változata kell, azt is elő lehet halászni.

Ez a felállás önmagában kétségtelenül megvéd egy csomó veszélytől, jó pár másiktól viszont nem: egy villámcsapás, tűzeset, betörés vagy akár egy elszabadult óvódás okán simán elveszhetnek az adatok backupostól. Pont az ilyesmi kivédésére találták fel az off-site backupot, vagyis azt, hogy az adatokat elmentik egy földrajzilag távol eső helyen is.

Az ideál

Nézzük csak, hogy mit kellene tudnia egy ideális backupnak:

1. Őrizzen meg minden metaadatot, szóval stimmeljenek a file-ok dátumai, jogosultságai, a hardlinkek legyenek kemények, a softok meg lágyak.

2. Minél kisebb adatforgalom. Azt hiszem, ezt nem kell sokat magyaráznom, ADSL usereknek meg pláne nem.

3. Titkosítás. A távoli gép jelen esetben teljesen megbízható, de ha valamiért át akarnék állni pl. valami felhőszolgáltatóra, akkor ez mindjárt nem lenne igaz. A titkosítás megvéd attól, hogy mások belelássanak a file-jaimba.

4. Szignózás. Ez meg megvéd attól, hogy a file-jaimat észrevétlenül megváltoztassák.

5. Legyen maga a backup folyamat is biztonságos.

6. Minél kevesebb overhead. Nyilván. Feleslegesen minek izzadjon a gép.

7. Lehetőleg minél kevesebb, minél szabványosabb eszköz. Ez szintén akkor tud fontos lenni, ha az ember felhősödni akar.

8. Legyen robosztus. Vagyis bírja jól azt, ha menet közben történik valami gebasz.

9. Egyszerű legyen visszállítani a mentésből az adatokat.

A most

A távol eső gép jelen esetben egy általam adminisztrált linuxos gép, ami egyrészt rengeteg szempontból kényelmes, bár ez a kényelem arra indított, hogy pár dolgot elspóroljak. A konkrét rendszer nagyon egyszerű, a távoli gépen rsync-kel egyszerűen tükrözöm. Ez egyrészt működik, másrészt a fenti kilenc követelményből négyet nem teljesít.

Nincs titkosítás, nincs szignózás, mivel az rsync-nek rootként kell futnia mindkét oldalon (az én oldalamon azért, hogy el tudja olvasni azokat a file-okat is, amiket amúgy csak egy-egy user olvashat, a túloldalon meg azért, hogy be tudjá állítani az ownert meg a groupot), különösebben nem is biztonságos és rettenetes overhead-je van, mivel az rsync-nek százmillió file-ra rá kell néznie, hogy megváltozott-e (közben megszámoltam: 22 millió fájl, 170 GB) - csak ez nagyjából egy óráig tart.

Szerencsére a mérleg másik serpenyője sem üres. Az rsync tényleg csak azt küldi át, amit kell és tök szabványosnak tekinthető, szóval ezeket jó lenne megőrizni. Maga a folyamat meg elég hibaálló, ha valami miatt megszakad a mentés, akkor is csak annyi történik, hogy az utolsó nap mentése nem lesz teljes. És a visszaállítás is egyszerű, ott a file, visszamásolom, ennyi.

A terv

A terv az, hogy csinálok egy rakat file-t (a jelenlegi terv szerint konkrétan 1 GB-osakat), ezeket LVM-mel összefűzöm egy partícióvá majd azt dm-crypt-tel titkosítom és backupnál ezeket a file-okat rsyncelem.
Ez nyilvánvalóan megoldja a titkosítás problémáját. Mivel ezek a file-ok gond nélkül bárki által olvashatóakká tehetők és nem kell a túloldalon sem bizergálni az ownershipjüket, ezért el lehet tekinteni a root használatától is. Leginkább viszont arra számítok, hogy ez erősen csökkenti az overheadet, vagyis azt, amíg az rsync kitalálja, hogy mit kell lemásolnia: csak viszonylag kevés file-t kell megnéznie, hogy változtak-e (a jelenlegi terv szerint 200 db) és változás esetén csak 1 GB-ot kell átnyálaznia változás után. Ha bejönnek a várakozásaim, akkor az overhead elhanyagolhatóvá válik.
Mivel a mentendő file-ok száma kezelhetőre csökken, ezért a szignózás is megoldható, pl. crontabból simán lehet mindegyikhez generálni egy szignót (amit csak akkor kell update-elni, ha a file is megváltozik).

Problémák a tervvel

A legfontosabb probléma a hibatűrés: ha valami miatt megszakad a szinkronizálás, akkor ott állok egy használhatatlan backuppal, hiszen a file-oknak, amiknek egy egységes file-rendszert kellene kiadniuk, az egyik fele még a tegnapi, a másik fele meg a mai állapotot tükrözi, azt úgy nem nagyon fogom felmountolni, vagy ha mégis, nem lesz benne sok köszönet. Márpedig ez fontos probléma, hiszen ha pl. valamiért olvashatatlanná válik egy file, akkor a backup meg fog szakadni (vagyis pont akkor nem lesz működő backup, amikor szükség lenne rá).

A megvalósítás

1. Először is legenerálom a file-okat. Gyárthatnék "üres" file-okat is, azonban úgy döntöttem, hogy ha már úgyis fel akarom használni azt a helyet, akkor inkább feltöltöm nullával, így talán kevésbé fragmentálódnak.

for a in $(seq -w 0 199) ; do echo $a ; dd if=/dev/zero of=dirvish_0$a.img bs=16K count=65536 ; done

... (to be continued)

Hozzászólások

(#1) dabadab


dabadab
titán

Pop! Goes My Heart :)

DRM is theft

(#2) bambano


bambano
titán

jesszus!
addig nem fognék neki egy ilyen megoldásnak, amíg nem tudom biztosan, hogy az lvm tetszőleges darab fájlon is működik. 170 gigát minimum 170 darab egy gigás fájlba tudsz tárolni, szóval ezen agyalni kellene.

A másik nagy kérdés, hogy mit akarsz backupolni? mert szövegfájlok backupolására svn.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

(#3) dabadab válasza bambano (#2) üzenetére


dabadab
titán

"addig nem fognék neki egy ilyen megoldásnak, amíg nem tudom biztosan, hogy az lvm tetszőleges darab fájlon is működik."

Megprobaltam utananezni, ugy tunt, hogy nincs erre vonatkozoan semmi korlat, az LVM1-ben volt annyi, hogy maximum 65536 PE lehetett egy logical volume-ban. Egyebkent az jobban aggasztott, hogy mindegyik file-nak kulon loopback device kell, de ugy tunt, hogy ez se problema.. Ha minden jol megy, akkor ma este ugyis osszerakom az LVM-es reszt es akkor ki fog derulni, hogy beleszaladok-e valami korlatozasba.

"A másik nagy kérdés, hogy mit akarsz backupolni?"

Mindenfelet, pl. a komplett /home-ot.

DRM is theft

(#4) bambano válasza dabadab (#3) üzenetére


bambano
titán

ez tipikusan egy olyan dolog, amiben nem hinnék el semmit a doksinak. amíg nem teszteltem rogyásig a megoldást, addig nem fogadnám el. abban légy teljesen biztos, hogy ezzel az ötlettel te most kimész a szokásos felhasználási körből és olyat fogsz csinálni, amit szerintem eddig még senki. kicsit egyedül leszel, mint egy úttörő a marson.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

(#5) bambano válasza dabadab (#3) üzenetére


bambano
titán

a mit akarsz backupolni kérdés inkább fájltípusra vonatkozik. binárist? szöveget?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

(#6) dabadab válasza bambano (#5) üzenetére


dabadab
titán

Binarist meg szoveget vegyesen. Pl. ott van a komplett csaladi fotoalbum, a komplett levelezes, forrasok, pdf-ek, doc-ok, c64-es disk image-ek :), tenyleg mindenfele.

DRM is theft

(#7) lapa


lapa
veterán

szerintem az rsync nem nyálaz végig minden fájlt, vagy legalábbis nem tudom, de rövid időtávon belül nem.

100 millió fájlból gondolom csak lehetne szűrni, mi az ami és ami nem változik nap, mint nap. nem tudom elképzelni amúgy mi az a 100 millió, de akkoris. nekem a 900 giga átlagos személyes cuccokkal végez 2-3 perc alatt, úgy hogy erőltetve van az elején fájllista készítés. télleg nem tudom mi lehet nálad, ha egy linux is csak 1-200 ezer fájl. most megnéztem, az összes privát fájlom 120.000. és ebben benne vannak a privát emailek fájlonként (a gmail egészben...) meg minden.

ha már mindenképp titkolni és felhős gépen, akkor szerintem rsync incrementál | gpg --> feltőt. de szerintem ez sehogyse jó, mert pl nekem a virtualbox image-em ilyenkor 1:1 újra felkerül, hatalmas overhead. valahogy a tárolót kéne eleve titkosítottá tenni, gondolom lehet távoli dm-crypt-et csinálni, nem? akkor transzparens.

de én még mindig truecrypt, ami távolinál nem biztos hogy műx.

nemtom, valahol olvastam, hogy ez az rsync inkrementálos megoldás nem kezeli le jól a jogosultságokat (merthogy hardlinkelsz). aztán lehet ezt benézem csak, vagy nem erről van szó.

de én csak ugatom a témát, ezt tudjátok.

(hozzáteszem én xp-s offline files-on nőttem fel és az tényleg nyálazott ezerrel, azért nyaralásonként be van zippelve a fotóalbum, mert minek küzdjön vele a gép).

[ Szerkesztve ]

(#8) bambano válasza lapa (#7) üzenetére


bambano
titán

rsync: beállítástól függ, vagy csak az utolsó módosítás/kreálás dátumát nézi végig és az alapján dönt vagy mondhatod neki, hogy csináljon md5-ös checksumot minden fájlról és az alapján döntse el, hogy változott-e valami.

ha titkosítani kell, akkor lehet, nem az rsync a jó megoldás, hanem tar vagy hasonlók. a tarfájlt már lehetne titkosítani.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

(#9) lapa válasza bambano (#8) üzenetére


lapa
veterán

mondjuk szerintem normál esetben nem kell a hash, nem is default.

ja, valahogy úgy képzeltem, hogy a diffet-incrementet képezni rsynccel, aztán tar és gpg.

az xp saját titkolója volt jó, az tényleg file szinten titkolt. perszer ahhoz kéne egy online titkolt backup is a diffhez.

de nekem még mindig az ilyen extra fájlok problémásak, mint virtuáldiszk vagy thunderbird mail konténer. ott busz mindent, még mindig egyetlen esélyed egy távoli rsync szellem, hogy az ilyen giga fájloknak csak a dirib-darab checksumjait hasonlítsa a hálón át, aztán meg csak a különbséget küldje át.

többek közt ezért maildirelek mbox helyett a saját szerveren, elég szívás még lokál neten is, míg a thunderbird gmail local cache átdarál x gigát 2 új spam miatt.

[ Szerkesztve ]

További hozzászólások megtekintése...
Copyright © 2000-2022 PROHARDVER Informatikai Kft.