Cómo eliminar el historial de mensajes y archivos multimedia antiguos en Matrix Synapse

Escenario de ejemplo (solo a modo ilustrativo): Northstar Community, una organización sin ánimo de lucro hipotética, utiliza un servidor doméstico Matrix Synapse. Su base de datos y su repositorio multimedia están creciendo, y el administrador desea eliminar el historial de salas antiguas y el contenido multimedia obsoleto sin borrar accidentalmente las discusiones actuales ni las imágenes de perfil. Este ejemplo no constituye un informe de una implementación real ni un resultado probado.

La clave está en tratar el historial de mensajes y los archivos multimedia como tareas de limpieza independientes. Synapse cuenta con una API para eliminar el historial de salas y herramientas de limpieza de archivos multimedia independientes; además, la configuración de retención de archivos multimedia permite eliminar archivos, aunque los eventos de Matrix que los referencian permanecen. Primero, decida qué archivos deben permanecer disponibles, luego realice una copia de seguridad de la base de datos y del almacenamiento de archivos multimedia, seleccione el método adecuado y verifique ambas áreas de almacenamiento posteriormente.

Decide qué significa "antiguo" para tu servidor.

Antes de modificar la configuración o llamar a un punto final destructivo, defina una regla de retención. En el ejemplo de Northstar, supongamos que la junta aprueba conservar el historial de la sala durante 180 días, mantener las cargas locales bajo una política similar y tratar los archivos multimedia remotos como una caché que se puede recuperar si es necesario. Otra organización podría necesitar años de retención por motivos legales, operativos o comunitarios. Estos plazos son solo ejemplos, no recomendaciones universales.

Separe los datos en dos categorías:

• Eventos de la sala: mensajes y otros eventos almacenados en la base de datos de Synapse. La eliminación de eventos modifica el historial de navegación que los usuarios pueden consultar en la sala.
• Multimedia: archivos subidos, miniaturas y copias en caché de archivos de otros servidores. Estos se encuentran en el repositorio multimedia o en un repositorio externo configurado.

La documentación oficial de Synapse describe las políticas de retención para eventos y la limpieza de medios de forma independiente. La eliminación del historial de salas no garantiza la limpieza del almacenamiento de medios, y la eliminación de un archivo multimedia no borra el evento vinculado a él. Comience registrando el tamaño de la base de datos, el tamaño del almacenamiento de medios, las salas afectadas y la fecha límite prevista. Consulte el manual de configuración de Synapse .

Realice una copia de seguridad antes de purgar.

Realice una copia de seguridad de la base de datos siguiendo el procedimiento recomendado para su motor de base de datos, y también una copia de seguridad del repositorio de medios o del almacenamiento externo de medios. Una copia de seguridad de la base de datos por sí sola no conserva los archivos cargados; una copia de seguridad de los medios por sí sola no restaura los eventos de la sala. Confirme que las copias de seguridad sean legibles y que sepa cómo restaurarlas antes de continuar. Si Synapse se ejecuta en contenedores o utiliza procesos independientes, incluya la configuración y los volúmenes de almacenamiento correspondientes en su plan de mantenimiento.

Para el servidor hipotético de Northstar, el administrador registra el tamaño de la base de datos y del almacenamiento multimedia, y confirma un punto de restauración reciente antes de acceder a las salas compartidas. Esto resulta útil porque una "limpieza" solo es exitosa si elimina los datos previstos y, al mismo tiempo, permite recuperar el contenido necesario.

Seleccione la opción de retención programada para la limpieza continua.

Si desea que Synapse siga aplicando una política, configure la retención de eventos y la retención de medios por separado en la configuración del servidor principal. Por ejemplo, un administrador podría adaptar este ejemplo para un servidor cuya política aprobada sea de 180 días para el historial de salas y los medios locales, con una caché de medios remotos de 30 días:

retention:
  enabled: true
  default_policy:
    max_lifetime: 180d

media_retention:
  local_media_lifetime: 180d
  remote_media_lifetime: 30d

