Scenario di esempio (solo a scopo illustrativo): Northstar Community, un'ipotetica organizzazione no-profit, gestisce un homeserver Matrix Synapse. Il suo database e l'archivio multimediale sono in crescita e l'amministratore desidera rimuovere la cronologia delle stanze e i file multimediali obsoleti senza cancellare accidentalmente le discussioni correnti o le immagini del profilo. Questo esempio non rappresenta una descrizione di un'implementazione reale né un risultato testato.
Il segreto sta nel trattare la cronologia dei messaggi e i file multimediali come operazioni di pulizia separate. Synapse offre un'API per la pulizia della cronologia delle stanze e strumenti separati per la pulizia dei file multimediali; un'impostazione di conservazione dei file multimediali può anche rimuovere i file mantenendo intatti gli eventi Matrix che vi fanno riferimento. Innanzitutto, è necessario decidere cosa deve rimanere disponibile, quindi eseguire il backup del database e dell'archivio multimediale, scegliere il metodo appropriato e infine verificare entrambe le aree di archiviazione.
Decidi cosa significa "vecchio" per il tuo server
Prima di modificare la configurazione o di richiamare un endpoint distruttivo, è necessario definire una regola di conservazione. Nell'esempio di Northstar, si supponga che il consiglio di amministrazione approvi la conservazione della cronologia delle stanze per 180 giorni, applichi una politica simile ai caricamenti locali e consideri i file multimediali remoti come una cache da cui è possibile recuperare i dati in caso di necessità. Un'altra organizzazione potrebbe richiedere periodi di conservazione più lunghi per motivi legali, operativi o di condivisione. Questi periodi sono solo esempi e non raccomandazioni universali.
Suddividere i dati in due categorie:
- Eventi della stanza: messaggi e altri eventi memorizzati nel database di Synapse. L'eliminazione degli eventi modifica la quantità di dati che gli utenti possono visualizzare nella stanza.
- Media: file caricati, miniature e copie memorizzate nella cache di file provenienti da altri homeserver. Questi risiedono nel repository multimediale o in un repository esterno configurato.
La documentazione ufficiale di Synapse descrive separatamente le politiche di conservazione degli eventi e la pulizia dei file multimediali. La cancellazione della cronologia di una stanza non garantisce di per sé la pulizia dell'archivio multimediale, e l'eliminazione di un file multimediale non cancella l'evento ad esso collegato. Inizia annotando le dimensioni del database, le dimensioni dell'archivio multimediale, le stanze interessate e la data limite prevista. Consulta il manuale di configurazione di Synapse .
Eseguire un backup prima di procedere alla pulizia.
Eseguite un backup del database seguendo la procedura consigliata per il vostro motore di database e create un backup anche del repository multimediale o dell'archivio multimediale esterno. Un backup del database da solo non conserva i file caricati; un backup dei file multimediali da solo non ripristina gli eventi della sala. Prima di procedere, verificate che i backup siano leggibili e che sappiate come ripristinarli. Se Synapse viene eseguito in container o utilizza worker separati, includete la configurazione e i volumi di archiviazione pertinenti nel vostro piano di manutenzione.
Nel caso ipotetico del server di Northstar, l'amministratore registra le dimensioni del database e dello spazio di archiviazione multimediale e conferma un punto di ripristino recente prima di intervenire sulle stanze condivise. Questo è utile perché una "pulizia" ha successo solo se rimuove i dati desiderati lasciando recuperabili i contenuti necessari.
Scegli la conservazione programmata per la pulizia continua
Se si desidera che Synapse continui ad applicare una policy, è necessario configurare separatamente la conservazione degli eventi e dei file multimediali nella configurazione del server principale. Ad esempio, un amministratore potrebbe adattare questo esempio a un server la cui policy approvata prevede 180 giorni per la cronologia delle stanze e i file multimediali locali, con una cache per i file multimediali remoti di 30 giorni:
retention:
enabled: true
default_policy:
max_lifetime: 180d
media_retention:
local_media_lifetime: 180d
remote_media_lifetime: 30d
Questa è una configurazione esemplificativa, non una policy da applicare automaticamente a ogni server. Synapse documenta che la funzionalità di conservazione degli eventi è disabilitata per impostazione predefinita. Questa default_policyimpostazione si applica alle stanze che non dispongono di un m.room.retentionevento di stato; gli amministratori delle stanze possono impostare le policy delle stanze, mentre gli amministratori dei server possono limitare la durata delle policy utilizzando le impostazioni di durata consentita documentate. Se è necessario un limite superiore coerente, è consigliabile esaminare tali controlli e le policy delle stanze già in uso, anziché presumere che l'impostazione predefinita sia valida per tutte le stanze.
La durata di conservazione dei file multimediali si basa sul tempo trascorso dall'ultimo accesso a un elemento multimediale. Se un elemento non è mai stato consultato, Synapse utilizza il suo orario di creazione. L'impostazione si applica agli originali e alle miniature; le durate di conservazione non impostate o nulle non eliminano quella categoria di file multimediali. Un elemento memorizzato nella cache remota può essere richiesto nuovamente dalla sua origine dopo essere stato eliminato. I file multimediali in quarantena e quelli protetti localmente costituiscono un'eccezione e non vengono rimossi da queste impostazioni di conservazione. La pulizia dei file multimediali viene eseguita sul processo o sul worker di Synapse che ha enable_media_repoabilitato questa opzione. Consultare la documentazione corrente relativa a retention e media_retention , quindi applicare la configurazione utilizzando la normale procedura di riavvio o distribuzione per la propria installazione.
Prima di adottare l'esempio, confronta il suo comportamento con le tue esigenze. Se un messaggio di una stanza deve rimanere leggibile con il relativo allegato per 180 giorni, non scegliere un periodo di conservazione dei file multimediali più breve a meno che tu non accetti che il messaggio possa sopravvivere alla conservazione del file locale. Verifica se i tuoi file multimediali sono archiviati direttamente in Synapse o in un repository esterno; l'API di Synapse per l'eliminazione dei file multimediali locali non rimuove i file multimediali archiviati in un repository esterno.
Elimina gli eventi delle stanze più vecchie su richiesta
Per una pulizia una tantum, utilizzare l'API di amministrazione di Synapse per la cancellazione della cronologia. Questa operazione richiede un token di accesso di amministratore del server ; essere amministratore di una singola stanza non equivale a disporre della stessa autorizzazione. Synapse consiglia di mantenere l'API di amministrazione nascosta al pubblico e di effettuare queste richieste in genere dal server o da un host di amministrazione affidabile. Non incollare un token di accesso attivo nella cronologia della shell condivisa, nei ticket o nei log.
La richiesta deve specificare un limite temporale utilizzando un ID evento o un timestamp Unix in millisecondi. Il seguente esempio di shell è illustrativo. Sostituisci homeserver, room ID, token variable e sample cutoff con i valori che hai esaminato. L'esempio richiede esplicitamente anche la cancellazione degli eventi dei messaggi dell'utente locale:
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"
Senza delete_local_events: true, Synapse conserva per impostazione predefinita gli eventi inviati dagli utenti locali; gli eventi inviati da remoto possono essere eliminati. Lo stato della stanza, come l'appartenenza e lo stato dell'argomento, viene conservato. Synapse conserva anche almeno un messaggio in ogni stanza. L'operazione può richiedere diversi minuti o più e gli utenti non possono tornare indietro nella porzione in fase di eliminazione mentre è in corso. L'API restituisce immediatamente un ID di eliminazione; eseguire il polling /_synapse/admin/v1/purge_history_status/<purge_id>finché lo stato non è completeo esaminare l'errore se è failed. Consultare la documentazione dell'API Purge History prima di selezionare un cutoff. In particolare, verificare se la rimozione degli eventi locali è appropriata per le proprie stanze.
Pulire separatamente i supporti locali e la cache remota.
Per le operazioni di pulizia ricorrenti, scegli media_retentione utilizza i periodi di validità che corrispondono alla disponibilità che prometti agli utenti. Per una pulizia una tantum, Synapse offre endpoint distinti:
- File multimediali locali:
POST /_synapse/admin/v1/media/delete?before_ts=<timestamp_ms> rimuove i file multimediali locali idonei in base all'ora dell'ultimo utilizzo. L'API accetta anche una soglia di dimensione. I file multimediali del profilo e dell'avatar della stanza vengono conservati per impostazione predefinita; non disabilitare questa protezione a meno che non si siano valutate attentamente le conseguenze.
- File multimediali remoti memorizzati nella cache:
POST /_synapse/admin/v1/purge_media_cache?before_ts=<timestamp_ms> rimuove i file multimediali remoti memorizzati nella cache il cui ultimo accesso risale a prima della data limite. Se un utente richiede successivamente un file remoto rimosso, Synapse può richiederlo nuovamente al server di origine.
Entrambi gli endpoint utilizzano un timestamp Unix positivo in millisecondi e il limite di accesso ai file multimediali si basa sull'ultimo accesso, non semplicemente sulla data di caricamento o creazione. L'API per l'eliminazione dei file multimediali locali rimuove il file e le miniature dalla memoria interna di Synapse, incluse le copie memorizzate nella cache locale dei file remoti; non elimina i file da un repository multimediale esterno. La risposta riporta il numero di elementi eliminati. Prima di eseguire una richiesta, consultare la documentazione dell'API di amministrazione multimediale di Synapse per i parametri e i dettagli degli endpoint aggiornati.
Nell'esempio di Northstar, un amministratore dovrebbe innanzitutto testare il valore limite rispetto alla policy approvata e verificare se gli ID o i conteggi restituiti dall'endpoint corrispondono alle aspettative. Se la cache remota è l'unica fonte di crescita, la cancellazione dei caricamenti locali sarebbe un'operazione errata. Se i caricamenti locali devono rimanere disponibili, è consigliabile scegliere un periodo di validità locale più lungo o evitare l'endpoint di cancellazione dei supporti locali.
Valutare i risultati e, se necessario, modificare la strategia.
Dopo ogni operazione, verificare che la pulizia sia stata completata correttamente, esaminare il numero di risposte API, confermare che le stanze rappresentative mostrino il limite di cronologia previsto e confrontare separatamente l'utilizzo del database e dell'archivio multimediale. Una riduzione delle righe del database potrebbe non tradursi immediatamente in una pari riduzione dell'utilizzo del disco del sistema operativo; il recupero dello spazio del database dipende dal motore del database e dalle relative procedure di manutenzione. Seguire le indicazioni del fornitore del database anziché eliminare manualmente i file del database.
Se il database si riduce ma l'archivio multimediale rimane invariato, verificare la conservazione dei media, il media worker con enable_media_repostato di quarantena o protezione e se i file sono archiviati esternamente. Se l'utilizzo dei media diminuisce ma rimangono messaggi vecchi, è normale quando è stata eliminata solo la parte multimediale. Se gli eventi rimangono inaspettatamente, verificare se la conservazione è abilitata, se la stanza ha un proprio stato di conservazione, se gli eventi locali sono stati conservati intenzionalmente e se lo stato di eliminazione è completo.
Per Northstar, il criterio di successo non è semplicemente "il disco è più piccolo". Il criterio è che il limite approvato per la cronologia precedente sia visibile, che i messaggi e gli allegati correnti richiesti funzionino ancora, che la categoria di supporti prevista sia stata pulita e che entrambi i backup siano ancora disponibili. Se questi controlli falliscono, interrompere ulteriori operazioni di pulizia e ispezionare i criteri della stanza, la risposta dell'API, la configurazione del worker e il backend di archiviazione prima di estendere la pulizia.
Limiti da tenere a mente
Le politiche di conservazione non sostituiscono le procedure legali o le normative sulla conservazione dei dati di un'organizzazione. La federazione implica che altri server domestici possano conservare copie proprie di eventi o contenuti multimediali e Synapse non può garantire la cancellazione da tali server. La cancellazione remota dei contenuti multimediali rimuove la cache di questo server; non elimina il file sorgente sul server domestico di origine. Allo stesso modo, l'eliminazione di un evento o di un oggetto multimediale locale da Synapse non ripristina una copia già scaricata da un altro partecipante.
Utilizza la conservazione programmata quando hai bisogno di una policy ripetibile; utilizza le API di amministrazione per una pulizia mirata e verificata. Mantieni separate le due operazioni nel tuo registro delle modifiche, poiché i relativi segnali di successo ed effetti sono diversi.