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.