UFS Snapshots ja oder nein?

A

ath0

Well-Known Member
Ich denke zur zeit darüber nach, wie ich meinen Server besser aufstellen kann.
Will heißen, das ich mir das updaten erleichtern und einige prozesse Kapseln (durch Jails) möchte.

Bis jetzt habe ich einen Rechner der meinen regulären Server darstellt. Wenn ich ein Update mache (bei jedem Update) ziehe ich mir nur wichtige Konfigurationsdateien und alle Daten die von den einzelnen Diensten benötigt werden in eine Virtuelle Maschiene auf meinem Desktop. Ich packe jede nacht all diese daten in ein Archiv das ich mit tar erstelle und hohle es mir auf meinen Desktop (da ich hoffe das nie beide Rechner zur selben zeit einen Festplattendefekt haben) Weil ich bis jetzt nicht all zu viel Trafic auf meinem Server habe kann ich einen Switch zwischen den beiden Systemen noch relativ schnell und quasi ohne verfügbarkeits Loch machen.
Der wechsel von echtem Rechner nach VM wird sich nicht vermeiden lassen, aber das spiegeln des systems ist 100% verbesserungsfähig.

Jetzt meine Frage.
Kann man mit UFS (ich finde das Filesystem einfach gut und kann mich nur schwer trennen) und Snapshots täglich eine Aufnahme des systems machen und diese aufnahme quasi als neue version in meine Virtuelle maschiene "Mergen" und eine Kopie dieses Snapshots (meinetwegen als dd) irgendwo als Backup ablegen?

Das ich mir ein dd erzeugen kann habe ich schon Recherchiert mir geht es aber darum das ganze wie in einer Versionskontrolle verwalten und ablegen zu können, also nur die veränderungen. Wichtig währe mir auch, das ich in gewissen abständen auch zu alte zustände löschen kann.

Ich habe in einem HowTo gelesen, dass snapshots nach einem Neustart nicht mehr vorhanden sind. Dieser Beitrag war schon etwas älter so wie auch das FreeBSD WIKI zu diesem Thema. Ist das noch so?

Gibt es eine Aktuellere und umfangreichere Quelle bzw. könnt ihr mir anregungen geben?

ath0
 
Hiho,

ich würde Backups per dump empfehlen. Damit kannst du schöne inkrementelle Sicherungen machen.
Ich hab mir dazu ein kleines Backupscript gebaut:
http://www.denkrobat.de/wiki/index.php/Backupscript

Das ganze kannst du dann noch in die periodics bauen und schon hast du immer ein aktuelles Backup :)

edit: Das kannst du dann natürlich recht simpel in deine Virtualisierung bringen... Du könntest z.B. eine Virtuelle Maschine sichern die dein Level0-Dump enthält. Dann machst du einfach immer ne Kopie davon und musst nur noch die höheren Dumps einspielen. Das sollte recht effizient sein.
 
Zuletzt bearbeitet:
UFS2 Snapshots in FreeBSD haben einen relativ hohen Overhead. Im Gegensatz zu ZFS Snapshops sollte man davon nicht hunderte rum liegen haben. Sie sind jedoch wunderbar geeignet um konsistente Backups von gemounteten Dateissystemen mit dump(8) zu erstellen. Diese kannst du archivieren und schnell wieder einspielen.
 
Ja, nein, jein. Dafür muss man ein wenig weiter ausholen. Grundsätzlich sind UFS-Snapshots nicht mit den ZFS-Snapshots zu vergleichen. Sie sind wesentlich weniger effizient und bieten viel weniger Möglichkeiten. Sie werden erstellt, indem jede Inode des Dateisystems angeschaut wird und belegte Inode umkopiert. Das hat einige Auswirkungen:

- Da beim Erstellen und entfernen der Snapshots jede Inode angefasst wird, sind es extrem io-lastige Vorgänge. Auf meinem Desktop mit einer 2TB Partition dauert das Erstellen knappe 30 Minuten, das Löschen sogar an die 40 Minuten. Während dieser Zeit ist die Platte faktisch ausgelastet und damit weitgehend kopiert und das, obwohl sich das Erstellen eines Snapshots nur ca. 60% der verfügbaren UIO-leistung krallt. "Außfallfrei" sieht anders aus.

