Je mehr datenverarbeitende Sozialanwendungen auf meinem Server laufen, desto drängender stellt sich die Frage nach einer geeigneten Backup-Strategie. Für Mastodon gibt es eine präzise Anleitung zur Sicherung der wichtigsten Daten (.env.production, Medien, PostgreSQL- und Redis-Datenbank). Weil Redis sein eigenes Backup erzeugt, benötige ich lediglich einen Cronjob für PostgreSQL –
53 12 * * * pg_dump -U mastodon -d mastodon_production > /backup/mastodon_production.sql && gzip -f -9 /backup/mastodon_production.sql
– und einige rbackup.py-Konfigurationen, die aber den Cache für entfernte Medien-Inhalte aussparen sollten (exclude: *cache*), denn:
snafu:~/live$ bin/tootctl media usage Attachments: 1.09 GB (290 KB local) Custom emoji: 40.1 MB (12.7 KB local) Preview cards: 140 MB Avatars: 1.96 GB (96.5 KB local) Headers: 3.91 GB (413 KB local)
Mit bin/tootctl media remove --days=1 (als täglichen Cronjob) lässt sich der Attachments-Cache gut beherrschen, aber das ungebremste Caching von Avatar- und Header-Bildern fremder Menschen könnte ein Problem werden.
Damit der obige Cronjob funktioniert, ändere ich das Anmeldeverfahren für PostgreSQL von peer auf sha-cram256 für alle lokalen Nutzerinnen außer dem Superuser postgres (und hinterlege das Passwort für mastodon in .env.production).Selbst wenn man von Mastodons Caching-Problemen absieht, geht die Software sehr großzügig mit Speicherplatz um: Ein Dump der Datenbank ist schon nach wenigen Wochen deutlich größer als meine 14 Jahre alte Website-Datenbank (300 MB vs. 120 MB).
Das gilt auch für Synapse, deren Datenbank noch stärker zur Fülle neigt und mit großem Aufwand in Schach gehalten werden muss. Ich sichere sie daher nur einmalig (pg_dump synapse_production > /backup/synapse_production.sql && gzip -f -9 /backup/synapse_production.sql) und gemeinsam mit den Einstellungen (/etc/matrix-synapse).
Kommunikation ist schön, braucht aber viel Platz.