Esta es una configuración ilustrativa, no una política aplicable a todos los servidores. Synapse documenta la función de retención de eventos como deshabilitada por defecto. Esto default_policyse aplica a las salas que no tienen un m.room.retentionevento de estado; los administradores de salas pueden establecer políticas para las salas, mientras que los administradores de servidores pueden limitar la duración de las políticas con la configuración de tiempo de vida permitido documentada. Si necesita un límite superior consistente, revise esos controles y las políticas de sala que ya utiliza, en lugar de asumir que la configuración predeterminada cubre todas las salas.

La duración de los archivos multimedia se basa en el tiempo transcurrido desde el último acceso a un elemento. Si un elemento nunca se ha accedido, Synapse utiliza su fecha de creación. Esta configuración se aplica a los originales y las miniaturas; las duraciones no definidas o nulas no eliminan esta categoría de archivos multimedia. Un elemento almacenado en caché remoto puede volver a solicitarse a su origen después de haber sido eliminado. Los archivos multimedia en cuarentena y los archivos multimedia protegidos localmente son excepciones y no se eliminan con esta configuración de retención. La limpieza de archivos multimedia se ejecuta en el proceso o trabajador de Synapse que esté enable_media_repohabilitado. Consulte la referencia actual de retención y media_retention y, a continuación, aplique la configuración mediante el procedimiento normal de reinicio o implementación de su instalación.

Antes de adoptar el ejemplo, compare su comportamiento con sus necesidades. Si un mensaje de sala debe permanecer legible con su archivo adjunto durante 180 días, no elija un tiempo de vida del archivo más corto a menos que acepte que el mensaje pueda sobrevivir al archivo disponible localmente. Verifique si su archivo multimedia está almacenado en Synapse o en un repositorio externo; la API de eliminación de archivos multimedia locales de Synapse no elimina los archivos multimedia almacenados en un repositorio externo.

Elimine los eventos de sala antiguos bajo demanda.

Para una limpieza puntual, utilice la API de administración de Synapse Purge History. Esto requiere un token de acceso de administrador del servidor ; ser administrador de una sala individual no otorga el mismo permiso. Synapse recomienda mantener la API de administración oculta al público y, por lo general, realizar estas solicitudes desde el servidor o un host de administración de confianza. No copie ni pegue un token de acceso en vivo en el historial de la consola compartida, los tickets ni los registros.

La solicitud debe especificar un límite mediante un ID de evento o una marca de tiempo Unix en milisegundos. El siguiente ejemplo de shell es ilustrativo. Reemplace homeserver, room ID, token variable y sample cutoff con los valores que haya revisado. El ejemplo también solicita explícitamente la eliminación de eventos de mensajes de usuarios locales:

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"

Sin delete_local_events: trueSynapse, Synapse conserva los eventos enviados por usuarios locales de forma predeterminada; los eventos enviados remotamente se pueden eliminar. El estado de la sala, como la membresía y el estado del tema, se conserva. Synapse también mantiene al menos un mensaje en cada sala. La operación puede tardar varios minutos o más, y los usuarios no pueden paginar más hacia atrás en la parte que se está purgando mientras se ejecuta. La API devuelve un ID de purga inmediatamente; sondee /_synapse/admin/v1/purge_history_status/<purge_id>hasta que el estado sea completeo investigue el error si es failed. Consulte la documentación de la API de historial de purga antes de seleccionar un límite. En particular, revise si eliminar los eventos locales es apropiado para sus salas.

Limpiar los medios locales y la caché remota por separado

Para la limpieza recurrente, utilice media_retentiony seleccione periodos de tiempo que se ajusten a la disponibilidad que promete a los usuarios. Para una limpieza puntual, Synapse proporciona distintos puntos finales:

• Archivos locales: POST /_synapse/admin/v1/media/delete?before_ts=<timestamp_ms> elimina los archivos multimedia locales que cumplen los requisitos según su última fecha de uso. La API también acepta un límite de tamaño. Los archivos multimedia de perfil y avatar de sala se conservan de forma predeterminada; no desactive esta protección a menos que haya revisado detenidamente las consecuencias.
• Archivos multimedia remotos en caché: POST /_synapse/admin/v1/purge_media_cache?before_ts=<timestamp_ms> elimina los archivos multimedia remotos almacenados en caché cuyo último acceso se produjo antes de la hora límite. Si un usuario solicita posteriormente un archivo remoto eliminado, Synapse puede volver a solicitarlo al servidor de origen.

Ambos puntos de acceso utilizan una marca de tiempo Unix positiva en milisegundos, y el límite de acceso a los archivos multimedia se basa en el último acceso, no simplemente en la fecha de carga o creación. La API de eliminación de archivos multimedia locales elimina el archivo y las miniaturas del almacenamiento propio de Synapse, incluidas las copias en caché local de archivos remotos; no limpia un repositorio de archivos multimedia externo. La respuesta informa la cantidad de elementos eliminados. Consulte la API de administración de medios de Synapse para obtener los parámetros y detalles de los puntos de acceso actuales antes de realizar una solicitud.

En el ejemplo de Northstar, un administrador primero compararía el límite con la política aprobada y verificaría si los identificadores o recuentos devueltos por el punto final coinciden con las expectativas. Si la caché remota es la única fuente de crecimiento, eliminar las cargas locales sería una operación incorrecta. Si las cargas locales deben permanecer disponibles, elija un tiempo de vida local más prolongado o evite el punto final de eliminación de medios locales.

Mide el resultado y cambia de rumbo cuando sea necesario.

Tras cada tarea, compruebe que la purga se haya completado correctamente, revise el número de respuestas de la API, confirme que las salas representativas muestren el límite de historial previsto y compare el uso de la base de datos y del almacenamiento multimedia por separado. Una reducción en el número de filas de la base de datos puede no reflejarse inmediatamente en una reducción equivalente del uso del disco del sistema operativo; la recuperación del espacio de la base de datos depende del motor de la base de datos y de sus procedimientos de mantenimiento. Siga las instrucciones del proveedor de la base de datos en lugar de eliminar los archivos manualmente.

Si la base de datos se reduce pero el almacenamiento de medios no, revise la retención de medios, el trabajador de medios con enable_media_repoel estado de cuarentena o protección, y si los archivos se almacenan externamente. Si el uso de medios disminuye pero quedan mensajes antiguos, es normal cuando solo se eliminaron los medios. Si quedan eventos inesperadamente, compruebe si la retención está habilitada, si la sala tiene su propio estado de retención, si los eventos locales se conservaron intencionalmente y si el estado de eliminación es completo.

Para Northstar, el criterio de éxito no es simplemente que el disco sea más pequeño. Se trata de que el límite del historial antiguo aprobado sea visible, que los mensajes y archivos adjuntos actuales necesarios sigan funcionando, que la categoría de medios prevista se haya limpiado y que ambas copias de seguridad permanezcan disponibles. Si estas comprobaciones fallan, detenga las purgas posteriores e inspeccione la política de la sala, la respuesta de la API, la configuración del trabajador y el sistema de almacenamiento antes de ampliar la limpieza.

Límites a tener en cuenta

Las políticas de retención no sustituyen la revisión legal o de retención de registros de una organización. La federación implica que otros servidores domésticos pueden conservar sus propias copias de eventos o archivos multimedia, y Synapse no puede garantizar su eliminación de dichos servidores. La eliminación remota de archivos multimedia borra la caché de este servidor; no elimina el archivo original en su servidor de origen. Del mismo modo, eliminar un evento o archivo multimedia local de Synapse no recupera una copia que otro participante ya haya descargado.

Utilice la retención programada cuando necesite una política repetible; utilice las API de administración para una limpieza específica y revisada. Mantenga ambas operaciones separadas en su registro de cambios, ya que sus señales de éxito y efectos son diferentes.