Cum să ștergi istoricul mesajelor vechi și fișierele media în Matrix Synapse

Scenariu exemplu (doar ilustrativ): Northstar Community, o organizație non-profit ipotetică, rulează un server de acasă Matrix Synapse. Baza de date și depozitul media sunt în creștere, iar administratorul dorește să elimine istoricul vechi al camerelor și fișierele media învechite fără a șterge accidental discuțiile curente sau imaginile de profil. Acest exemplu nu este un raport al unei implementări reale sau al unui rezultat testat.

Cheia este de a trata istoricul mesajelor și fișierele media ca sarcini separate de curățare. Synapse are o API de curățare a istoricului camerelor și instrumente separate de curățare a fișierelor media; o setare de păstrare a fișierelor media poate, de asemenea, elimina fișiere în timp ce evenimentele Matrix care le fac referire rămân. Mai întâi decideți ce trebuie să rămână disponibil, apoi faceți o copie de rezervă a bazei de date și a depozitului media, alegeți metoda adecvată și verificați ambele zone de stocare ulterior.

Decide ce înseamnă „vechi” pentru serverul tău

Înainte de a schimba configurația sau de a apela un endpoint distructiv, scrieți o regulă de păstrare. Pentru exemplul Northstar, să presupunem că consiliul aprobă păstrarea istoricului camerei obișnuite timp de 180 de zile, păstrarea încărcărilor locale conform unei politici similare și tratarea mediilor la distanță ca o memorie cache care poate fi preluată din nou, dacă este necesar. O altă organizație ar putea avea nevoie de ani de păstrare din motive legale, operaționale sau comunitare. Aceste perioade de timp sunt exemple, nu recomandări universale.

Separați datele în două categorii:

• Evenimente în cameră: mesaje și alte evenimente stocate în baza de date Synapse. Ștergerea evenimentelor modifică cât de departe pot naviga utilizatorii în cameră.
• Media: fișiere încărcate, miniaturi și copii memorate în cache ale fișierelor de pe alte servere principale. Acestea se află în depozitul media sau într-un depozit extern configurat.

Documentația oficială Synapse descrie politicile de păstrare pentru evenimente și curățarea fișierelor media în mod independent. O curățare a istoricului camerelor nu dovedește în sine că depozitul media a fost curățat, iar ștergerea unui fișier media nu șterge evenimentul care a fost legat de acesta. Începeți prin a înregistra dimensiunea bazei de date, dimensiunea depozitului media, camerele afectate și data limită intenționată. Consultați manualul de configurare Synapse .

Faceți o copie de rezervă înainte de curățare

Faceți o copie de rezervă a bazei de date utilizând procedura recomandată pentru motorul bazei de date și faceți o copie de rezervă și a depozitului media sau a depozitului media extern. O copie de rezervă a bazei de date singură nu păstrează fișierele încărcate; o copie de rezervă media singură nu restaurează evenimentele camerei. Confirmați că copiile de rezervă sunt lizibile și că știți cum să le restaurați înainte de a continua. Dacă Synapse rulează în containere sau utilizează worker-uri separate, includeți configurația și volumele de stocare relevante în planul de întreținere.

Pentru serverul ipotetic al Northstar, administratorul înregistrează dimensiunile bazei de date și ale spațiului de stocare media și confirmă un punct de restaurare recent înainte de a accesa camerele partajate. Acest lucru este util deoarece o „curățare” are succes numai dacă elimină datele dorite, lăsând în același timp conținutul necesar recuperabil.

Alegeți păstrarea programată pentru curățarea continuă

Dacă doriți ca Synapse să aplice în continuare o politică, configurați separat păstrarea evenimentelor și păstrarea fișierelor media în configurația serverului principal. De exemplu, un administrator ar putea adapta acest exemplu pentru un server a cărui politică aprobată este de 180 de zile pentru istoricul camerei și fișierele media locale, cu o memorie cache pentru fișierele media la distanță de 30 de zile:

retention:
  enabled: true
  default_policy:
    max_lifetime: 180d

media_retention:
  local_media_lifetime: 180d
  remote_media_lifetime: 30d

