Backup mit UFS Snapshot

Z

zuglufttier

Well-Known Member
Ahoi,

ich habe ein System mit UFS und möchte gerne Backups machen. Folgender Befehl tut eigentlich was er soll:

Code: 
dump -C16 -b64 -0uanL -h0 -f - / | pigz --rsyncable > /tmp/root.dump.gz

Aber: Das dauert ziemlich lange, andererseits scheint es auch kaum Performance zu kosten.

Kann man das irgendwie beschleunigen ohne das System offline zu nehmen? Gibt es Alternativen (außer ZFS), um ein Backup vom kompletten System zu machen?
 
Was genau willst Du denn erreichen?
Auf /tmp wäre mir das alles zu heiß, selbst als Zwischenlagerung.
 
Das ist nur mein Test, ich würde das Backup entweder direkt per ssh transferieren oder ein entferntes Dateisystem dafür mounten.

Ich will ein komplettes Backup aus dem Live-System heraus machen. Im schlimmsten Fall kann ich dann ein frisches FreeBSD auf eine Platte installieren und einfach mit restore das Backup draufbügeln: Das System sollte dann sehr flott wieder lauffähig sein. Das ganze ist ein Rootserver, ansonsten würde ich einfach ein Backup der kompletten VM machen...
 
Du kannst dump -C 64 oder so probieren, allerdings kostet das mehr RAM für die größeren Caches. Außerdem kannst zu einen RAM Puffer zwischen dump und dein Kompressor klemmen. Da bieten sich buffer oder mbuffer an.
 
zuglufttier schrieb:
Ich will ein komplettes Backup aus dem Live-System heraus machen. Im schlimmsten Fall kann ich dann ein frisches FreeBSD auf eine Platte installieren und einfach mit restore das Backup draufbügeln: Das System sollte dann sehr flott wieder lauffähig sein. Das ganze ist ein Rootserver, ansonsten würde ich einfach ein Backup der kompletten VM machen...
Zum Vergrößern anklicken....

Ich weiß nicht, ob Du Dir damit nicht unter Umständen ins Knie schießt.
Der dump braucht Zeit und friert Dir wöhrenddessen nicht deine Dateien ein und ggf. "paßt" nachher etwas nicht.
 
Der Parameter L macht einen Snapshot des Dateisystems und sorgt dafür, dass der Snapshot am Ende auch wieder verschwindet. Das sollte also passen.

Während des Backups ist auf der Maschine fast keine Auslastung zu erkennen, werde vielleicht mal mit den Parametern spielen...
 
Man sollte nicht den Fehler machen UFS-Snapshots mit den deutlich "moderneren" ZFS-Snapshots zu verwechseln. Während bei ZFS ein Snapshot keinen Overhead hat, sind sie bei UFS verdammt teuer. Das Anlegen und Löschen dauert abhängig von der Anzahl Dateien im Dateisystem sehr lange, mit jedem Snapshot verteuern sich IO-Operationen deutlich. Darum sind insgesamt auch nur 20 Snapshots erlaubt... Ist nebenbei noch Last auf dem UFS? Dann kann es gut sein, dass der Schreibkopf Lambada tanzt, wenn es mechanische Platten sind und du daher keinen Durchsatz bekommst. Das müsste man in der Ausgabe von 'gstat' sehen können.
 
Sag du es mir :D


Prinzipiell sollte es so einfach wie möglich sein, von daher bin ich bei tar auch nicht abgeneigt.
 
Ein Snapshot stellt halt sicher, dass die Daten allesamt insoweit konsistent sind, so als hättest du den Rechner zu dem Zeitpunkt hart abgeschaltet. Ein Backup mittels tar aus dem laufenden System ergibt "irgendwas". Ein Mix aus dem was zwischen Start und Ende vom tar Aufruf so alles passiert ist.
 
-Nuke- schrieb:
Ein Snapshot stellt halt sicher, dass die Daten allesamt insoweit konsistent sind, so als hättest du den Rechner zu dem Zeitpunkt hart abgeschaltet.
Zum Vergrößern anklicken....

Zumindest zum großen Teil, ja. Wenn man z.B. einen mysql-Daemon laufen hat der auch wirklich etwas tut, ist auch ein Snapshot kein Garant für Konsistenz.

Rob
 
