Komplettes konsistentes Backup laufender Jails

Rakor

Rakor

Administrator
Teammitglied
Hallo zusammen,

vor größeren Umbauten sichere ich meine Jails hin und wieder per tar um im Notfall auf den alten Stand zurück wechseln zu können. Dafür halte ich die Jails zunächst an um ein konsistenten Abzug zu erhalten. Das funktioniert zwar recht sauber, aber je nach Größe der Jail bekomme ich da unnötige (?) Downtimes. Lieber wäre es mir die Jail zu sicher ohne sie anhalten zu müssen.
Mit ZFS snapshots funktioniert das sicherlich wunderbar, aber da die Kiste auf absehbare Zeit kein ZFS erhalten wird ist das keine Lösung für mich. UFS-Snapshots sind, so meine ich, immernoch kaputt (oder gibt es da Neuigkeiten?) wenn in Kombination mit Journal.

Wie macht ihr das?

Grüße
 
Auch wenn die gesammte Kiste nicht auf zfs migriert wird, könntest du die Jails doch in ZFS container packen.
Also eine extra Partition als ZFS pool nutzen oder eine Datei dafür nutzen und in dieser einen ZFS Pool anlegen.
Wie letzteres in große Umgebungen skaliert kann ich nicht sagen, bei mir hatte ich im kleinen Rahmen keine performance Einbußen.
ZFS und UFS darf man mittlerweile wohl auch offiziell gemischt betreiben, ich habe da beim Testen vor meiner Migration keine Probleme (damals sollte man das lieber nicht machen).

Wie schnell und gut dump funktioniert, welches sterum vorgeschlagen hat, weiß ich nicht, da ich es nie genutzt habe.
 
Ein ZFS Snapshot allein schützt aber nicht vor inkonsistenten Daten bei einer DB! Da muss man schon noch, bei MySQL z.B. ein "FLUSH TABLES WITH READ LOCK" absetzen.
 
foxit: Doch ein ZFS Snapshot ist konsistent. Sollte deine MySQL DB in nur einem Dataset liegen ist sie konsistent, wenn du MySQL nicht verstellt hast auch wenn du aus dem Log wiederherstellen musst.
 
Crest schrieb:
Sollte deine MySQL DB in nur einem Dataset liegen ist sie konsistent, wenn du MySQL nicht verstellt hast auch wenn du aus dem Log wiederherstellen musst.
Zum Vergrößern anklicken....

Das kommt aber darauf an, welches Backend man bei MySQL nimmt. MyISAM z.B. entspricht nicht komplett dem ACID-Prinzip.

Ich für meinen Teil schicke die entsprechenden "sync" Befehle (wie auch immer die aussehen) an die entsprechenden Dienste und mache dann ein Snapshot mit ZFS.
 
Kommt auf den Dienst um dessen Downtime es geht. Du könntest die kritischen Dienste (z.B. DB) zur Replikation in identischen Jails clustern, dann müsstest Du fürs Backup nur eine davon runterfahren und sichern. Unkritische Entry-Points, z.B. einen Apache als SW-Loadbalancer kannst Du eigentlich auch live sichern - da passiert nicht viel und die runtime-Daten kannst Du ja aus dem Backup raushalten. Die zweite Charge kannst Du als aktiv/passiv Variante auch erst vorm Backup hochfahren, um im Normalbetrieb Resourcen zu sparen. Ist halt aufwändig und fehleranfällig, daher nur bedingt automatisierbar :)
 
foxit schrieb:
offtopic sorry:

Hast du dazu mehr Informationen? Würde ich gerne mal genauer anschauen.
Danke
Zum Vergrößern anklicken....

Ich überlege mir so, dass eine DB ja von sich aus immer sicherstellen sollte, "zum FS hin" konsistent zu sein, also z.B. bei Transaktionen. D.h. einer guten DB, bei der sich auch das FS drunter "ordentlich" verhält, sollte man den Rechner unterm Arsch wegziehen können und trotzdem zumindest keine Korruption erhalten.

Und wenn das alles gegeben ist, dann heißt das automatisch, dass man zu beliebiger Zeit einen Snapshot im FS machen kann, ohne dass die DB kaputtgeht. (Edit: wenn man alles nach dem Snapshot wegwirft natürlich.)
 
In der Theorie stimmt das. In der Praxis gibt es allerdings einige Dinge zu beachten:
- Im Moment des Snapshots sind die Datenbankdateien nicht konsistent, die Konsistenz ergibt sich erst durch Anwenden des Undo- / Redo-Log. Je nach Abstand zwischen den Checkpoints, der Anzahl Transaktionen und der verwendeten Datenbankengine kann das nach dem Restore notwendige Recovery unerträglich lange dauern.
- Nicht alle Datenbanken sind atomar konsistent. Die noch immer extrem weit verbreitete MyISAM-Engine von MySQL wurde schon als Beispiel genannt.
- Je nach Anwendungsfall kann es durchaus Sinn haben die Datenbanken abseits des Jails noch einmal getrennt zu sicher. Mal wild um mich geschossen z.B. per WAL-Archive bei Postgresql, mysqlhotcopy bei MySQL und so weiter.
 
Wer MyISAM seine Daten anvertraut dem sind sie halt nicht wichtig genug sie in einer ordentlichen Datenbank zu hinterlegen.
 
Also hier wird im Dritten Punkt grob erklärt warum ZFS snapshots immer konsistent sind. Das hier eine Datenbank im spiel ist war anfangs nicht erwähnt, dabei könnte es natürlich schon zu Inkonsistenzen kommen wenn Daten in mehreren Tabellen geschrieben werden o.ä.. Da kann man wenn es wirklich wichtig ist ein konsistentes Backup zu haben entweder einen Zeitpunkt ermitteln zu dem nichts geschrieben wird (ein Snapshot dauert bei 3 TB ca 1 Sekunde) oder die DB unterstützt etwas wie einen Backupmodus bei dem sie die Daten kurzzeitig im RAM behält o.ä. dann nutzt man eben diesen. Ich habe früher(pre ZFS) immer meine Datenbank per Tar gesichert und beim Recovern oder aufsetzen eines neuen Servers nie Probleme gehabt die DB wieder in gang zu bekommen, die Daten sind heute immer noch sauber. Ich habe mich auch mit der tar methode sicher gefühlt, snapshots sind aber definitiv besser und beim nächsten umbau werde ich mal schauen wie ich da noch sowas wie einen Backup modus hin bekomme evtl. so
 
Nuja also aus einer Datenbank zieh ich vorher schon einen Dump... Zugegeben sehe ich da sqlite-Datenbanken da etwas unkritischer.. Warum auch immer.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben