Distributed Network Backups

Du bist hier :

{{#youAreHere:Distributed Network Backups}}

Man sollte ja nicht alles auf dasselbe Pferd setzen. Beim Backup gilt das genauso : auch wenn man seine Daten remote speichert, stellt sich die Frage, ob es nicht besser wäre, die Daten verteilt auf mehreren Rechner zu speichern, damit man, falls ein Knoten ausfällt, trotzdem noch an alles ran kommt.

Diese Idee kam uns beim 88. LUG-Treffen.

Diese Seite soll nun das Brainstorming beherbergen.

Es wurden mehrere Ansätze in Betracht gezogen. Sie basieren alle auf FUSE und dessen Treiber, die es ermöglichen, FTP/SSH/WebDav Verzeichnisse lokal und transparent zu mounten.

Richtiges RAID Device

Fasst die o.g. Verzeichnisse zu einem RAID zusammen, welches man dann weiterverwenden kann.

Vorteile :

• würde auch LVM over RAID unterstützen
• filesystem würde einfach drüber liegen, darum kümmert sich linux selber

Nachteile :

• kann nicht über FUSE gehen, da es ein block device sein muss.
• muß als Kernel-Modul vorliegen -> root-Rechte

Pseudo-RAID5 System

FUSE Filesystem, womit man die Daten transparent über ein Paar Verzeichnisse à la RAID verteilen kann. Jedes Verzeichnis dient als virtuelle RAID-Platte.

Vorteile :

• in FUSE zu implementieren, nur User-Rechte benötigt
• Daten werden transparent verteilt, der User sieht nur ein Verzeichnis mit Dateien
• Was nun in diesem Verzeichnis liegt, und wie man die Daten speichert, darum kümmert sich wiederum der drunter liegende FUSE-Treiber

Nachteile :

• alle Platten müssen dieselbe Größe haben, zumindest wird nur die kleinste gemeinsame Größe verwendet !
• wenn man über freies Webspace geht (z.B. GMX WebDAV) bekommt man nur 1-Stellige GB. Das könnte ein Problem sein, wenn man viele GB Backup'en will -> ist das ein realistisches use model ?
• hilft nur bei Ausfall eines Knotens ! (lesend)

Implementierungsprobleme/ansätze :

• RAID5 macht ein XOR der (n-1) Blöcke und schreibt es als 1 Block auf die n-te Platte
• XOR wird alternierend auf die n Platten verteilt
• 1 Block = 1 Datei auf den Platten, deren Namen auf den Block zurückschliessen lässt -> schneller Zugriff auf die Blöcke, keine Mapping Table, Datenbank, Inode Table... notwendig.
• es gibt RAID-DP, wo man 2 XOR benutzt, und daher bei n Platten nur n-2 an Kapazität hat. Bedeutet aber, dass man 2 Platten dafür opfern muß (sprich : man benötigt schon mal 4 um zu starten)
• was ist mit timeouts beim Schreiben ? kann dann nicht sehr schnell das FS inkonsistent werden ?
• was ist mit fsck, recovery usw... ?
• was ist mit resize ?

Pseudo-RAID-1 System

Daten werden zwischen Locations gespiegelt.

Bedeutet das nicht einfach, dass man das Backup mehrmals anstossen muß um dasselbe Ergebnis zu bekommen ?

---