KobRheTilla schrieb:
Zumindest zum großen Teil, ja. Wenn man z.B. einen mysql-Daemon laufen hat der auch wirklich etwas tut, ist auch ein Snapshot kein Garant für Konsistenz.
Zum Vergrößern anklicken....

Ich weiß jetzt nicht wie weit Snapshots in UFS gehen, aber zumindest bei gewöhnlichen ZFS Snapshots ist es halt so, dass das einem Datenbank-Absturz / Power-Out gleicht. Hier sollten dann die ACID-Eigenschaften der Datenbank greifen und nach der "wieder Inbetriebnahme" sollte MySQL sein Log abspulen und die Daten wieder konsistent sein. Eben nur auf dem alten Stand dann. Mittels tar kopiert man nur irgendwas zu unterschiedlichen Zeiträumen und die Daten sind dann ggf. auch wirklich kaputt, weil Daten und Transaktions-Log nicht mehr übereinstimmen.

Gut, stimmt jetzt natürlich nur für InnoDB und Co. Wer noch MyISAM einsetzt, der legt eh keinen Wert auf konsistente Daten.

edit: Ist jetzt natürlich auch nicht soo relevant, weil man Datenbank-Backups eh anders macht als nur "Daten weg kopieren" :D
 
Ich mache so oder so von meiner Datenbank (postgresql) einen regelmäßigen Dump. Ansonsten ist da nicht viel los: E-Mail, XMPP und OpenLDAP. Ist nur eine kleine Benutzergruppe.

Aber vielleicht migriere ich auch einfach zu ZFS und nutze dann zfs send/receive...
 
-Nuke- schrieb:
.. Ein Backup mittels tar aus dem laufenden System ergibt "irgendwas".
Zum Vergrößern anklicken....

Ich wage zu behaupten, dass auch ein UFS-Snapshot - abhängig von den Services (*) auf der Maschine - 'irgendwas' nach dem Replay ergibt.

(*) Für ne sql Instanz würd ich da z.B. nicht meine Hand ins Feuer legen
 
Dürfte ich Euch noch einmal das altmodische AMANDA ans Herz legen? Das gibt es nicht nur versehentlich immer noch und bis jetzt habe ich alle Daten, die ich brauchte, dort problemlos und schnell immer wiedergefunden.
Nur ein Plug 'n' Play bare metal restore ist mir noch nie gelungen.
 
Das kannst du! Mittlerweile habe ich aber die Migration zu ZFS gemacht. Ich werde die Tage dann mal schauen wie ich mit zfs send/receive klarkomme.
 
Nuja, sind die Datenbanken überschaubar kann.man da vorher schnell nen dump von ziehen. Aber natürlich ist das dann nichtmehr so transparent, gerade wenns ums Rücksichern geht
 
Um konsistent zu recovern muss man den dump wieder einspielen. Das muss man wissen.

PS: sprich wenn du jmd den Snapshot hinlegst zum recovern ist für ihn das nicht automatisch bekannt. Er recovert den Snapshot und bekommt ggf eine inkonsistente Datenbank obwohl da noch ein konsitenter Dump rumläge.
 
Ich wollte auch nur ein Beispiel geben, wie man eine Datenbank sicher snapshotten kann. :) 'pg_start_backup()' und 'pg_stop_backup()' sind alles andere als einfach anzuwenden, da das Datenbanksystem weiterläuft und die Dateien auf der Festplatte dadurch laufend verändert werden. Die beiden Low Level Funktionen stellen nur sicher, dass man mit den zwischen den beiden Aufrufen gesicherten Daten, den in der Zwischenzeit geschriebenen Write Ahead Logs und einer zugehörigen Log-Position auf einen garantiert konsistenten Zustand recovern kann. In der Praxis, wenn es nicht gerade ein Dateisystemsnapshot sein muss, gibt es robustere Wege, die wesentlich weniger Fallstricke haben. Zum Beispiel 'pg_basebackup', was grob auf dem Backup Mode aufbaut. Aber PostgreSQL Backups sind hier Offtopic und das Thema ist viel zu komplex, um es in 10 Zeilen abzuhandeln.
 
Ja, funktioniert schon mal gut! Inkrementelle Backups laufen sehr zackig und der Erstabgleich war auch harmlos, nachdem ich ein paar Berechtigungen mit zfs allow (für einen normalen Benutzer) gesetzt habe.

Muss nur noch auf der Gegenseite richtige Backups machen!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben