Wie man alte Nachrichtenverläufe und Medien in Matrix Synapse löscht

Beispielszenario (nur zur Veranschaulichung): Die fiktive gemeinnützige Organisation Northstar Community betreibt einen Matrix Synapse-Homeserver. Ihre Datenbank und ihr Medienspeicher wachsen stetig, und der Administrator möchte alte Chatverläufe und veraltete Medien entfernen, ohne versehentlich aktuelle Diskussionen oder Profilbilder zu löschen. Dieses Beispiel stellt weder einen realen Einsatz noch ein getestetes Ergebnis dar.

Entscheidend ist, Nachrichtenverlauf und Mediendateien als separate Bereinigungsvorgänge zu behandeln. Synapse bietet eine API zum Löschen des Raumverlaufs und separate Tools zum Bereinigen von Mediendateien. Eine Einstellung zur Medienaufbewahrung kann Dateien entfernen, während die zugehörigen Matrix-Ereignisse erhalten bleiben. Legen Sie zunächst fest, welche Daten verfügbar bleiben müssen, sichern Sie dann die Datenbank und den Medienspeicher, wählen Sie die geeignete Methode und überprüfen Sie anschließend beide Speicherbereiche.

Legen Sie fest, was „alt“ für Ihren Server bedeutet.

Bevor Sie die Konfiguration ändern oder einen Endpunkt aufrufen, der Daten löscht, sollten Sie eine Aufbewahrungsregel festlegen. Nehmen wir beispielsweise Northstar: Der Vorstand genehmigt die Aufbewahrung des normalen Raumverlaufs für 180 Tage, die Aufbewahrung lokaler Uploads unterliegt einer ähnlichen Richtlinie, und externe Medien werden als Cache behandelt, der bei Bedarf erneut abgerufen werden kann. Andere Organisationen benötigen möglicherweise aus rechtlichen, betrieblichen oder gemeinschaftlichen Gründen eine jahrelange Aufbewahrung. Diese Zeiträume sind Beispiele und keine allgemeingültigen Empfehlungen.

Teilen Sie die Daten in zwei Kategorien auf:

• Raumereignisse: Nachrichten und andere Ereignisse, die in der Synapse-Datenbank gespeichert werden. Das Löschen von Ereignissen ändert die Reichweite, die Benutzer im Raum zurückblättern können.
• Medien: Hochgeladene Dateien, Miniaturansichten und zwischengespeicherte Kopien von Dateien von anderen Homeservern. Diese befinden sich im Medien-Repository oder in einem konfigurierten externen Repository.

Die offizielle Dokumentation von Synapse beschreibt die Aufbewahrungsrichtlinien für Ereignisse und die Medienbereinigung separat. Das Löschen des Raumverlaufs beweist nicht automatisch, dass der Medienspeicher bereinigt wurde, und das Löschen einer Mediendatei löscht nicht das zugehörige Ereignis. Notieren Sie zunächst die Datenbankgröße, die Größe des Medienspeichers, die betroffenen Räume und den geplanten Abbruchzeitpunkt. Weitere Informationen finden Sie im Synapse-Konfigurationshandbuch .

Vor dem Löschen ein Backup erstellen

Erstellen Sie eine Datenbanksicherung gemäß der für Ihre Datenbank-Engine empfohlenen Vorgehensweise und sichern Sie auch das Medienrepository oder den externen Medienspeicher. Eine Datenbanksicherung allein sichert keine hochgeladenen Dateien; eine Mediensicherung allein stellt keine Raumereignisse wieder her. Stellen Sie sicher, dass die Sicherungen lesbar sind und Sie wissen, wie Sie sie wiederherstellen können, bevor Sie fortfahren. Wenn Synapse in Containern ausgeführt wird oder separate Worker verwendet, berücksichtigen Sie die entsprechenden Konfigurationen und Speichervolumes in Ihrem Wartungsplan.

Für den hypothetischen Server von Northstar protokolliert der Administrator die Größe der Datenbank und des Medienspeichers und überprüft einen aktuellen Wiederherstellungspunkt, bevor er die gemeinsam genutzten Räume bearbeitet. Dies ist wichtig, da eine Bereinigung nur dann erfolgreich ist, wenn die gewünschten Daten entfernt werden, die benötigten Inhalte aber wiederherstellbar bleiben.

Wählen Sie eine geplante Aufbewahrungsfrist für die laufende Reinigung.

Soll Synapse eine Richtlinie weiterhin anwenden, konfigurieren Sie die Ereignis- und Medienaufbewahrung separat in der Homeserver-Konfiguration. Ein Administrator könnte beispielsweise dieses Beispiel für einen Server anpassen, dessen genehmigte Richtlinie 180 Tage für den Raumverlauf und lokale Medien sowie einen 30-tägigen Cache für Remote-Medien vorsieht:

retention:
  enabled: true
  default_policy:
    max_lifetime: 180d

media_retention:
  local_media_lifetime: 180d
  remote_media_lifetime: 30d

Dies ist eine beispielhafte Konfiguration und keine allgemeingültige Richtlinie für jeden Server. Synapse dokumentiert, dass die Ereignisaufbewahrung standardmäßig deaktiviert ist. Dies default_policygilt für Räume ohne Statusereignis m.room.retention. Raumadministratoren können Raumrichtlinien festlegen, während Serveradministratoren die Gültigkeitsdauer von Richtlinien mit den dokumentierten Einstellungen für die zulässige Gültigkeitsdauer begrenzen können. Wenn Sie eine einheitliche Obergrenze benötigen, überprüfen Sie diese Einstellungen und die bereits verwendeten Raumrichtlinien, anstatt davon auszugehen, dass die Standardeinstellung alle Räume abdeckt.

Die Lebensdauer von Mediendateien richtet sich nach dem Zeitpunkt des letzten Zugriffs. Wurde eine Datei noch nie aufgerufen, verwendet Synapse deren Erstellungsdatum. Diese Einstellung gilt für Originale und Miniaturansichten; nicht festgelegte oder leere Lebensdauern führen nicht zur Löschung der entsprechenden Medienkategorie. Eine zwischengespeicherte Datei kann nach ihrer Löschung erneut vom Ursprungsserver angefordert werden. Quarantänisierte und lokal geschützte Medien sind Ausnahmen und werden durch diese Aufbewahrungseinstellungen nicht entfernt. Die Medienbereinigung wird auf dem Synapse-Prozess oder -Worker ausgeführt, der diese enable_media_repoFunktion aktiviert hat. Lesen Sie die aktuellen Informationen zur Aufbewahrung und zur Medienaufbewahrung und wenden Sie die Konfiguration anschließend im Rahmen des normalen Neustarts oder der Bereitstellung Ihrer Installation an.

Bevor Sie das Beispiel übernehmen, vergleichen Sie dessen Verhalten mit Ihren Anforderungen. Wenn eine Raumnachricht mit Anhang 180 Tage lang lesbar bleiben muss, wählen Sie keine kürzere Medienlebensdauer, es sei denn, Sie akzeptieren, dass die Nachricht länger gültig sein könnte als die lokal verfügbare Datei. Prüfen Sie, ob Ihre Medien in Synapse selbst oder in einem externen Medienspeicher abgelegt sind; die lokale Medienlösch-API von Synapse entfernt keine Medien, die in einem externen Speicher abgelegt sind.

Ältere Raumereignisse bei Bedarf löschen

Für eine einmalige Bereinigung verwenden Sie die Synapse Purge History Admin API. Hierfür benötigen Sie ein Serveradministrator- Zugriffstoken; die Administratorrechte für einen einzelnen Raum sind nicht ausreichend. Synapse empfiehlt, die Admin API nicht öffentlich zugänglich zu machen und diese Anfragen üblicherweise vom Server oder einem vertrauenswürdigen Administrationshost aus zu stellen. Fügen Sie niemals ein aktives Zugriffstoken in die gemeinsam genutzte Shell-Historie, Tickets oder Protokolle ein.

