Ein Ordner, den niemand angelegt hat

Wer zum ersten Mal in den Filestore einer Odoo-Datenbank schaut, findet 256 Ordner mit zweistelligen Hex-Namen und dazwischen einen, der aus der Reihe fällt: checklist. Darin liegen wieder Hex-Ordner, und darin Dateien mit langen Hash-Namen, jede genau 0 Byte groß. Je nach Dokumentenaufkommen sind es schnell mehrere hundert. Die Odoo-Dokumentation erwähnt den Ordner nicht, keine Einstellung schaltet ihn ab. Spätestens beim Schreiben des Backup-Skripts stellt sich die Frage, ob er mit muss.

Er muss nicht. Warum, steht im Quellcode von ir.attachment, geprüft an Odoo 19.

Was Odoo dort ablegt

Odoo speichert Anhänge unter dem SHA1-Hash ihres Inhalts, verteilt auf 256 Unterordner nach den ersten beiden Zeichen des Hashes. Zwei Anhänge mit identischem Inhalt teilen sich deshalb eine einzige Datei auf der Platte. Das spart Platz, hat aber eine Folge: Beim Löschen eines Anhangs weiß Odoo im selben Moment nicht sicher, ob die Datei noch jemand anderes braucht. Dazu kommt, dass die laufende Transaktion noch zurückgerollt werden könnte, was den Anhang wiederherstellen würde. Die Datei sofort zu löschen wäre ein Risiko.

Odoo löscht deshalb gar nicht. Es merkt sich nur den Dateinamen zur späteren Prüfung, und genau das ist der Ordner checklist: eine leere Datei unter demselben relativen Pfad wie das Original, also checklist/a3/a3f1… für eine Datei a3/a3f1…. Deshalb spiegelt der Ordner die Hash-Struktur des Filestores. Die Datei ist ein Merkzettel, keine Kopie.

Auch beim Anlegen einer Datei setzt Odoo einen solchen Merkzettel, bevor das erste Byte geschrieben wird. Bricht die Transaktion danach ab, bleibt die Datei ohne zugehörigen Datensatz zurück und wird beim nächsten Aufräumen entsorgt. Der Ordner füllt sich also schon bei jedem Upload, lange bevor jemand etwas löscht.

Wann die Merkzettel abgearbeitet werden

Die geplante Aktion „Base: Auto-vacuum internal data“ läuft einmal täglich und ruft dabei die Müllabfuhr des Filestores auf. Die geht den Ordner checklist durch, fragt die Tabelle ir_attachment in Blöcken ab, welche der vorgemerkten Namen dort noch in der Spalte store_fname stehen, dem Verweis vom Datensatz auf die Datei, und löscht die physische Datei nur, wenn kein Datensatz mehr darauf zeigt. Anschließend entfernt sie den Merkzettel. Damit währenddessen kein neuer Anhang dazwischenkommt, sperrt sie die Tabelle gegen Schreibzugriffe, wartet auf diese Sperre aber höchstens zehn Sekunden und gibt sonst auf, bis zum nächsten Lauf. Im Serverlog steht danach eine Zeile nach dem Muster „filestore gc 1834 checked, 212 removed“.

Ein voller Ordner ist also kein Fehler. Er heißt nur, dass der Cron länger nicht lief oder zuletzt viel hochgeladen oder gelöscht wurde.

Kann der Ordner beim Backup wegbleiben?

Ja. Er enthält keine Nutzdaten, und alles, was er festhält, ist aus der Datenbank rekonstruierbar oder schlicht unwichtig. Nach einer Wiederherstellung ohne diesen Ordner startet Odoo normal. Der nächste Autovacuum-Lauf findet nichts vor und tut nichts, und beim nächsten Upload legt Odoo den Ordner wieder an.

Der einzige Effekt: Dateien, die zum Zeitpunkt des Backups zur Prüfung vorgemerkt waren, bleiben nach dem Restore als Waisen im Filestore liegen. Kein Datensatz zeigt darauf, keine Müllabfuhr räumt sie ab. Das kostet Speicherplatz, sonst nichts.

Bei rsync oder tar reicht daher ein --exclude 'checklist' auf der Ebene des Datenbank-Filestores.

Wichtiger als der Ausschluss ist, was drinbleibt: die 256 Hash-Ordner und der Datenbank-Dump, beide möglichst zeitnah zueinander erstellt. Ein Dump, der Anhänge kennt, die im Filestore fehlen, ist das eigentliche Problem eines Odoo-Backups. Ein fehlender Merkzettel-Ordner ist keins.

Wenn Waisen doch stören

Wer nach mehreren Restores Platz zurückholen will, kann die Müllabfuhr von Hand auf den gesamten Bestand ansetzen: In der Odoo-Shell alle Dateien des Filestores per _mark_for_gc vormerken und danach _gc_file_store aufrufen. Odoo prüft jeden Eintrag gegen die Datenbank und löscht nur, was nirgends mehr referenziert wird. Vorher ein Backup, wie bei jedem Eingriff in den Filestore, und danach die Log-Zeile lesen. Sie sagt, wie viele Dateien geprüft und wie viele entfernt wurden.

Erstellt von Martin Schmid, mit Unterstützung von Claude Fable 5.1 und nach eigener inhaltlicher Prüfung freigegeben. Es gelten unsere Hinweise und Haftungsausschluss.