Mastodon Maintenance

Die wichtigsten Wartungsaufgaben für Administratoren

Wer eine Mastodon-Instanz betreibt, muss regelmäßig aufräumen. Ohne Pflege wachsen Datenbank und Medienspeicher unkontrolliert – bei einer mittelgroßen Instanz mit Object Storage können das nach einigen Monaten leicht mehrere hundert Gigabyte sein, die unnötig Kosten verursachen.

Die folgenden Aufgaben basieren auf der offiziellen tootctl-Dokumentation und sind für aktuelle Mastodon-Versionen (4.x) geprüft. Alle Befehle setzen eine native Installation mit rbenv voraus. Wer Docker nutzt, ersetzt den Aufruf entsprechend durch docker exec.

Vorbereitung: Der richtige Aufruf

Alle tootctl-Befehle werden als mastodon-User ausgeführt. Da rbenv den Ruby-Interpreter verwaltet, muss der PATH explizit gesetzt werden:

sudo -u mastodon bash -c "export PATH=/home/mastodon/.rbenv/shims:/home/mastodon/.rbenv/bin:\$PATH && cd /home/mastodon/live && RAILS_ENV=production bin/tootctl BEFEHL"

Der Einfachheit halber werden die Befehle im Folgenden ohne diesen Wrapper geschrieben – er muss bei der tatsächlichen Ausführung ergänzt werden.

Vor und nach jeder Maintenance-Aktion lohnt sich ein Blick auf den aktuellen Speicherverbrauch:

bin/tootctl media usage

1. Mediencache aufräumen

Der größte Posten bei Instanzen mit Object Storage. Mastodon cached Bilder, Videos und Anhänge von anderen Instanzen in S3 oder Backblaze B2 – und baut diesen Cache im laufenden Betrieb kontinuierlich aus.

Remote-Medien älter als 30 Tage löschen:

bin/tootctl media remove --days=30

Avatare und Header-Grafiken von Fediverse-Accounts, die seit mehr als 30 Tagen inaktiv waren, entfernen. Immer zuerst als Dry-Run ausführen:

bin/tootctl media remove --prune-profiles --days=30 --dry-run
bin/tootctl media remove --prune-profiles --days=30

Dieser Schritt kann bei einer großen Instanz mit hunderttausenden bekannten Fediverse-Accounts eine Stunde oder länger dauern und dabei mehrere Dutzend Gigabyte freisetzen. Bei laufendem Betrieb können vereinzelte Timeout-Fehler auftreten – das ist normal, der Prozess läuft weiter und überspringt die betroffenen Dateien.

Verwaiste Mediendateien ohne Datenbankreferenz aufspüren und löschen:

bin/tootctl media remove-orphans

Bei großen Buckets dauert dieser Befehl mehrere Stunden. Unbedingt in einer tmux-Session ausführen:

tmux new -s orphans
# Befehl ausführen
# Ctrl+B, D zum Detachen – Prozess läuft im Hintergrund weiter
# tmux attach -t orphans zum Wiederverbinden

2. Preview Cards aufräumen

Mastodon generiert Vorschaukarten für verlinkte Webseiten. Auch diese summieren sich über Zeit. Wichtig: Karten der letzten 14 Tage nicht löschen, da Mastodon sie erst nach zwei Wochen neu abruft.

bin/tootctl preview_cards remove --days=30

3. Alte Remote-Posts aus der Datenbank entfernen

Posts von anderen Instanzen, mit denen kein lokaler User interagiert hat (kein Like, Boost, Antwort), können sicher gelöscht werden. Das reduziert die Datenbankgröße erheblich und ist die Voraussetzung dafür, dass pg_repack (siehe unten) nennenswert Speicher zurückgewinnen kann.

bin/tootctl statuses remove --days=90

Bei einer großen Instanz kann dieser Befehl sehr lange dauern und die Datenbank belasten. Außerhalb der Stoßzeiten oder wöchentlich per Cronjob ausführen.

4. Accounts aufräumen

Remote-Accounts, die nie mit einem lokalen User interagiert haben, aus der Datenbank entfernen:

bin/tootctl accounts prune

Accounts gegen ihre Heimatinstanz prüfen und gelöschte Accounts lokal entfernen. Nicht zu häufig ausführen, da dieser Befehl viele Remote-Server kontaktiert:

bin/tootctl accounts cull

5. Cache leeren und Zähler neu berechnen

