Copias de seguridad del servidor: la regla 3-2-1 y cómo restaurar

La regla 3-2-1 dice: guarda tres copias de tus datos importantes (el original y dos copias de seguridad), en dos tipos de almacenamiento distintos, y deja al menos una copia en otro lugar. En un VPS, eso significa tener al menos una copia fuera del servidor, además de los datos del propio servidor.

La misma regla se recomienda en el documento Data Backup Options, elaborado para US-CERT y publicado en el sitio web de la CISA. Su objetivo es que un solo fallo, error o ataque no pueda destruir todas las copias a la vez.

Una copia de seguridad, un snapshot y la redundancia de disco no son lo mismo

• Copia de seguridad: una copia independiente de tus datos, normalmente con versiones anteriores. Recupera un archivo borrado o dañado por error.
• Snapshot: registra el estado del servidor en ese momento. Sirve para volver atrás rápido antes de una actualización importante. Pero depende del disco original, así que no sustituye a una copia de seguridad.
• Redundancia de disco: los mismos datos escritos en dos discos a la vez. Te protege cuando falla un disco. Un archivo que borras se borra de ambos discos, y los datos cifrados por un ransomware quedan cifrados en los dos. Por eso no es una copia de seguridad.

Cómo aplicar 3-2-1 en un VPS

Puedes contar la copia diaria del panel como una de tus copias. Pero la que cumple la condición de "en otro lugar" es la que configuras y controlas tú. Las condiciones del servicio de Seturack también piden que guardes aparte una copia de tus datos importantes.

Qué copiar

Copiar los archivos de una base de datos en funcionamiento puede dar una copia inconsistente. Haz primero un volcado. Estos comandos se ejecutan como root, igual que en un script de cron:

mysqldump --single-transaction --all-databases | gzip > /var/backups/mysql-$(date +%F).sql.gz

sudo -u postgres pg_dumpall | gzip > /var/backups/pg-$(date +%F).sql.gz

Para los archivos, basta con esto: /etc, los archivos de tu sitio web, la carpeta de datos de tu aplicación, los volúmenes de Docker si usas Docker y los archivos .env. No copies lo que puedes volver a descargar, como paquetes e imágenes de Docker. Si tu aplicación tiene una clave de cifrado, guárdala también por separado. En algunas aplicaciones, una copia sin la clave no sirve de nada.

La frecuencia de las copias depende de cuántos datos puedes permitirte perder. Una copia al día significa perder, en el peor caso, hasta un día de datos. Si tu aplicación registra pedidos o pagos, es más seguro volcar la base de datos cada hora y enviarla fuera del servidor.

Una copia fuera del servidor con restic

restic es una herramienta de copias de seguridad de código abierto que cifra tus copias y guarda una sola vez los datos repetidos. El ejemplo de abajo escribe la copia en otro servidor al que se accede por SFTP. El destino necesita acceso SSH sin contraseña (con clave), porque una copia automática no puede responder a una petición de contraseña. Crea el archivo de la contraseña (/root/.restic-password) en un editor de texto y ejecuta chmod 600 sobre él.

sudo apt install -y restic

export RESTIC_REPOSITORY=sftp:[email protected]:/backups/vps

export RESTIC_PASSWORD_FILE=/root/.restic-password

restic init

restic backup /etc /var/www /var/backups

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

La documentación de restic advierte de que, si pierdes la contraseña, tus datos se pierden para siempre. Guarda también la contraseña en un gestor de contraseñas. Pon las dos líneas export, los volcados de la base de datos, restic backup y restic forget en un script como /usr/local/bin/backup.sh, en ese orden, y hazlo ejecutable con chmod +x. No olvides añadir al final una línea que borre los volcados antiguos, find /var/backups -name '*.sql.gz' -mtime +2 -delete, o los archivos de volcado llenarán el disco. Después ejecuta el script cada noche, por ejemplo desde /etc/cron.d/backup con esta línea:

30 3 * * * root /usr/local/bin/backup.sh

borg es una herramienta similar. Para copias de archivos sencillas puedes usar rsync, y para enviar datos a almacenamiento de objetos puedes usar rclone.

La prueba de verdad: restaurar

Una copia que no puedes restaurar no vale nada. Pruébala justo después de configurarla y luego a intervalos regulares:

• Con restic, extrae la última copia en una carpeta vacía y comprueba los archivos: restic restore latest --target /tmp/restore-test
• Carga un volcado de la base de datos en una base de datos temporal y revisa las tablas.
• En el panel, haz clic en el icono Recuperar archivos de ella junto a una copia, explora su contenido y descarga un archivo. Una restauración completa reemplaza todo el disco actual, así que recuperar un solo archivo es la forma más segura de probar.

Elige cuánto tiempo conservar las copias según lo tarde que podrías notar un problema. La copia del panel guarda los últimos 7 días y no se puede volver más atrás. Si puedes necesitar versiones más antiguas, guarda versiones semanales y mensuales en tu propia copia. Para los detalles de la copia del panel, consulta el artículo sobre las copias diarias.

Errores comunes

• Escribir la copia en el disco del mismo servidor. Si el disco se llena o pierdes el servidor, la copia se va con él.
• Guardar la contraseña o la clave de la copia en el mismo sitio que la copia.
• No darte cuenta de que el script está fallando. Añade un aviso al script o comprueba de vez en cuando la fecha de la última copia con restic snapshots.
• No vigilar cómo se llena el destino de la copia. Un destino lleno significa copias que fallan en silencio.