- Jeder Zugriff, egal ob lesend oder schreibend, bezieht mit jedem Snapshots mehr Inodes mit ein, das Dateisystem wird langsamer. Auch wenn theoretisch 2^32 Snapshots verwaltet werden können, zieht UFS bei 20 Stück die Reißleine und erlaubt nicht mehr. Er quitiert die Aufforderung einen 21ten Snapshot anzulegen mit "No space left on device" und Schluss ist.

- Snapshots belegen sehr viel Speicher, je größer die Differenz zwischen Snapshot und Dateisystem wird, umso mehr. Da UFS-Snapshots auf grob gesagt Dateiebene arbeiten (ZFS auf Blockeben), ist der Speicherverbrauch deutlich höher als bei ZFS und kann gern mal Dateisysteme volllaufen lassen.

Dazu kommt, dass Snapshots ein sehr stiefmütterlich behandeltes Thema sind. Ich habe zu FreeBSD 8.x gleich zwei Bugreports schreiben müssen und zumindest der zweite war so dumm, dass ich mich fragte, ob ich vielleicht der einzige Nutzer des Features bin:

- Wenn ufs.ko als Kernelmodul geladen wurde und "options FFS" nicht im Kernel war, ließen sich Snapshots zwar löschen, blieben aber in der Snapshotliste eingetragen. Entfernen ließen sie sich nur durch unmount und anschließendem neuem mount. D.h. nach spätestens 20 Snapshots durfte man remounten oder gleich rebooten. Toll.

- Wenn man auf einer SSD mit TRIM einen Snapshot anlegte, kam es zur sofortigen Kernelpanic. Dieser Bug fiel mir im Juli auf, fast 7 Monate nachdem TRIM in 8-STABLE gelandet war.

- Zu 9-BETA wurde von jemand anders noch ein Crash in Zusammenspiel mit Softupdate-Journaling berichtet. Das verwundert nicht, funktionierten Snapshots mit SU+J doch fast das ganze erste Jahr nicht (sie führten zur Korruption des Dateisystems) und wurden erst kurz vor Beginn der Betaphase repariert.

Aus allen hier genannten Gründen würde ich daher von UFS-Snapshots abraten. Das ist allerdings leichter gesagt als getan, ich nutze sie schließlich selbst auch. Allerdings nur noch für "fsck -B" und "dump -L". Zumindest sollte man sich klar machen, dass man vielleicht Probleme bekommen kann und größere Nachteile hat.

----

Nun zum eigentlichen Thema. Wenn du einen Snapshots per "mksnap_ffs / /.snap/snap" anlegst, erscheint er in /.snap/snap als eine ganz normale Datei. Diese Datei ist aus Systemsicht ein Image des UFS-Dateisytem und kann entsprechend behandelt werden:
- Du kannst es umkopieren: "cp /.snap/snap /mnt/mein_dateisystem.img"
- Du kannst es mounten: "mdconfig -a -t vnode -f /.snap/snap ; mount -o ro /dev/md0 /mnt"
Der einzige Unterschied zu einem echten Image ist, dass ein Snapshot (solange er nicht umkopiert wurde) nicht geschrieben werden kann. Er ist also readonly.

Was du nun mit "mergen" meinst, ist mir nicht ganz klar. Wenn du aus dem Snapshot eine VM machen willst, musst du ihn entweder umkopieren oder dir einen bösen Hack mit einem Binärdiff bauen. Beides ist nicht wirklich praxistauglich. Dinge wie "zfs rollback", also das Zurückrollen des Dateisystems auf den snapshot oder aber auch Dateisysteme aus dem Snapshot zu klonen, gehen mit UFS-Snapshots nicht.

Snapshots sind auch nach einem Reboot noch vorhanden. Seit mindestens FreeBSD 6, eventuell auch schon früher. Ich habe es eben auch extra noch mal in einer VM mit 9.0-RC1 getestet, der Snapshot verschwindet definitiv nicht.
 
@Yamagi Ich bin immer wieder über dein Wissen, insbesondere deinem Hintergrundwissen erstaunt. Danke dafür!

Danke für eure Antworten!

@Rakor Ich habe dein Backupscript kurz überflogen. Ich frage mich nur wie das funktioniert. Ist es nicht so, das dump von einem gemountetem Filesystem kein Image erzeugenkann? Wie umgehst du das?

Ja jetzt stellt sich mir die Frage wie machen das größere Anbieter von Webseiten oder Mail. Die müssen ja auch auf mehreren Rechnern (ob nun Echte oder VMs ist da ja eigentlich egal) die selben Daten vorhalten (nehmen wir z.B. Google).
Habt ihr da ne idee?