Die Anfrage muss einen Grenzwert mithilfe einer Ereignis-ID oder eines Unix-Zeitstempels in Millisekunden angeben. Das folgende Shell-Beispiel dient der Veranschaulichung. Ersetzen Sie Homeserver, Raum-ID, Token-Variable und den Beispiel-Grenzwert durch die von Ihnen geprüften Werte. Das Beispiel fordert explizit auch die Löschung von lokalen Benutzer-Nachrichtenereignissen an.

export SYNAPSE_ADMIN_TOKEN='replace-with-a-server-admin-token'
PURGE_CUTOFF_MS=1760000000000  # replace with the approved UTC cutoff

curl --fail-with-body -X POST \
  -H "Authorization: Bearer $SYNAPSE_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  --data "{\"purge_up_to_ts\": $PURGE_CUTOFF_MS, \"delete_local_events\": true}" \
  "https://matrix.example.org/_synapse/admin/v1/purge_history/!room:example.org"

Ohne delete_local_events: truedie Option `--template` speichert Synapse standardmäßig Ereignisse, die von lokalen Benutzern gesendet wurden; Ereignisse von externen Benutzern können gelöscht werden. Der Raumstatus, wie z. B. Mitgliedschaften und Themenstatus, bleibt erhalten. Synapse speichert außerdem mindestens eine Nachricht pro Raum. Der Vorgang kann mehrere Minuten oder länger dauern, und Benutzer können währenddessen nicht in den gelöschten Abschnitten zurückblättern. Die API gibt sofort eine Lösch-ID zurück; überprüfen Sie /_synapse/admin/v1/purge_history_status/<purge_id>den Status, bis er „false“ lautet, completeoder untersuchen Sie den Fehler, falls er „false“ lautet failed. Lesen Sie die Dokumentation der Löschhistorie-API, bevor Sie einen Abbruchzeitpunkt festlegen. Prüfen Sie insbesondere, ob das Entfernen lokaler Ereignisse für Ihre Räume sinnvoll ist.

Lokale Medien und Remote-Cache separat bereinigen

Für wiederkehrende Bereinigungen media_retentionwählen Sie Lebensdauern, die der von Ihnen zugesicherten Verfügbarkeit für die Benutzer entsprechen. Für eine einmalige Bereinigung bietet Synapse separate Endpunkte:

• Lokale Medien: POST /_synapse/admin/v1/media/delete?before_ts=<timestamp_ms> Entfernt geeignete lokale Medien basierend auf ihrem letzten Verwendungszeitpunkt. Die API akzeptiert auch einen Größenschwellenwert. Profil- und Raumavatar-Medien bleiben standardmäßig erhalten; deaktivieren Sie diesen Schutz nur, wenn Sie die Konsequenzen sorgfältig geprüft haben.
• Zwischengespeicherte Remote-Medien: POST /_synapse/admin/v1/purge_media_cache?before_ts=<timestamp_ms> Entfernt zwischengespeicherte Remote-Medien, deren letzter Zugriff vor dem Stichtag erfolgte. Fordert ein Benutzer eine entfernte Remote-Datei später an, kann Synapse sie erneut vom ursprünglichen Homeserver anfordern.

Beide Endpunkte verwenden einen positiven Unix-Zeitstempel in Millisekunden. Der Medien-Stornierungszeitpunkt basiert auf dem letzten Zugriff, nicht auf dem Upload- oder Erstellungsdatum. Die API zum Löschen lokaler Medien entfernt die Datei und ihre Miniaturansichten aus dem Synapse-Speicher, einschließlich lokal zwischengespeicherter Kopien von Remote-Dateien. Externe Medienspeicher werden nicht bereinigt. Die Antwort gibt die Anzahl der gelöschten Elemente an. Prüfen Sie die Synapse-Medienverwaltungs-API auf aktuelle Parameter und Endpunktdetails, bevor Sie eine Anfrage senden.

Im Beispiel Northstar würde ein Administrator zunächst den Grenzwert anhand der genehmigten Richtlinie prüfen und feststellen, ob die vom Endpunkt zurückgegebenen IDs oder Zählerstände den Erwartungen entsprechen. Wenn der Remote-Cache die einzige Wachstumsquelle ist, wäre das Löschen lokaler Uploads die falsche Vorgehensweise. Müssen lokale Uploads verfügbar bleiben, sollte eine längere lokale Lebensdauer gewählt oder der Endpunkt zum Löschen lokaler Medien vermieden werden.

Messen Sie das Ergebnis und ändern Sie gegebenenfalls den Kurs.

Prüfen Sie nach jedem Vorgang, ob die Bereinigung erfolgreich abgeschlossen wurde, überprüfen Sie die API-Antwortzahlen, stellen Sie sicher, dass die repräsentativen Räume die erwartete Verlaufsgrenze anzeigen, und vergleichen Sie die Datenbank- und Medienspeichernutzung separat. Eine Reduzierung der Datenbankzeilen führt möglicherweise nicht sofort zu einer gleichwertigen Reduzierung der Festplattennutzung des Betriebssystems; die Speicherplatzfreigabe in der Datenbank hängt von der Datenbank-Engine und ihren Wartungsverfahren ab. Befolgen Sie die Anweisungen des Datenbankanbieters, anstatt Datenbankdateien manuell zu löschen.

Wenn die Datenbank kleiner wird, der Medienspeicher aber nicht, überprüfen Sie die Medienaufbewahrung, den Medien-Worker enable_media_repo, den Quarantäne- oder Schutzstatus und ob Dateien extern gespeichert werden. Wenn die Mediennutzung sinkt, aber alte Nachrichten bestehen bleiben, ist dies zu erwarten, wenn nur Medien gelöscht wurden. Falls Ereignisse unerwartet verbleiben, prüfen Sie, ob die Aufbewahrung aktiviert ist, ob der Raum einen eigenen Aufbewahrungsstatus hat, ob lokale Ereignisse absichtlich beibehalten wurden und ob der Löschvorgang abgeschlossen ist.

Für Northstar ist das Erfolgskriterium nicht einfach nur „die Festplatte ist kleiner“. Es muss vielmehr sein, dass die genehmigte Grenze für den alten Verlauf sichtbar ist, erforderliche aktuelle Nachrichten und Anhänge weiterhin funktionieren, die vorgesehene Medienkategorie bereinigt wurde und beide Backups verfügbar bleiben. Sollten diese Prüfungen fehlschlagen, stoppen Sie weitere Bereinigungen und überprüfen Sie die Raumrichtlinie, die API-Antwort, die Worker-Konfiguration und das Speichersystem, bevor Sie die Bereinigung ausweiten.

Zu beachtende Grenzen

Aufbewahrungsrichtlinien ersetzen nicht die rechtliche Prüfung oder die Aufbewahrungspflichten einer Organisation. Durch die Föderation können andere Homeserver eigene Kopien von Ereignissen oder Mediendateien speichern, und Synapse kann die Löschung von diesen Servern nicht garantieren. Das Löschen von Mediendateien auf einem Remote-Server entfernt den Cache des Servers; die Quelldatei auf dem ursprünglichen Homeserver wird nicht gelöscht. Ebenso wird durch das Löschen eines lokalen Ereignis- oder Medienobjekts aus Synapse keine Kopie wiederhergestellt, die ein anderer Teilnehmer bereits heruntergeladen hat.

Verwenden Sie die geplante Aufbewahrung, wenn Sie eine wiederholbare Richtlinie benötigen; nutzen Sie die Admin-APIs für eine geprüfte, gezielte Bereinigung. Trennen Sie die beiden Vorgänge in Ihrem Änderungsdatensatz, da sich ihre Erfolgssignale und Auswirkungen unterscheiden.