Autoalojar un sitio en un VPS cuesta unos pocos euros al mes y devuelve el control de toda la pila. A cambio, la copia de seguridad pasa a ser una responsabilidad completa: ningún alojamiento compartido vigila en segundo plano. Un servidor sin una copia probada no está «en riesgo», está averiado en diferido. Esta guía describe un método completo y reproducible para un sitio WordPress o PHP: base de datos, archivos, copia externa cifrada, rotación y, sobre todo, restauración verificada.
Por qué la copia «cuando me acuerdo» siempre falla
Una copia manual depende de una decisión humana repetida, justo el tipo de tarea que una agenda cargada salta primero. Falla de tres formas previsibles: no se ejecuta con suficiente frecuencia, vive en el mismo disco que el sitio —y desaparece con él— y nunca se restaura para comprobar que funciona. Una copia que nunca se prueba es solo una hipótesis. Un buen método saca a la persona del bucle diario y solo la reclama para una prueba de restauración mensual.
La regla 3-2-1, versión servidor pequeño
La regla 3-2-1 sigue siendo la referencia más sólida: tres copias de los datos, en dos soportes distintos, uno de ellos fuera del sitio. En un VPS modesto funciona sin hardware caro.
| Copia | Ubicación | Función |
|---|---|---|
| Datos de producción | Disco del VPS | La fuente en servicio |
| Copia local | Segundo volumen o carpeta dedicada | Restauración rápida |
| Copia externa | Almacenamiento de objetos cifrado (S3, B2) | Sobrevive a perder el VPS |
Dos puntos importan más que el resto: la copia externa debe cifrarse antes de salir del servidor, y la copia local nunca sustituye a la externa. Un incidente que destruye el VPS se lleva ambos volúmenes si están en la misma máquina.
Copiar la base de datos correctamente
En un sitio dinámico la base de datos contiene lo esencial: contenidos, cuentas, pedidos. Un volcado coherente se hace sin bloquear las tablas, con una única transacción en un motor transaccional como InnoDB.
#!/usr/bin/env bash
# Sauvegarde de la base : dump compresse, date dans le nom
set -euo pipefail
STAMP=$(date +%F_%H%M)
DEST=/var/backups/db
mkdir -p "$DEST"
mariadb-dump --single-transaction --quick --lock-tables=false \
--defaults-extra-file=/root/.my.cnf ma_base \
| gzip -9 > "$DEST/ma_base_$STAMP.sql.gz"
El archivo de credenciales ~/.my.cnf evita escribir la contraseña en el comando y, por tanto, en el historial del shell y en la tabla de procesos. Debe ser legible solo por la cuenta que hace la copia, con permisos 600.
Copiar los archivos del sitio
No todos los archivos valen lo mismo: el código y los medios subidos deben guardarse, mientras que las cachés y los registros no aportan nada y engordan el archivo sin motivo. Un rsync incremental hacia un volumen local es rápido y legible.
# Fichiers du site : incrementiel via rsync vers un disque local
rsync -aH --delete \
--exclude 'wp-content/cache' \
--exclude '*.log' \
/var/www/monsite/ /var/backups/files/monsite/
La opción --delete mantiene el espejo local estrictamente alineado con la fuente; úsala con conocimiento, porque un borrado en el sitio se propaga a la copia local. Por eso precisamente la copia local no basta: la retención se juega en el nivel externo.
Externalizar y cifrar con restic
La copia externa es la que salva de un incendio en la sala de máquinas o de una cuenta comprometida. restic cifra en el cliente, deduplica y habla de forma nativa con el almacenamiento de objetos: el archivo sale ilegible para el proveedor del repositorio.
# Externaliser + chiffrer avec restic (depot sur stockage objet S3)
export RESTIC_REPOSITORY="s3:https://s3.example.com/backups-monsite"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=...
restic backup /var/backups/db /var/backups/files --tag nightly
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
El comando forget --prune aplica la política de retención y libera realmente el espacio de las instantáneas descartadas. La contraseña del repositorio vive en un archivo fuera del repositorio: perderla deja las copias ilegibles para siempre.
Dónde guardar la copia externa
La elección del repositorio externo pesa sobre el coste y sobre la velocidad de restauración. Tres familias destacan para un sitio autoalojado. El almacenamiento de objetos compatible con S3 —Backblaze B2, Scaleway, OVH, Wasabi— factura por gigabyte almacenado y es el más flexible; los precios de salida varían mucho entre proveedores y conviene leerlos antes de comprometerse. Un servicio centrado en copias como rsync.net ofrece acceso SSH y encaja bien con restic o con un simple rsync. Por último, un segundo servidor que ya se controla puede hacer de repositorio, siempre que esté físicamente separado del primero. La regla decisiva sigue siendo la misma: el proveedor nunca debe poder leer el contenido, algo que el cifrado en el cliente de restic garantiza sea cual sea el repositorio.
Automatizar con cron y fijar la retención
Reunidos en un único script, estos pasos se programan en una línea. Una noche de poco tráfico limita el impacto del volcado sobre la base en producción.
# /etc/cron.d/backup-monsite -> 3h15 chaque nuit, journalise la sortie
15 3 * * * root /usr/local/sbin/backup-monsite.sh >> /var/log/backup.log 2>&1
La retención equilibra coste de almacenamiento y profundidad de histórico. La tabla siguiente encaja con un sitio de contenidos habitual.
| Frecuencia conservada | Duración |
|---|---|
| Diaria | 7 días |
| Semanal | 4 semanas |
| Mensual | 6 meses |
Esta política guarda unas treinta instantáneas, suficientes para recuperarse de una corrupción descubierta tarde sin disparar la factura del almacenamiento de objetos.
Probar la restauración: el paso que todos saltan
Es la única comprobación que demuestra que la cadena funciona. Una vez al mes, una restauración en una carpeta desechable basta para validar la integridad del archivo y mantener el gesto entrenado, para que no se descubra un día de caída real.
# Tester la restauration dans un dossier jetable, une fois par mois
restic snapshots
restic restore latest --target /tmp/restore-test
gunzip Una copia que nunca se restaura no es una copia, es una hipótesis.
Referencia. Dos indicadores enmarcan todo plan de recuperación: el RPO, cuántos datos se acepta perder (aquí, hasta 24 h con un ritmo diario), y el RTO, el tiempo objetivo de vuelta al servicio. Dividirlos por dos cuesta más —copias más frecuentes, restauraciones repetidas— y ese equilibrio se decide antes del incidente, no durante.
Lo que hay que recordar
Una copia fiable se resume en cuatro exigencias: automatizada para no depender de nadie, separada del servidor para sobrevivir a su pérdida, cifrada antes de salir y restaurada con regularidad para demostrar que sirve. La regla 3-2-1, un script en cron y una prueba mensual cubren la mayoría de los casos de un sitio autoalojado.
El único susto real de copia que he vivido no vino de un disco muerto sino de un volcado corrupto que nadie había vuelto a abrir: el archivo existía, estaba vacío. Desde entonces considero que una copia sin probar no existe, y en las instalaciones de clientes pongo el recordatorio de restauración mensual antes que la propia automatización. Para un sitio de contenidos, restic hacia almacenamiento de objetos por unos pocos euros al mes es la mejor tranquilidad por euro que conozco. — Simon Janvier
Para profundizar
Documentación oficial de restic, repositorios y políticas de retención: restic.readthedocs.io.