Verstehe ich das richtig, das UFS nicht während des betriebes mit einem Dump gefüttert werden kann?
Wie werden Snapshots gelöscht wenn ich Sie nicht mehr brauche?

Hat denn einer erfahrungen mit ZFS und snapshots und dem kram? Da UFS für meine zwecke anscheinend nicht taugt,

Yamagi schrieb:
- Da beim Erstellen und entfernen der Snapshots jede Inode angefasst wird, sind es extrem io-lastige Vorgänge. Auf meinem Desktop mit einer 2TB Partition dauert das Erstellen knappe 30 Minuten, das Löschen sogar an die 40 Minuten. Während dieser Zeit ist die Platte faktisch ausgelastet und damit weitgehend kopiert und das, obwohl sich das Erstellen eines Snapshots nur ca. 60% der verfügbaren UIO-leistung krallt. "Außfallfrei" sieht anders aus.
Zum Vergrößern anklicken....

währe ich dann doch fast bereit einmal meinen Server neu auf einem ZFS auf zu setzen.

Ich bin deprimiert, ich habe mit UFS geredet ... Es hasst mich!:(
Ich hätte gehofft, das Ihr alle sagt das UFS Snapshots super sind, alles passiert in einem Wimpernschlag, Backup and Restore sind so unglaublich einfach und können einfach über das netz gemacht werden, auch das Synchronisieren ist genial und funktioniert änlich wie mit git. Natürlich alles im laufendem betrieb. Das währe so meine Wunschwelt :D
 
Doch, klar kann dump auf laufenden FS arbeiten. Dafür ist der Parameter -L da: http://www.freebsd.org/cgi/man.cgi?...=FreeBSD+8.2-RELEASE&arch=default&format=html

Also meine Backups auf dem Desktop führen auch dazu, dass das System eine gewisse Zeit lang sehr träge reagiert. Ich sag mal ein Zeitfenster von etwa 5 Minuten hängt das System stellenweise. Dann natürlich für ne gewisse Zeit ein recht hohen IO (aber meist reagiert der Rechner dann noch normal).
 
ath0 schrieb:
Hat denn einer erfahrungen mit ZFS und snapshots und dem kram?
Zum Vergrößern anklicken....
ZFS hat die Snapshots ganz anders und um ganze Universen effizienter implementiert. Ein "zfs snapshot pool/dataset@snap" erstellt den Snapshot unabhängig der Größe des Dataset innerhalb von Sekundenbruchteilen. Das Löschen per "zfs destroy pool/dataset@snapshot" ist ebenso schnell und geht fast ohne Verzögerung. Der verbrauchte Speicherplatz durch Snapshots ist bedeutend geringer, da sie auf Blockebene arbeiten. Man kann das Dataset mittels "zfs rollback pool/dataset@snapshot" später auf den Snapshots zurücksetzen, man kann den Snapshot in ein eigenes Dataset klonen und so weiter... Auch das ist alles praktisch ohne Verzögerung möglich.
Aber der dafür zu zahlende Preis ist halt, dass ZFS wesentlich höhere Hardwareanforderungen als UFS hat. Zum produktiven Einsatz würde ich in jedem Fall eine 64Bit-CPU und mindestens 4GB RAM empfehlen. Wobei 8GB wirklich nicht schaden können. Auch ist ZFS deutlich komplexer. Zwar ist es inzwischen recht robust und kann fast alle Fehler selbst korrigieren, die in Version 15 (FreeBSD 8.2) noch tödlich waren, aber dennoch. Wenn mal was richtig schief geht, gibt es kein fsck und das Backup wird dann schnell zum guten Freund. Halt ähnlich der diversen anderen modernen Dateisysteme dort draußen. Wobei ich allerdings bisher einmal ein so katastrophales Versagen hatte und das (Hauptspeicherkorruption durch einen defekten NIC-Treiber) hätte UFS genauso irreparabel zerdeppert.
 
Also werde ich erstmal noch bei meiner Krüppellösung bleiben und nächstes jahr zu meinem umzug das Backupscript von Rakor einbauen. Wenn dann in meiner neuen Bude alles IO ist werde ich mich um mehr RAM für meinen Server kümmern.
Meine CPU dürfte noch etwas ausreichen (Opteron x4 1352) :)

Nochmal vielen Dank!

ath0
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben