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)