ntfs particio mentese (ext3-ra) rdiff-backup-pal

Sajnos nem tapasztalatból beszélek, így annak tudatában írom, hogy jó eséllyel teljesen haszontalan a hozzászólásom.

Mivel legfontosabb kritériumnak azt találom, hogy a backup tökéletes hűséggel készüljön, azért én a backup készítését mindenképpen arra az oprendszerre bíznám, amely elsődleges gazdája az NTFS partíciónak. A backup-ra az rdiff-backup-ot használnám, ha jól tudom, elég jól követi az oprendszerfüggő file-tulajdonságokat. Annak érdekében, hogy a fogadó oldalon ne vesszenek el az rdiff-backup beállításai, a fogadó oldalt egy távoli disk image-nek választanám.

Vagyis az workstation XP-n futtatnám az rdiff-backup-ot, a target könyvtár pedig egy loop device-on leledzene, amely loop device alatti file egy sambá-n keresztül share-elt file lenne a linuxos gépről. Most már csak az a kérdés, hogy hogyan tudsz loop device-ot mount-olni XP alól.

Erre én a truecrypt-et ajánlom, határozottan nem titkosítási/hitelesítési szempontból (a doksi ui. kifejezetten említi, ha jól emlékszem, hogy ha valaki egy file based container-hez rendszeresen hozzáfér, akkor szivárog az információ, mert láthatók, hogy mely blokkok változnak az idő folyamán). Igazság szerint azt ajánlanám, hogy a félreértés elkerülése végett null cipher-t válassz, de olyat asszem nem tud. Ennek a megközelítésnek az is a haszna, hogy a truecrypt NTFS image-et a linuxos gépről is minden további nélkül fel tudod mount-olni TC + ntfs-3g segítségével. A jogosultságok nem lesznek hibátlanok, de csak olvasásra jól jöhet.

Valahogy így képzelem el a lépéseket:

1. Megcsinálsz egy szabvány samba share-t; csak arra figyelj, hogy feltétlenül támogasson 64 bites file offset-eket és méreteket. Gondolom ez nem lehetetlen.
2. Feltelepíted a truecrypt-et a workstation XP-re.
3. Az XP-n a TC-ből létrehozol egy file based container-t, melyet a samba share-re raksz. Feltétlenül NTFS file-rendszerrel formázd meg. A formázás várhatóan nagyon hosszú ideig fog tartani.
4. Az XP-n a TC-ben felcsatolod a file based container-t valahova.
5. Az rdiff-backup-ot az XP-n futtatod a helyi diszk és a TC volume között.

A titkosítás itt inkább hátrány, mint előny (formázás időigénye, titkosítás CPU igénye, hamis biztonságérzet); a TC-t azért ajánlom, mint említettem, mert az image file így könnyen nézegethető a linuxos szerver parancssorából is.

További hátrány, hogy ha a samba share valamilyen (pl. hálózati) okból lerohad backup közben, akkor egy inkonzisztens (és titkosított :)) NTFS file-rendszer lesz a kezedben, vagyis formázhatsz újat és kezdheted előről a backup-ot. Ha nem loop device-on belül dolgoznál, hanem a TC-t kidobnád és a samba-ra bíznád az egyes file-ok különálló megírását (vállalva ezzel, hogy néhány file-attribútum esetleg elveszik), akkor hálózati hiba esetén nem a linux filesystem-ed válna inkonzisztenssé, hanem "pusztán" az rdiff-backup struktúrája. Ebből (feltételezhetően) könnyebben vissza tudnál állni; remélhetőleg egy megszakadt rdiff-backup a korábbi, sikeresen commit-olt futások eredményét nem rontaná el, vagyis nem vesztenéd el azonnal a teljes backup-ot plusz history-t, csak amit éppen csinálsz. Hogy innen aztán meg tudod-e kísérelni ismét az rdiff-backup-ot, vagy annyira felborul a struktúrája, hogy mindenképpen újat kell kezdened, azt nem tudom.

Tehát a TC mellett szól a forráshű backup, ellene szól az erőforrásigény és a backup folyamat törékenysége. A samba pont a fordítottja. A platformfüggetlen elérhetőség elvileg mindkét esetben biztosított.

Van még egy olyan lehetőség is, ha van helyed dögivel, hogy a TC-vel egy lokális file based container-be dolgozol, vagyis munkaállomáson belül végzed az rdiff-backup-ot (ami így nagyon kicsi eséllyel borul csak meg); ezután lecsatolod a kötetet TC-ből, majd rsync-kel átnyomod a távoli gépre (ez akárhányszor lerohadhat, könnyedén újra tudod indítani). Ennek a kezdeti formázási erőforrásigénye is lényegesen kisebb (bár a legelső rsync-et nem úszod meg). A nagyobb rendelkezésre állásért (adatbiztonságért) itt több hellyel fizetsz. (Adatbiztonság "data safety" értelemben, nem "data security" értelemben, mivel nem rosszindulatú, intelligens ellenfeled van, hanem természeti.)