Den Redis-Cache leeren – sinnvoll nach Updates oder bei unerklärlichem Verhalten:

bin/tootctl cache clear

Follower- und Post-Zähler in der Datenbank neu berechnen, falls sie inkonsistent wirken:

bin/tootctl cache recount

6. Datenbankindizes reparieren

Nach Serverabstürzen oder Kollationsproblemen können Datenbankindizes korrupt werden. Dieser Befehl erkennt und behebt Duplikate:

bin/tootctl maintenance fix-duplicates

Vorsicht: Dieser Befehl sperrt Tabellen für längere Zeit. Nur im Wartungsfenster mit gestopptem Mastodon ausführen.

7. PostgreSQL-Speicher mit pg_repack zurückgewinnen

Nach tootctl statuses remove gibt PostgreSQL den freigegebenen Speicher nicht automatisch ans Betriebssystem zurück – die Datenbankdatei bleibt gleich groß. Das liegt daran wie PostgreSQL intern Speicher verwaltet: gelöschte Zeilen werden als „toter Speicher” markiert, aber nicht sofort freigegeben.

pg_repack reorganisiert alle Tabellen online und gibt den Speicher tatsächlich frei. Der entscheidende Vorteil gegenüber VACUUM FULL: Mastodon kann während der gesamten Ausführung weiterlaufen, da pg_repack keine langen Tabellensperren benötigt.

Ausführen als postgres-User:

su - postgres
pg_repack -d mastodon_production --no-kill-backend

Das --no-kill-backend ist wichtig: damit wartet pg_repack auf laufende Transaktionen statt sie abzuwürgen. Bei einer aktiven Instanz ist das die sichere Variante.

Den zurückgewonnenen Speicher anschließend prüfen:

psql -c "SELECT pg_size_pretty(pg_database_size('mastodon_production'));"

In der Praxis lassen sich nach einer gründlichen Bereinigung 2 GB und mehr zurückgewinnen – bei laufendem Betrieb und ohne Downtime. pg_repack sollte alle paar Monate manuell ausgeführt werden, nicht im täglichen Cronjob.

8. Alles als Cronjob automatisieren

Die täglichen und wöchentlichen Aufgaben gehören in einen Cronjob. Als root:

sudo crontab -e

Empfohlene Konfiguration:

# täglich 03:00 Uhr – Mediencache
0 3 * * * sudo -u mastodon bash -c "export PATH=/home/mastodon/.rbenv/shims:/home/mastodon/.rbenv/bin:\$PATH && cd /home/mastodon/live && RAILS_ENV=production bin/tootctl media remove --days=30"

# täglich 03:30 Uhr – Profilmedien
30 3 * * * sudo -u mastodon bash -c "export PATH=/home/mastodon/.rbenv/shims:/home/mastodon/.rbenv/bin:\$PATH && cd /home/mastodon/live && RAILS_ENV=production bin/tootctl media remove --prune-profiles --days=30"

# täglich 04:00 Uhr – Preview Cards
0 4 * * * sudo -u mastodon bash -c "export PATH=/home/mastodon/.rbenv/shims:/home/mastodon/.rbenv/bin:\$PATH && cd /home/mastodon/live && RAILS_ENV=production bin/tootctl preview_cards remove --days=30"

# wöchentlich sonntags 02:00 Uhr – Remote-Posts
0 2 * * 0 sudo -u mastodon bash -c "export PATH=/home/mastodon/.rbenv/shims:/home/mastodon/.rbenv/bin:\$PATH && cd /home/mastodon/live && RAILS_ENV=production bin/tootctl statuses remove --days=90"

Nicht im Cronjob, sondern manuell ausführen: accounts prune, accounts cull, media remove-orphans und pg_repack. Diese Befehle laufen entweder sehr lange, belasten Remote-Server oder sollten bewusst mit Dry-Run vorbereitet werden.

Fazit

Regelmäßige Maintenance hält eine Mastodon-Instanz schlank und die Kosten für Object Storage beherrschbar. Die Kombination aus wöchentlichem statuses remove, täglichem Mediencache-Aufräumen und gelegentlichem pg_repack macht den größten Unterschied. Was sich damit nicht vollständig lösen lässt, sind verwaiste Dateien im Object Storage – ein strukturelles Problem von Mastodon, das auch mit media remove-orphans nur teilweise behoben werden kann. Dazu mehr im Artikel über Mastodon und Backblaze B2.