bacula vs. selbstgestrickte Scripts

16/02/2014 - 05:05 von Peter Mairhofer | Report spam
Hi all,

Ich verwende einen seit Jahren erweiterten Satz an eigenen Skripten die
von cron aufgerufen werden fuer die Datensicherung eines Servers mit
virtuellen Maschinen (dzt. OpenVZ).

Es besteht aus einem Framework von bash Scripten, die taeglich,
woechentlich und monatlich per cron ausgefuehrt werden und
administraktive Aufgaben durchfuehren wie das Aus-/Einschalten von
Zielmaschinen, mounten von Dateisystemen incl. Crypto, Senden von Status
nach nagios oder erstellen von ZFS Snapshots ueber SSH.

Die aktuelle Strategie ist wie folgt:

Taeglich
=
* Sicherung des "/" des Hauptsystems per SSH auf ZFS dataset (FreeNAS)
* Sicherung von /etc, mysqldump und die Datenverzeichnisse der Container
(z.B. /etc, /var, /home, ...) auf einen exportierten iSCSI Container
(zVol). Dieser ist mit dm-crypt clientseitig (!) *verschluesselt*. Nach
der Sicherung wird ein ZFS *Snapshot* erstellt.
Vorteile: Mehrere Versionen, die aus einem gemeinsamen Speicherpool
kommen (keine Platzverschwendung)
* Sicherung von des Systemsteils der VZ Container per SSH auf ZFS dataset
* Sicherung von Benutzerdaten ebenfalls auf zVol auf exportierten iSCSI
container, verschluesselt und taeglicher Snapshot

Woechentlich
==
* Replikation des Gesamtsystems (excl. Userdaten) auf einen identen
Backupserver. Falls der erste abraucht kann der zweite sofort den
Betrieb aufnehmen

Monatlich
==
* Sicherung grosser Multimediadaten per SSH auf ein ZFS dataset


Die Sicherung ist sehr optimiert und sehr stark an meine Anforderungen
angepasst: Durch ZFS Snapshots stelle ich eine "Archivfunktion" sicher.
Dies geht solange bis der Speicherplatz einfach voll ist und ich kann
mich flexibel alter Versionen entledigen, so dieser ausgeht.
Durch ZFS zVols und Datasets wird kein Speicherplatz verschenkt: Die
Bloecke kommen alle aus einem gemeinsamen Pool. Sensible Daten werden
direkt clientseitig verschluesselt. Dateisysteme mit ACLs werden direkt
per iSCSI angesprochen um keine Daten zu verlieren. Systemdaten werden
komprimiert gespeichert (ueber ZFS).
Die ZFS Zielpools sind natuerlich nach "Wichtigkeit" gestaffelt und
haben zufaetzlich zraid1 (RAID5) fuer die wichtigen Daten oder gar nicht
fuer die "normalen".

Das wichtigste fuer mich dabei ist Flexibilitaet, "Archivfunktion",
keinen Speicher zu verschenken (d.h. alte Versionen teilen sich
gemeinsamen Pool) und eine woechentliche Spiegelung die sofort
einsatzbereit ist.

ABER

Das System ist komplex und ich durchschaue es nicht mehr wenn ich 6
Monate nicht draufschau. Es sollte eigentlich als "Setup-and-Run"
laufen, da ich nicht mehr viel meiner Zeit in meinen Server investiere.

Jetzt fuerchte ich mich wirklich vor dem GAU: Alles ist irgendwie
"verstreut" und ich wuerde wahrscheinlich stunden fuer die
Rekonstruktion benoetigen.

Auch das Wiederherstellen einfacher Dateien aus dem Archiv hat Huerden
(schon passiert): Backupgeraet einschalten, wahllos ZFS Snapshot
auswaehlen, muehevoll per iSCSI exportieren. Manuell mounten, cryptsetup
ausfuehren, etc, schauen ob die Datei in der gewuenschten Version
enthalten ist.


Deswegen ueberlege ich auf bacula umzusteigen. Allerdings befuerchte ich
dass es sehr starr ist.

Fuer Leute mit bacula Erfahrungen: Kann man das komplette beschriebene
Szenario auf bacula abbilden? Was geht/was nicht? Gibt es alternative
Ansaetze falls bestimmte Szenarien nicht funktionieren?


LG
Peter
 

Lesen sie die antworten

#1 Uwe Scholz
18/02/2014 - 16:19 | Warnen spam
Hallo Peter,

Ich habe Bacula vor ein paar Jahren in meiner alten Arbeitsgruppe für
etwa 10 Arbeitsplatzrechner in der Uni eingerichtet und betreut. Die
Backupfiles wurden von einem eigens eingerichteten Backup-Rechner auf
Platte gespeichert und dieses dann nochmal als Sicherung auf einer
externen Netzwerkfestplatte. Wenn du an meiner Kurzanleitung (pdf)
interessiert bist, kann ich dir diese gerne zukommen lassen. Natürlich
werden aber nicht alle von dir gewünschten Punkte dort beschrieben. Ein
richtig gutes Buch über Bacula gibt es übrigens im Fachhandel von
Philipp Storz - Bacula (Open Source Press, Juni 2012).


Peter Mairhofer writes:
[...]

Die aktuelle Strategie ist wie folgt:

