Hay una conversación que tuve demasiadas veces: "Bruno, el sitio desapareció/fue hackeado — ayúdame a volver desde el backup". Y llega la pregunta que define todo: "¿cuál backup?". Cuando la respuesta es "el automático del hosting", la historia suele terminar mal. Esta guía es para que nunca vivas ese momento.
Por qué el backup del hosting no basta
No es que sea inútil — es que es una copia, y no puedes depender de una sola. Los motivos:
- Vive en la misma casa. Muchas veces el backup está en la misma máquina/datacenter del sitio. Si el servidor cae — o es comprometido, como en el caso de LiteSpeed que comenté ayer — el backup puede caer también.
- No lo controlas. Frecuencia, retención y disponibilidad las decide el hosting, no tú.
- Cuenta suspendida = backup perdido. Un pago atrasado, una violación de términos o un cierre, y el backup se va con la cuenta.
Usa el backup del hosting, sí — como una de tus copias. No como la única.
La regla 3-2-1 (la base de todo)
Es el estándar que los profesionales de TI usan hace décadas, y encaja perfecto en un sitio:
- 3 copias de tus datos (la original + 2 backups).
- 2 medios/lugares diferentes (ej.: el servidor + almacenamiento en la nube).
- 1 copia fuera del sitio (off-site) — en otro proveedor, fuera del alcance de lo que tumbaría el servidor.
Qué entra en el backup (las dos mitades)
Un sitio son dos cosas, y un backup que olvida una es inútil:
- Archivos: el código, los uploads/medios, temas, plugins y archivos de configuración.
- Base de datos: el contenido de verdad — posts, páginas, usuarios, pedidos, ajustes.
Archivos sin base = un sitio vacío. Base sin archivos = contenido sin el sitio. Y ojo: versionar el código en Git no es backup — Git guarda el código, pero no los uploads de los clientes ni la base de datos.
Cómo hacerlo en la práctica
WordPress: un plugin como UpdraftPlus o All-in-One WP Migration, programado y apuntando a un destino externo (Google Drive, S3, Dropbox). Nada de guardar el backup en la propia carpeta del sitio.
Sitio a medida (PHP y similares): una tarea programada (cron) que empaqueta archivos + base y la envía fuera. El esqueleto que uso:
# backup-diario.sh — archivos + base, enviados a un storage externo
DIA=$(date +%F)
mysqldump -u USER -pCLAVE NOMBRE_BASE | gzip > /tmp/db-$DIA.sql.gz
tar -czf /tmp/site-$DIA.tar.gz /ruta/del/sitio
# envía fuera del hosting (rclone -> Google Drive/S3/Backblaze)
rclone copy /tmp/db-$DIA.sql.gz remoto:backups/
rclone copy /tmp/site-$DIA.tar.gz remoto:backups/
rm -f /tmp/db-$DIA.sql.gz /tmp/site-$DIA.tar.gzPrográmalo en cron (ej.: cada día a las 3h) y mantén varias versiones — no solo la última. Si un problema (o un ransomware) corrompe el sitio, la copia más reciente puede ya estar dañada; vas a querer volver a una de días atrás.
El paso que casi nadie da: probar la restauración
Este es el truco. Un backup que nunca se restauró es solo esperanza. Archivos corruptos, un dump incompleto, un borrado que nadie notó — solo lo descubres en el peor momento posible. Cada pocos meses, toma el backup y restáuralo en un entorno de prueba (local o un subdominio) y confirma que el sitio sube entero. Si nunca restauraste, no tienes un backup — tienes un archivo y un acto de fe.
Checklist del backup que salva
- ☐ Es automático (no depende de que te acuerdes).
- ☐ Incluye archivos + base de datos.
- ☐ Al menos una copia fuera del hosting.
- ☐ Guarda varias versiones (no solo la más reciente).
- ☐ La restauración fue probada en los últimos meses.
- ☐ Las credenciales del destino de backup están guardadas en lugar seguro.
Quiero una rutina de backup que realmente salva
¿No estás seguro de que tu backup aguantaría en el momento clave? Yo armo (y pruebo) una rutina 3-2-1 para tu sitio — hablemos.