Auf meinem Server nutze ich Xen zur Virtualisierung, netterweise kann das Logical Volumes (LVM) für die Festplatten der Gastsysteme nutzen. Damit ich nun nicht auf jeder virtuellen Maschine bacula konfigurieren muss und beim Wiederherstellen des Backups direkt alle Gastsysteme auf einen Schlag restauriert habe, habe ich mir vor einiger Zeit ein Script geschrieben, welches einen Snapshot der LVs mountet, der dann gesichert wird: http://code.stapelberg.de/git/xen-lvm-snapshot/.
Da ich den Snapshot zu einem beliebigen Zeitpunkt (dann, wenn das Backup eben
läuft) anfertige, ist das Dateisystem des Gastsystems natürlich nicht
notwendigerweise in einem konsistenten Zustand (bereits weil ext3
ein Journaling Filesystem ist, kann man den Snapshot nicht einfach mounten).
Deswegen nutze ich fsck um das Journal abspielen zu lassen und
somit einen sauberen Zustand des Dateisystems für die Sicherung zu erlangen.
Das funktionierte auch bis gestern einwandfrei. Dann allerdings meinte
fsck, dass 183 Tage ohne Überprüfung des Dateisystems zu lange
seien und dass er jetzt mal prüfen müsse. Soweit ist das ja eigentlich
kein Problem, allerdings gibt fsck einen anderen Returncode
zurück, wenn er im Zuge dieser Überprüfung das Dateisystem verändert. Das
wiederum veranlasst die Shell, das Script abzubrechen (durch set -e
), bevor der Snapshot gemountet wird, was wiederum bacula
stört (immerhin wurde der Fehler bis hin zu mir durchgereicht).
Die Lösung des Problems ist trivial, gleichzeitig sieht man hier aber schön, wie selbst vermeintlich simple Programme monatelang funktionieren können, bevor ein Fehler bemerkt wird.