Taeglich
=>
* Sicherung des "/" des Hauptsystems per SSH auf ZFS dataset (FreeNAS)
* Sicherung von /etc, mysqldump und die Datenverzeichnisse der Container
(z.B. /etc, /var, /home, ...) auf einen exportierten iSCSI Container
(zVol). Dieser ist mit dm-crypt clientseitig (!) *verschluesselt*. Nach
der Sicherung wird ein ZFS *Snapshot* erstellt.
Vorteile: Mehrere Versionen, die aus einem gemeinsamen Speicherpool
kommen (keine Platzverschwendung)
* Sicherung von des Systemsteils der VZ Container per SSH auf ZFS dataset
* Sicherung von Benutzerdaten ebenfalls auf zVol auf exportierten iSCSI
container, verschluesselt und taeglicher Snapshot

Woechentlich
==>
* Replikation des Gesamtsystems (excl. Userdaten) auf einen identen
Backupserver. Falls der erste abraucht kann der zweite sofort den
Betrieb aufnehmen

Monatlich
==>
* Sicherung grosser Multimediadaten per SSH auf ein ZFS dataset



zunàchst denke ich, dass deine oben beschriebene Strategie nicht sehr
komplex ist. Bacula könnte daher tatsàchlich das Mittel deiner Wahl
sein.

Die Sicherung ist sehr optimiert und sehr stark an meine Anforderungen
angepasst: Durch ZFS Snapshots stelle ich eine "Archivfunktion" sicher.
Dies geht solange bis der Speicherplatz einfach voll ist und ich kann
mich flexibel alter Versionen entledigen, so dieser ausgeht.
Durch ZFS zVols und Datasets wird kein Speicherplatz verschenkt: Die
Bloecke kommen alle aus einem gemeinsamen Pool. Sensible Daten werden
direkt clientseitig verschluesselt. Dateisysteme mit ACLs werden direkt
per iSCSI angesprochen um keine Daten zu verlieren. Systemdaten werden
komprimiert gespeichert (ueber ZFS).
Die ZFS Zielpools sind natuerlich nach "Wichtigkeit" gestaffelt und
haben zufaetzlich zraid1 (RAID5) fuer die wichtigen Daten oder gar nicht
fuer die "normalen".

Das wichtigste fuer mich dabei ist Flexibilitaet, "Archivfunktion",
keinen Speicher zu verschenken (d.h. alte Versionen teilen sich
gemeinsamen Pool) und eine woechentliche Spiegelung die sofort
einsatzbereit ist.

ABER
>
Das System ist komplex und ich durchschaue es nicht mehr wenn ich 6
Monate nicht draufschau. Es sollte eigentlich als "Setup-and-Run"
laufen, da ich nicht mehr viel meiner Zeit in meinen Server investiere.

Jetzt fuerchte ich mich wirklich vor dem GAU: Alles ist irgendwie
"verstreut" und ich wuerde wahrscheinlich stunden fuer die
Rekonstruktion benoetigen.

Auch das Wiederherstellen einfacher Dateien aus dem Archiv hat Huerden
(schon passiert): Backupgeraet einschalten, wahllos ZFS Snapshot
auswaehlen, muehevoll per iSCSI exportieren. Manuell mounten, cryptsetup
ausfuehren, etc, schauen ob die Datei in der gewuenschten Version
enthalten ist.


Deswegen ueberlege ich auf bacula umzusteigen. Allerdings befuerchte ich
dass es sehr starr ist.

Fuer Leute mit bacula Erfahrungen: Kann man das komplette beschriebene
Szenario auf bacula abbilden? Was geht/was nicht? Gibt es alternative
Ansaetze falls bestimmte Szenarien nicht funktionieren?


LG
Peter



Zwar ist der Grad der Spezialisierung, den du als nàchstes in deinem
Post erwàhnst schon beachtenswert. Allerdings kannst du mit Bacula gut
Einfluss auf die Speicherdauer von alten Backups und viele, viele andere
Dinge nehmen. Ich denke, du wirst dich daher mit der Dokumentation von
Bacula nàher auseinander setzen müssen, um zu entscheiden, ob du es
nutzen willst, oder nicht.

Bacula-Backups können natürlich gepackt werden, um Speicherplatz zu
sparen. Verschlüsselung geht auch. Lies dazu einfach mal hier weiter:
http://www.bacula.org/de/dev-manual...selun.html Selbst
habe ich Verschlüsselung in Bacula jedoch nie verwendet und kann daher
darüber nichts sagen.

Was mir an Bacula immer sehr gefallen hat, war/ist die sehr einfache und
komfortable Datenwiederherstellung. Die scheint in deinem Fall eher
kompliziert zu sein. Es ist halt die Frage, wie schnell du eine
Wiederherstellung im Fall der Fàlle brauchst und liefern kannst. Mit
Bacula ist sowas in wenigen Minuten erledigt. Die von dir gefürchtete
"Starre" kann ich allerdings bei Bacula nicht bestàtigen. Ich empfand es
als sehr durchdachtes, flexibles System. Wobei es hier wohl auch auf
deine Anforderungen an ein Backup-System ankommt.

Die Entscheidung, von deinem jetzigen System weg und zu Bacula (oder
etwas ganz anderem) hinzugehen, kannst daher nur du selber treffen. Die
Einarbeitungszeit solltest du allerdings nicht unterschàtzen. Ich
brauchte damals gute zwei Wochen, um richtig zu verstehen, was ich
eigentlich mache und wie die einzelnen Bacula-Komponenten funktionieren.
Allerdings musste ich nebenbei noch um eine Diplomarbeit schreiben...
;-) (Du kannst ja beide Systeme auch parallel laufen lassen, bis du dich
final entscheidest.)

Viele Grüße,
Uwe

Ähnliche fragen