Aceasta este o configurație ilustrativă, nu o politică de tip „drop-in” pentru fiecare server. Synapse documentează funcția de păstrare a evenimentelor ca fiind dezactivată în mod implicit. Se default_policyaplică camerelor care nu au un m.room.retentioneveniment de stare; administratorii camerelor pot seta politici pentru camere, în timp ce administratorii serverului pot limita durata de viață a politicilor cu setările documentate pentru durata de viață permisă. Dacă aveți nevoie de o limită superioară consistentă, revizuiți acele controale și politicile camerei deja utilizate, în loc să presupuneți că valoarea implicită acoperă fiecare cameră.

Duratele de viață ale suporturilor media se bazează pe timpul scurs de la ultima accesare a unui element media. Dacă un element nu a fost niciodată accesat, Synapse utilizează ora sa de creare. Setarea se aplică originalelor și miniaturilor; duratele de viață nesetate sau nule nu elimină acea categorie de suport media. Un element din cache la distanță poate fi solicitat din nou de la originea sa după ce a fost eliminat. Suporturile media din carantină și suporturile media protejate local sunt excepții și nu sunt eliminate de aceste setări de retenție. Curățarea suporturilor media se execută pe procesul sau lucrătorul Synapse care a fost enable_media_repoactivat. Examinați referința curentă pentru retenție și media_retention , apoi aplicați configurația utilizând procedura normală de repornire sau implementare pentru instalarea dvs.

Înainte de a adopta exemplul, comparați comportamentul acestuia cu nevoile dvs. Dacă un mesaj din cameră trebuie să rămână lizibil cu atașamentul său timp de 180 de zile, nu alegeți o durată de viață mai scurtă a fișierului media, decât dacă acceptați că mesajul poate supraviețui fișierului disponibil local. Verificați dacă fișierele media sunt stocate chiar în Synapse sau într-un depozit media extern; API-ul de ștergere a fișierelor media locale al Synapse nu elimină fișierele media deținute de un depozit extern.

Ștergeți evenimentele mai vechi ale camerei la cerere

Pentru o curățare unică, utilizați API-ul de administrare Synapse Purge History. Aceasta necesită un token de acces de administrator al serverului ; a fi administrator al unei camere individuale nu este aceeași permisiune. Synapse recomandă păstrarea API-ului de administrare ascuns de public și, de obicei, efectuarea acestor solicitări de pe server sau de la o gazdă de administrare de încredere. Nu lipiți un token de acces live în istoricul shell partajat, în tichete sau jurnale.

Cererea trebuie să specifice o limită de timp (cutoff) utilizând un ID de eveniment sau o marcă temporală Unix în milisecunde. Următorul exemplu de shell este ilustrativ. Înlocuiți serverul de acasă, ID-ul camerei, variabila token și limita de timp (cutoff) exemplu cu valori pe care le-ați analizat. Exemplul solicită în mod explicit și ștergerea evenimentelor de mesaje ale utilizatorului local:

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"

Fără delete_local_events: true, Synapse păstrează în mod implicit evenimentele trimise de utilizatorii locali; evenimentele trimise la distanță pot fi șterse. Starea camerei, cum ar fi apartenența și starea subiectului, este păstrată. De asemenea, Synapse păstrează cel puțin un mesaj în fiecare cameră. Operațiunea poate dura câteva minute sau mai mult, iar utilizatorii nu pot pagina mai înapoi prin porțiunea care este eliminată în timp ce rulează. API-ul returnează imediat un ID de eliminare; interogați /_synapse/admin/v1/purge_history_status/<purge_id>până când starea este completesau investigați eroarea dacă este failed. Consultați documentația API-ului Purge History înainte de a selecta o limită de timp. În special, verificați dacă eliminarea evenimentelor locale este potrivită pentru camerele dvs.

Curățați separat suportul media local și memoria cache la distanță

Pentru curățarea recurentă, utilizați media_retentionși alegeți durate de viață care corespund disponibilității pe care o promiteți utilizatorilor. Pentru o curățare unică, Synapse oferă puncte finale distincte:

• Fișiere media locale: POST /_synapse/admin/v1/media/delete?before_ts=<timestamp_ms> elimină fișierele media locale eligibile în funcție de ultima utilizare. API-ul acceptă și un prag de dimensiune. Fișierele media pentru profil și avatarul camerei sunt păstrate în mod implicit; nu dezactivați această protecție decât dacă ați analizat intenționat consecințele.
• Medii media la distanță memorate în cache: POST /_synapse/admin/v1/purge_media_cache?before_ts=<timestamp_ms> elimină mediile media la distanță memorate în cache al căror ultim acces a fost înainte de întrerupere. Dacă un utilizator solicită ulterior un fișier la distanță eliminat, Synapse îl poate solicita din nou de la serverul de origine.

Ambele endpoint-uri utilizează o marcă temporală Unix pozitivă în milisecunde, iar limita de timp pentru media se bazează pe ultimul acces, nu doar pe data încărcării sau creării. API-ul de ștergere a media locală elimină fișierul și miniaturile din memoria proprie a Synapse, inclusiv copiile stocate în cache local ale fișierelor la distanță; nu curăță un depozit media extern. Răspunsul raportează numărul de elemente șterse. Verificați API-ul de administrare media Synapse pentru parametrii actuali și detaliile endpoint-ului înainte de a rula o solicitare.

Pentru exemplul Northstar, un administrator ar testa mai întâi limita de stocare în raport cu politica aprobată și ar verifica dacă ID-urile sau numărul returnate de endpoint corespund așteptărilor. Dacă memoria cache la distanță este singura sursă de creștere, eliminarea încărcărilor locale ar fi o operațiune greșită. Dacă încărcările locale trebuie să rămână disponibile, alegeți o durată de viață locală mai lungă sau evitați endpoint-ul de eliminare a suportului media local.

Măsurați rezultatul și schimbați cursul atunci când este necesar

După fiecare job, verificați dacă epurarea s-a finalizat cu succes, examinați numărul de răspunsuri API, confirmați că sălile reprezentative afișează limita istorică așteptată și comparați separat utilizarea bazei de date și a depozitului media. O reducere a rândurilor bazei de date poate să nu apară imediat ca o reducere egală a utilizării discului sistemului de operare; recuperarea spațiului bazei de date depinde de motorul bazei de date și de procedurile sale de întreținere. Urmați instrucțiunile furnizorului bazei de date în loc să ștergeți manual fișierele bazei de date.

Dacă baza de date se micșorează, dar depozitul media nu, verificați păstrarea mediilor, lucrătorul media cu enable_media_repostarea , carantina sau protecția și dacă fișierele sunt stocate extern. Dacă utilizarea mediilor scade, dar mesajele vechi rămân, acest lucru este așteptat atunci când au fost eliminate doar mediile. Dacă evenimentele persistă în mod neașteptat, verificați dacă păstrarea este activată, dacă camera are propria stare de păstrare, dacă evenimentele locale au fost păstrate intenționat și dacă starea de eliminare este finalizată.

Pentru Northstar, criteriul de succes nu este pur și simplu „discul este mai mic”. Ci este ca limita aprobată a istoricului vechi să fie vizibilă, mesajele și atașamentele actuale necesare să funcționeze în continuare, categoria media dorită să fie curățată și ambele copii de rezervă să rămână disponibile. Dacă aceste verificări eșuează, opriți epurările ulterioare și inspectați politica camerei, răspunsul API, configurația worker-ului și backend-ul de stocare înainte de a extinde curățarea.

Limite de reținut

Politicile de păstrare nu înlocuiesc revizuirea legală sau revizuirea privind păstrarea înregistrărilor de către o organizație. Federarea înseamnă că alte servere principale pot păstra propriile copii ale evenimentelor sau fișierelor media, iar Synapse nu poate garanta ștergerea de pe aceste servere. Ștergerea la distanță a fișierelor media elimină memoria cache a acestui server; nu șterge fișierul sursă de pe serverul principal de origine. De asemenea, ștergerea unui eveniment local sau a unui obiect media din Synapse nu reia o copie deja descărcată de un alt participant.

Folosește retenția programată atunci când ai nevoie de o politică repetabilă; folosește API-urile de administrare pentru o curățare revizuită și țintită. Păstrează cele două operațiuni separat în înregistrarea modificărilor, deoarece semnalele și efectele lor de succes sunt diferite.