cpdup mit laufender Jail

serialize

Newbie
Hi Ihr,

ich hab 'ne Frage zu cpdup, hab eben versucht, mit cpdup eine laufende Jail über's Netzwerk zu sichern, scheint soweit ganz gut zu klappen. Ich hab jetzt Bedenken, was mit dein eingehängten Mount-Points passiert.

Also, folgendes Szenario:
Die Samba-Jail in /jails/samba soll auf einen anderen Rechner kopiert werden, via
# cpdup /jails/samba root@192.168.3.32:/jails/samba​

In /jails/samba ist allerdings ein nullfs-Mount:
/data => /jails/samba/data

Werden die Dateien aus dem nullfs-mount mit übertragen und landen in /jails/samba/data auf dem neuen Server?

Haltet Ihr das Vorgehen im Allgemeinen für sinnvoll, um 'ne laufende Jail über's Netz zu sichern, oder gibt es da bessere Methoden?

Danke für eure Hilfe,
die besten Grüße,
serio
 
Denk dran, dass das herauskopieren und hereinkopieren von Dateien in eine laufende Jail dazu führen kann, dass Dateideskriptoren aus dem Host in sie hineingelangen oder schlimmer hinausgelangen können. Dann hast du einen Gefängnisausbruch, also einen Prozess der durch diesen Dateideskriptor Teile des Hosts sehen und angreifen kann.
 
Danke, genau an solche Sachen hab ich eben nicht gedacht :)

Also keine so gute Idee, aber kann man eine Jail dann sinnvoll im laufenden Zustand sichern? Wenn Ja, wie?

Viele Grüße,
serio
 
Über Snapshots. Du erstellst einen FFS-Snapshot (mksnap_ffs) auf der Partition und sicherst aus diesem heraus. Natürlich hat es den Nachteil, dass die Snapshots - anders als bei ZFS - alles andere als licht sind und entsprechend lange zu Erstellen benoetigen. Der Snapshot enthält keine Deskriptoren der eigentlichen Dateisysteme, daher ist es sicher.
 
Hi

das Thema interessiert mich. Also ich hab seit einiger Zeit eine Art Testserver am Laufen, läuft unter 6.3 amd64 hat 1GB RAM (also ausreichend für ZFS). Auf der Maschine laufen 3 Jails (MySQL, Mail, Apache), die ich nun möglichst komfortabel, schnell und vor allem sicher sichern möchte. Also nach einem Supercrash wäre es ideal, wenn ich lediglich den Host neu installieren müsste, die Jails dann ganz einfach mit einem kleinen Restore-Script zurückspielen, hochfahren, feddisch! Geht sowas??? :rolleyes:

Noch ist das Ding wie gesagt nicht in produktivem Einsatz, was sich aber sehr bald ändern soll. Deshalb frage ich mich wie ihr das macht? Yamagi hat schon die Möglichkeit mit mksnap_ffs angesprochen. Also hab ich etwas gegoogelt und da wird davon gesprochen dass ufs2 snapshots doch sehr umständlich und träge sind, immer mit dem Hinweis dass ZFS da um Längen seiner Zeit voraus wäre.
Jetzt frag ich mich, ob man es auf einem produktiven System riskieren kann ZFS zu verwenden, oder ob doch (noch) die sperrigen UFS2 Snapshots die einzige Lösung sind.
Also.... wie macht ihr das????? :cool:

thx
 
Erstmal zu ZFS: ZFS ist in der Version, in der es in FreeBSD 7.0 vorliegt meiner bescheidenen Meinung nach nicht für produktiven Einsatz geeignet. Es hat schlicht noch zu viele Unwägbarkeiten. Pawels Patches gegen -CURRENT beheben das, aber sind für dich schlicht noch uninteressant. Auch hast du ein 1 GB RAM, was für ZFS schonr echt wenig ist. MySQL, Apache und co. wollen ja auch was abhaben. Kurz: ZFS kannst du knicken.

Wie ich schon schrieb und wie Google noch mal bestätigte, UFS2-Snapshots sind eher sperrig. Wie sperrig hängt von drei Faktoren ab: Größe des Dateisystems, Anzahl der belegten Inodes und Zugriffe auf die Platte während des Erstellens. Die zum Erstellen und Löschen benötigte Zeit schwangt extrem. Meine Jail-Systeme haben im Schnitt 100GiB Dateisysteme mit Belegungen von durchschnittlich 20%. Sind ein paar hunderttausend Dateien. Das Erstellen benötigt zwischen 5 und 10 Minuten und ist damit völlig akzeptabel. Mein Dateiserver hat ein 5TiB Array mit mehreren zehn Millionen Dateien darauf. Ich bunkere da diverse Quellcode-Bäume der Kundensysteme. Die Belegeung ist knappe 85%. Das Erstellen eines Snapshots dauert zwischen 6 und 8 Stunden, damit ist es viel zu langsam.

Die UFS2 Snapshots wurden Anfang des Jahrtausends auch nicht eingebaut, um sie durch den Nutzer groß nutzen zu lassen. Stattdessen benötgte man sie für das Hintergrund-fsck. Dies legt einen Snapshot an und läuft über ihn, ein nicht unbeträchtlicher Teil der fsck-Zeit wird tatsächlich für das Erstellen des Snapshots benötigt. Irgendwann kam dann "dump -l" dazu, auch dies läuft über Snapshots...

