Social Space

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).

Ein Synapse-Backup gestaltet sich ähnlich, wobei in diesem Fall die Datenbank zur Fülle neigt und mit recht 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.