Backup para mailcow — guía
Instalación
- El módulo viene con el mailcow Toolkit 0.7.0 o más reciente (un paquete, una licencia por producto). En el host de mailcow, como root, ejecuta el instalador del Toolkit como siempre:
sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized --name <instance>, o actualiza el Toolkit desde System → Updates (Toolkit). El instalador copiadata/web/mlw-backup/, instala el script del host/usr/local/sbin/mlw-mailcow-backup-<instance>y crea la tabla del historial y el temporizadormlw-mailcow-backup-<instance>.timer(cada 5 minutos comprueba si toca hacer una copia). - Instala GnuPG en el host si falta:
apt install gnupg. - Abre System → Backup en el menú de administración de mailcow.
Licencia
Abre System → Updates (Toolkit) y busca la tarjeta Backup for mailcow: pega la clave y actívala, o empieza la prueba de 30 días. Por consola: php /web/mlw-toolkit/cli.php activate mailcow-backup <KEY> dentro de php-fpm-mailcow.
Sin licencia válida se detienen las copias programadas y las subidas a Google Drive. Verificar, restaurar y borrar siguen funcionando, así que siempre puedes recuperar tus datos.
Primera configuración
- Settings → Local folder: una ruta absoluta en el host, idealmente en un disco distinto del de mailcow (por ejemplo
/srv/backup/mailcowo un disco montado). Se crea legible solo por root. Deja espacio para unas dos copias. - Encryption: pulsa Set con generated (recommended): la frase de contraseña se muestra una sola vez — guárdala fuera del servidor (gestor de contraseñas, papel). O elige my own y escribe dos veces una de al menos 12 caracteres.
- Back up now en la tarjeta Status hace la primera copia; el progreso y el registro se muestran en directo.
Programación, componentes y retención
En Settings:
- Scheduled backups activado o desactivado; Times (hora del servidor, se admiten varias, p. ej.
03:15, 15:15) y Days. - What is backed up: correo (vmail), claves de cifrado (crypt — necesarias para leer el correo cifrado), redis, rspamd, postfix, base de datos (SQL). Todos están activados por defecto.
- Local copies kept y Copies kept on Drive: se quedan las N más recientes; las más antiguas se borran tras cada copia.
- Compression threads para el script de mailcow.
- E-mail: solo en caso de fallo (por defecto), tras cada copia o nunca; dirección vacía = la dirección de notificaciones del Toolkit.
Una copia que se perdió mientras el servidor estaba apagado se ejecuta una vez cuando vuelve a estar en marcha. Las copias programadas se ejecutan con baja prioridad de CPU y de disco.
Qué es una copia
El propio backup_and_restore.sh de mailcow escribe los componentes elegidos; el módulo los empaqueta en un único archivo y lo cifra con GnuPG (AES-256, con protección de integridad) con tu frase de contraseña:
| Archivo | Contenido |
|---|---|
mailcow-<host>-<date>.tar.gpg |
el archivo cifrado (los archivos backup_*.tar.zst de mailcow y su mailcow.conf) |
mailcow-<host>-<date>.json |
el manifiesto: componentes y tamaños, SHA-256 del archivo cifrado, id de la frase de contraseña, versiones de mailcow y del Toolkit |
Sin mailcow: gpg -d mailcow-…tar.gpg > backup.tar pide la frase de contraseña y devuelve la carpeta de copia de seguridad habitual de mailcow.
Google Drive
El módulo usa tu propio cliente OAuth de Google, así que el acceso a tu Drive se queda en tu servidor:
- En Google Cloud Console, crea (o elige) un proyecto y activa la Google Drive API.
- OAuth consent screen: tipo External, tu correo como contacto de soporte y de desarrollador; después Publish app («In production»). En modo de prueba, Google hace caducar el acceso a los 7 días.
- Credentials → Create credentials → OAuth client ID, tipo Web application, con la URI de redirección que muestra la página:
https://<your mailcow UI host>/mlw-backup/oauth.php. - Pega el Client ID y el client secret en Google Drive en la página, pulsa Save y después Connect Google Drive, y permite el acceso. Puede que Google avise de que la app no está verificada: es tu propia app, continúa.
- En Settings, activa Upload every backup to Google Drive y elige el nombre de la carpeta.
El alcance (scope) es drive.file: el módulo solo ve los archivos que ha creado, nunca el resto de tu Drive. Las subidas van en partes de 32 MiB y continúan tras un error de red. Test lista la carpeta; Disconnect revoca el acceso (las copias se quedan en Drive).
Verificar y restaurar
En Backups cada copia muestra dónde está (local, Drive o ambos):
- Verify: descifra y lee el archivo cifrado entero (descargado de Drive si no está en local) sin restaurar nada.
- Restore…: marca los componentes, escribe
RESTOREy confirma. El SHA-256 del archivo se comprueba contra su manifiesto, se descifra y se comprueban sus rutas, y después cada componente se restaura con los pasos de la propia restauración de mailcow: los contenedores afectados se detienen y se vuelven a arrancar; la base de datos detiene todo mailcow durante unos minutos y toma las credenciales SQL delmailcow.confde la copia. Lo que cambió en esos componentes después de la fecha de la copia se pierde. No se ejecuta ninguna resincronización forzada del correo; si después un buzón parece incorrecto:docker exec $(docker ps -qf name=dovecot-mailcow) doveadm force-resync -A '*'. - Delete: borra la copia en local y en Drive.
Un servidor nuevo
- Instala mailcow y el Toolkit, activa la licencia (o restaura sin ella).
- Encryption → my own: escribe la frase de contraseña antigua (en un servidor que ya tiene una, marca for older backups only).
- Google Drive: usa el mismo cliente OAuth de Google y conéctalo; aparecen las copias antiguas (el módulo ve los archivos que creó su cliente).
- Restore… de la copia más reciente, todos los componentes.
Consola y archivos
El script del host se puede ejecutar a mano (como root): MLW_TK_CONF=/etc/mlw-mailcow-toolkit/<instance>.conf mlw-mailcow-backup-<instance> backup|verify NAME|list. El progreso está en data/hooks/phpfpm/.mlw-toolkit/backup/run.json y run.log; el historial, en la tabla mlw_bk_run de la base de datos de mailcow. uninstall.sh conserva las copias locales y las de Drive.