Um nun zu deiner Frage zurückzukommen, in der Praxis führt kaum etwas an den Snapshots vorbei, wenn man vollständige Backups laufender Jails machen möchte. Schon allein, weil die Jails ja eingefrohren werde müssen, ansonsten verändern sie sich eventuell während des Backuplaufs und die ganze Sache wird inkonsistent. Die billige Milchmädchenlösung ist: MySQL stoppen -> Snapshot erstellen -> MySQL starten -> Snapshot mounten ->Sichern. Nicht sonderlich ausgereift, aber in vielen Einsatzszenarien völlig ausreichend. Alterntaiv kann man sich sagen "Ausbrüche schrecken mich nicht und Inkonsistenten sind unwahrscheinlich" und ganz einfach die laufenden Jails ohne weitere Abfederung sichern. Muss man für sich selbst entscheiden, ich hatte bei dieser Methode ab und an mal ausgebrochene Prozesse, was schon nervte. Die Prozesse sind dann sowohl den Host, als auch dem Jail zugeordnet. Inzwischen verwende ich eine etwas ausgekluegeltere Prozedur. Ich mounte das Jail per Nullfs an einen anderen Ort. Durch das Nullfs erreiche ich eine Entkopplung, Dateideskriptoren werden nicht aus dem Jail heraus genommen, ich kann auf dem Nullfs-Mount problemlos sichern. Sichern tue ich dort allerdings nur den garantiert konsistenten Teil, Dinge wie MySQL, Apache Webroots (wenn Scripte in sie schreiben dürfen), Mailboxen und so erforden angepasste Mechanismen. Für MySQL ist dies z.b. MySQK Hotcopy, was innerhalb des entsprechenden Jails läuft. In der Praxis kann man den sich verändernden Teil des Jails z.b. täglich sichern und den unveränderlichen Teil einmal die Woche. Ein Jail besteht also aus mehreren Sicherungen, in dem Beispiel das Jail selbst und dazu MySQL. Wer möchte kann sich nun ein simples Script schreiben, welches automatisiert aus diesen Einzelsicherungen bei der Wiederherstellung wieder ein Jail zusammensetzt.
 
Für MySQL gibt es noch eine weitere Möglichkeit, die insbesondere dann interessant wird, wenn InnoDB ins Spiel kommt und damit MySQlHotCopy nicht oder nur noch eingeschränkt funktioniert. Man setzt dazu einen Slave auf und fährt den zum Sichern runter. Der Master bleibt damit permanent in Betrieb, und die Backups werden trotzdem konsistent. Wenn man die Binlog-Dateien auf dem Slave dazu noch regelmäßig sichert, kann man damit sogar Point-in-Time Recovery fahren.
 
vielen Dank für die ausführliche Erklärung. Ich glaub für meinen Fall ist UFS2 mit Snapshots noch über Jahre ausreichend. ;)
 
Servus,

nochmal für die Mitlesenden, folgendermaßen sichere ich jetzt die Jails von einem Rechner auf den anderen.

1. Schritt: Snapshot erstellen
# mksnap_ffs /jails /jails/.snap/ssJails​

2. Schritt: Virtuelles Device erstellen
Das ist notwendig, um den Snapshot zu mounten
# mdconfig -a -t vnode -f /jails/.snap/ssJails -u 2​

3. Schritt: Snapshot mounten
# mount /dev/md2 /mnt/snapshot​

4. Schritt: Backup der Jail mittels cpdup über ssh

!!! Das Backup mit cpdup via ssh geht übrigens erst ab cpdup Version 1.0.7, versucht man es mit der älteren Version gibt es allerhand Fehlermeldungen :)
# cpdup /mnt/snapshot/samplejail user@backuphost:/jailbackup/samplejail​

5. Schritt: umount + Device entfernen
# umount /dev/md2
# mdconfig -d -u 2​

That's it,
viel Spaß und Danke für eure Unterstützung...
serio

PS: Fehler und Korrekturen sind absolut erwünscht
 
Zuletzt bearbeitet:
Den Snapshot noch löschen: rm -f /jails/.snap/ssJails
Machst du das nicht, bleibt der Snapshot vorhanden und dein Dateisystem läuft nach und nach voll, da immer mehr Änderungen zwischen diesem und der aktuellen Situation gespeichert werden wollen.
 
!! Das Backup mit cpdup via ssh geht übrigens erst ab cpdup Version 1.0.7, versucht man es mit der älteren Version gibt es allerhand Fehlermeldungen

# cpdup /mnt/snapshot/samplejail user@backuphost:/jailbackup/samplejail

was spricht den gegen den einsatz von rsync? damit könnte man auch noch etwas bandbreite sparen.
 
Soweit ich weiß, hatte rsync etwas Zicken mit den immutable-flags "schg" gemacht, cpdup halt nicht, daher ziehe ich cpdup rsync vor, wenn es um Jails geht. Aber mittlerweile ist das wohl eher 'ne philosophische Frage, wer was nutzt, weil beide Tools ja annähernd das gleiche tun.
 
Zurück
Oben