Backup auf kleinere Ziele verteilen

[TRex]

Ich würde gerne ein etwas größeres Raid(-5) auf kleinere Platten sichern. Während ich mir auf dem Raid dank der Größe über Partitionierung keine Gedanken machen muss, wird das beim Backup plötzlich doch wieder zum Thema... was ich gerne hätte (und damit begründet sich das Problem):

1. wahlfreien/partiellen Zugriff auf die gesicherten Daten (wenn mein Raid steht, wäre es nett, nicht erstmal genug Platz für alles zusammen bereitstellen zu müssen)
2. keinen USB-Raid-Verbund
3. keinen Totalausfall, wenn eine der USB-Backup-Platten stirbt (sowas wie tar und split - geht auch gegen 1.)
4. anvisierter Backupmodus für mich ist eigentlich eine mehr oder weniger exakte Kopie der Daten, keine inkrementellen Backups. Veraltete, also auf der Quelle gelöschte Dateien können/sollen vom Platz her nicht ewig bleiben - zumindest kann ich keine drei full-backups speichern.

Am liebsten wäre mir, wenn ich (sowas wie) rsync dazu nutzen könnte. Also einfach die Dateien auf die Laufwerke verteilt - irgendwo sind dann eben mal Ordner leer und man muss im sync.log suchen, auf welcher Platte die nun liegen... zumindest wäre das so vorstellbar von meiner Seite. Mag sicher einige konzeptionelle Probleme beherbergen, hab das noch nicht weiter verfolgt.

Mit duplicity hab ich schon ein wenig Erfahrungen (kleinere Backups), und das multi-Backend [1] könnte eventuell sein, was ich suche (ich kann einzelne Dateien/Verzeichnisse extrahieren - aber die Rahmenbedingungen mit dem multi-Backend sind unklar). Notwendiger Modus wäre meinem Verständnis nach "stripe", und ich bin aber nicht sicher, ob einzelne Dateien über destinations hinweg gesplittet werden (evt nur wenn nirgends mehr zusammenhängend Speicher verfügbar ist?). Zur Not könnte ich natürlich mal mit ein paar kleinen tmpfs-mounts experimentieren..

Ich nehme einfach an, dass das Grundproblem nicht sehr trivial ist, auch im Falle von geänderten Dateien (Datei wächst, passt nicht mehr aufs Laufwerk - verschieben?), weswegen ich auf duplicity gekommen bin. Vielleicht hat ja hier schonmal jemand ähnliche Backup-Probleme gelöst.. Input ist willkommen.

[1] http://duplicity.nongnu.org/duplicity.1.html#sect18

[schwedenmann]

Hallo



Wie oft soll denn das backup gemacht werden und über wieviel Terrabyte reden wir hier ?

Dein Hauptproblem scheint ja wohl die Größenbegrenzung des backups des Zielmediums(medien) zu sein.

ich habe gerade mal kurz ins Manual von Bareos, das scheint Zielgrößen als Vorgabne zu akzeptieren.


ne andere Möglichkeit , (wohl von hinten ins Knie geschossen), vorrausgesetzt du mußt nicht jeden Tag ein backup machen, wäre dar (kann Archive splitten) erstellt zwar Archive, aber man kann die Kompression auschalten, bzw. nicht archivieren, du willst ja kein komprimiertes Archiv, wenn ich dich richtig verstehe.


mfg
schwedenmann

[TRex]

Bisher hab ich mein Backup täglich mit rsync -au gemacht. Das hat mir ermöglicht, dass ich die Platte im Fehlerfall einfach bis zur Reparatur des Raids verwenden kann, ohne irgendwas irgendwo entpacken zu müssen. Wenn das wegfällt, ist die nächste Hürde der Datenverlust aller Daten bei Verlust eines einzigen Teilvolumes.

Prinzipiell will/muss ich nicht komprimieren - wenn das als Bonus ohne Abzüge daherkommt, nehm ichs mit. Ich seh aber derzeit nicht, wie "Zusammenpacken in ein großes etwas" (tar/dar/... 90% aller backupsoftware) und dann splitten/komprimieren auch nur ansatzweise so gut ist wie direkter Zugriff auf eine rsync-Kopie, die direkt auf einem Dateisystem liegt.

Verstehst du, was & warum ich das so will? Wenn ich auf mein wichtigstes Kriterium verzichte, erweitere ich meine potentielle Auswahl an Software auf ein paar hundert Programme, auf Kosten dessen, dass ich bei einem defekten Backupvolume (evt nur ein Bitkipper) in die Röhre schaue (alles weg ist) und vielleicht sogar das Backup nur als Ganzes wiedereinspielen kann. Aktuell ist da dann nur eine einzelne Datei beschädigt.

[schwedenmann]

Hallo


@TRex

Verstehst du, was & warum ich das so will? Wenn ich auf mein wichtigstes Kriterium verzichte, erweitere ich meine potentielle Auswahl an Software auf ein paar hundert Programme, auf Kosten dessen, dass ich bei einem defekten Backupvolume (evt nur ein Bitkipper) in die Röhre schaue (alles weg ist) und vielleicht sogar das Backup nur als Ganzes wiedereinspielen kann. Aktuell ist da dann nur eine einzelne Datei beschädigt.

ist mir schon klar, nachdem du tar und Konsorten eine Absage erteilt hast, nur dann wird dein Kriterium (max. Zielgröße darf nicht erreicht werden) schwer zu erfüllen sein. rsync hat nativ keinen Schalter dafür und ob das mit dublicity, rsnapshot und Konsorten geht


mfg
schwedenmann

[TRex]

Ein kleines Stück Hoffnung hab ich mit einem dateisystembasierten Verbund - also sowas wie glusterfs. Ich hab natürlich keine Ahnung, ob sowas [1] funktionieren könnte - ein Dateisystem weiß immerhin, was eine Datei ist und kann entscheiden, wo der Block geschrieben wird (statt wie zB Raid-0 wahllos zu verteilen). Interessant wirds natürlich, was passiert, wenn so ein Block plötzlich nicht mehr da ist. Aber das hab ich im Eingangspost ja bereits beschrieben.

Bis dahin hab ich drei Optionen:

1. selbst "partitionieren" und manuell entscheiden, was wo hin gesichert wird
2. quasi aufgeben und bacula verwenden (immerhin besser als tar - duplicity kanns auch nich)
3. Bucket-Problem selbst lösen (hab ja sonst nix zu tun...)

Bis mir (oder wem anderen) was einfällt, bleib ich bei 1. und halte mir ein paar 5,10,20 MB loop-devices zum rumspielen bereit..

[1] http://www.das-werkstatt.com/forum/werk ... =24&t=2079

[inne]

Ein kleines Stück Hoffnung hab ich mit einem dateisystembasierten Verbund - also sowas wie glusterfs.

Sowas sollte auch mit LVM gehen. Eine VG bzw. LV kann über mehrere PV gehen.

Nun bin aber auch wieder raus, aus dem Thema.

[TRex]

Klingt auch sehr nach meinem Fall: http://serverfault.com/questions/222000 ... a-recovery

(Mit nem anderen Ansatz)