AnnexGroup

Documentación

Copias de seguridad y restauración

En Administración → Copia de seguridad puede crear y gestionar copias de seguridad.

¿Qué se guarda?

  • Base de datos MySQL/MariaDB
  • Almacenamiento de blobs (adjuntos y cuerpos de mensajes)
  • Ajustes del servidor (opcional)
  • Claves DKIM (opcional)

Lo que no se guarda

  • El índice de búsqueda de texto completo. Es derivado y se reconstruye tras una restauración — véase el paso 4 más abajo. Sin ese paso, la búsqueda no encuentra nada, aunque todos los datos estén.
  • El certificado TLS. En una máquina nueva, el servidor obtiene uno nuevo en cuanto los registros DNS apuntan a ella.

Restauración por la interfaz

  1. Subir el archivo de copia de seguridad.
  2. Elegir el objetivo de la restauración (completa o selectiva).
  3. El servidor se reinicia al finalizar, si es necesario.

Restauración por línea de comandos

Este es el camino para el caso grave. La interfaz deja de responder exactamente cuando más la necesitaría — base de datos dañada, versión a medio desplegar, directorio borrado.

El comando trabaja sin servidor en marcha y se niega a funcionar mientras haya uno que responda. Es intencional: mientras se importa el volcado, un servicio en marcha sigue escribiendo en las mismas tablas, y el resultado es una mezcla de dos estados que solo se nota días después.

# Mostrar las copias de seguridad existentes
sudo annexgroup restore-backup --list

# Detener el servicio
sudo systemctl stop annexgroup

# Restaurar
sudo annexgroup restore-backup annexgroup-backup-20260831-090000.tar.gz

Traslado a otra máquina

El motivo más frecuente de una restauración no es un siniestro, sino un traslado: la máquina antigua debe desaparecer. El procedimiento es el mismo, con cuatro añadidos.

1. Crear una base de datos vacía. En la máquina nueva, con el mismo juego de caracteres:

CREATE DATABASE annexgroup CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'annexgroup'@'localhost' IDENTIFIED BY '<Contraseña>';
GRANT ALL PRIVILEGES ON annexgroup.* TO 'annexgroup'@'localhost';

2. Transferir el archivo y la configuración. El archivo pertenece al directorio de copias de seguridad de la nueva instalación (<directorio-de-datos>/backups). Compruebe en la configuración las rutas data_dir y database_dsn — de lo contrario, apuntan a directorios que no existen en la máquina nueva.

3. Restaurar, como arriba, con el servicio detenido.

4. Reconstruir el índice de búsqueda — con el servicio aún detenido:

sudo annexgroup reindex-search
sudo systemctl start annexgroup

En este orden, no al revés. El índice de búsqueda tolera exactamente un escritor. Si el servicio ya está en marcha, mantiene el bloqueo y reindex-search se interrumpe con un aviso al respecto.

Después, contar, no esperar. Una restauración solo está comprobada cuando ha comparado ambas cosas: inicie sesión por IMAP y por la interfaz web, abra un mensaje con adjunto y busque una palabra de la que sepa que aparece.

Nota: Pruebe las copias de seguridad regularmente en un entorno separado. Una copia que nunca se ha restaurado es una suposición, no una protección.

¿Algo poco claro o mal descrito? Díganoslo — lo corregiremos. Su pregunta nos muestra dónde flojea el texto.