Hacer copias de un servidor propio: lo que falla de verdad

En resumen

• La regla 3-2-1: tres copias de los datos, en dos soportes, una de ellas fuera de línea, y al menos una en otro emplazamiento.
• Una base de datos se copia con sus propias herramientas, nunca copiando su carpeta mientras funciona.
• Una copia de seguridad solo existe una vez restaurada, y la restauración se juzga por el contenido, no por el código de retorno.
• En un servidor de producción, nada de limpieza global: un inventario escrito de los servicios y sus volúmenes, y órdenes específicas.

Por qué no basta con una copia que se ejecuta

Hacer copias de seguridad de un servidor autoalojado cabe en una regla conocida: tres copias, dos soportes, una copia aparte. Lo que protege de verdad es añadir restauraciones probadas en serio. Todo lo demás es detalle de ejecución, pero es en ese detalle donde se pierden los datos.

Nuestro servidor hace funcionar una docena de servicios en contenedores Docker, detrás de un enrutador Traefik: el CRM Twenty, la automatización n8n, las estadísticas Matomo, la firma electrónica, la facturación y modelos de IA. Lo que sigue viene de esa explotación, incluidos nuestros errores, y son las reglas de nuestra salida del SaaS, entregada con copias de seguridad automáticas fuera del servidor y una restauración probada.

La regla 3-2-1, y lo que no dice

La CNIL, la autoridad francesa de protección de datos, la presenta como el estado de la técnica en su ficha sobre la copia de seguridad de los datos: tres copias de los datos, en dos soportes distintos, una de ellas fuera de línea. La misma ficha recomienda guardar al menos una en un emplazamiento geográficamente distinto, y advierte contra las copias conservadas en los mismos sistemas que los datos sin estar aisladas: un ransomware podría entonces alcanzar unas y otros.

Para un servidor alquilado, esto da en concreto tres copias:

Este último punto cuenta: si un atacante o un error de script obtiene permisos en el servidor, no debe poder borrar la copia remota con las mismas claves.

Lo que la regla no dice es cómo copiar una base de datos en uso, ni cómo saber que la copia sirve para algo. Ahí es donde falla.

Lo que falla de verdad

1. La base copiada como una simple carpeta

Copiar el directorio de datos de una base PostgreSQL mientras funciona no da una copia de seguridad fiable. La documentación de PostgreSQL sobre la copia a nivel de sistema de archivos lo dice sin rodeos: el servidor de base de datos debe detenerse para obtener una copia utilizable, salvo que se use una instantánea coherente del volumen. Una base se copia, por tanto, con sus propias herramientas: una exportación lógica (pg_dump) para las bases pequeñas, o una copia base completada con el archivado continuo del registro de transacciones (WAL) para las más grandes.

Este segundo mecanismo permite volver a un instante preciso. La documentación de PostgreSQL sobre el archivado continuo lo explica: reproduciendo el registro hasta el momento deseado, se recupera la base tal como estaba en cualquier instante desde la copia base. De ahí saca una consigna:

La palabra «test» está en la documentación oficial: no es una precaución de agencia.

2. El volumen olvidado

Con Docker, los datos útiles viven en volúmenes o carpetas montadas. Un servicio añadido deprisa, con un volumen que nadie ha añadido al script de copia, y el día de la avería se descubre que nunca se copió. El remedio es simple y eficaz: una lista escrita de los servicios, sus volúmenes y su método de copia, releída cada vez que se añade un servicio.

3. La orden de limpieza global

Es nuestro error, y lo contamos porque es instructivo.

La documentación de docker system prune es sin embargo clara: por defecto, elimina todos los contenedores detenidos, las redes que ningún contenedor usa, las imágenes huérfanas (sin etiqueta) y la caché de compilación no utilizada; con la opción --all, todas las imágenes no utilizadas. En un servidor donde un servicio está detenido momentáneamente, «no utilizado» puede querer decir «en producción, pero no en este instante».

Los volúmenes no se eliminan por defecto, para no borrar datos importantes que ningún contenedor usa en ese instante: es lo que salvó nuestros datos. Con la opción --volumes, eso deja de ser cierto para los volúmenes anónimos.

Nuestro consejo: en un servidor de producción, nada de limpieza global, una limpieza específica en su lugar, y un inventario de servicios al día. Un incidente que no deja una regla escrita se repetirá.

4. La copia nunca restaurada

El caso más silencioso. El script se ejecuta cada noche, no señala ningún error, y nadie ha comprobado nunca que el archivo se descomprime, que la base se recarga, que la aplicación arranca sobre ella. Una copia de seguridad solo existe a partir del día en que se ha restaurado con éxito.

Y el éxito se juzga por el contenido, no por el código de retorno. En uno de los proyectos que operamos, la herramienta de restauración devolvía un error por simples advertencias: por eso validamos una restauración por el número de tablas y registros recuperados.

5. La alerta que no sale

Un script de copia que falla sin avisar es peor que no tener script, porque da una falsa seguridad. Cada copia debe enviar una señal en caso de fallo, e idealmente una señal cuando no se ha ejecutado en absoluto.

El procedimiento que recomendamos

Para una pyme que hace funcionar algunos servicios en un servidor propio:

• Cada noche: exportación de cada base con su herramienta, copia de los volúmenes listados, envío cifrado a un almacenamiento remoto con sus propias credenciales.
• Cada semana: comprobación automática de que los archivos de la noche existen, tienen un tamaño plausible y se descomprimen.
• Cada trimestre: restauración completa de un servicio en un contenedor desechable o en una máquina de prueba, cronometrada y validada por el contenido. El tiempo medido se convierte en su plazo real de recuperación, el que puede anunciar a la dirección.
• Con cada nuevo servicio: actualización del inventario y del script, antes de la puesta en producción, no después.
• Retención: copias diarias durante algunas semanas, copias mensuales durante más tiempo. La duración depende de sus obligaciones y de sus datos personales: guardar datos más tiempo del necesario no es una seguridad, es una deuda.

Los límites honestos

Este procedimiento protege contra la pérdida de datos. No garantiza la disponibilidad: restaurar un servicio lleva tiempo, y durante ese tiempo está detenido. Si su actividad no soporta unas horas de interrupción, hace falta redundancia (un segundo servidor listo para tomar el relevo), lo que cambia el coste. Es una línea que integrar en el cálculo del coste real de salir del SaaS a tres años.

Por dónde empezar

Escriba el inventario: cada servicio, su base, sus volúmenes y su método de copia. Luego restaure un servicio completo, aunque sea pequeño, y anote el tiempo que lleva. Las copias de seguridad son solo una pieza de la base de infraestructura común a sus proyectos, junto a los accesos, la supervisión y los presupuestos. Si aún no tiene servidor, empiece por una herramienta poco crítica, como aconseja nuestra guía de las herramientas que autoalojar primero. Para delegar, la gestión externalizada de nuestra salida del SaaS cubre la supervisión, las actualizaciones y copias de seguridad probadas. Los demás temas de explotación están en nuestra sección de infraestructura y nube.

Preguntas frecuentes

Fuentes

1. Ficha sobre la copia de seguridad de los datos (nueva pestaña)cnil.fr
2. Documentación de PostgreSQL sobre la copia a nivel de sistema de archivos (nueva pestaña)postgresql.org
3. Documentación de PostgreSQL sobre el archivado continuo (nueva pestaña)postgresql.org
4. Documentación de docker system prune (nueva pestaña)docs.docker.com