Copias de seguridad de sitios que de verdad te salvan: 7 reglas para backups cifrados y fuera del servidor
La mayoría de las «copias de seguridad» fallan justo cuando las necesitas: mismo servidor, nunca probadas, sin cifrado. Estas son siete reglas para backups que sobreviven a un desastre real — y cómo dejar de hacerlas a mano.
Todo el mundo tiene copias de seguridad — hasta el día en que las necesita. Entonces descubre que la copia vivía en el servidor que acaba de morir, que no se ejecutaba desde hace tres semanas, o que restaura un caos inservible. Una copia que nunca has probado no es una copia; es una esperanza. Aquí van siete reglas que convierten la esperanza en algo de lo que de verdad puedes recuperarte.
1. Automatiza — o no ocurrirá
Una copia que tienes que acordarte de lanzar es una copia que deja de ejecutarse en silencio. Prográmala. A diario es un valor por defecto razonable para la mayoría de los sitios; los sitios con más tráfico quieren snapshots de base de datos más frecuentes. La única buena cadencia de copia es aquella en la que ningún humano tiene que pensar.
2. Sigue el 3-2-1
La regla clásica sigue vigente: 3 copias de tus datos, en 2 soportes distintos, con 1 fuera del sitio. Parece exagerado hasta que un solo fallo — un disco muerto, un mal despliegue, un bucket borrado — se lleva todo lo que estaba en un mismo lugar.
3. Sácala del servidor
Este es el paso que la gente se salta. Una copia que está en el mismo VPS que el sitio muere con el VPS. Envía las copias a almacenamiento de objetos — un bucket S3, Backblaze B2, o un destino SFTP en otra máquina. Estar fuera del sitio es la diferencia entre «perdimos una tarde» y «perdimos el negocio».
4. Cifra antes de que salga
Tu copia lo contiene todo: base de datos, datos de clientes, secretos, configuración. En cuanto sale de tu servidor es un objetivo apetecible. Cífrala antes de subirla (AES-256 es el estándar) y guarda también cifradas las credenciales de almacenamiento. Una copia sin cifrar en un bucket mal configurado es una brecha esperando a ocurrir.
5. Respalda la base de datos y los archivos
Una copia solo de archivos restaura un sitio que no puede conectar con sus datos; una copia solo de base de datos restaura datos sin sitio alrededor. Necesitas ambos — subidas, configuración y código y la base de datos — idealmente capturados juntos para que sean coherentes.
6. Guarda versiones, no solo «la última»
Si tu única copia es la de anoche, entonces un problema que detectas una semana tarde — una tabla corrupta, un cifrado silencioso por ransomware, una migración fallida — ya está dentro de tu copia. Mantén una ventana de retención (p. ej. diaria durante una semana, semanal durante un mes) para volver a antes del daño.
7. Prueba tus restauraciones
El paso que más se salta — y el único que demuestra que el resto funcionó. Restaura periódicamente una copia en un lugar desechable y comprueba que el sitio realmente arranca. Una restauración que nunca has ejecutado es cara o cruz en tu peor día.
La forma fácil
Hecho a mano, esto es un montón de pegamento frágil: un cron, mysqldump, un tar, un paso gpg, un aws s3 cp, un script de retención y un procedimiento de restauración que nadie ha ensayado. Es justo el tipo de cosa que se pudre en silencio.
Un panel debería hacerlo y ya. ShadowPanel ejecuta copias programadas y cifradas con AES-256 de tus archivos y bases de datos directamente a tu propio destino S3 o SFTP, mantiene un historial con retención, guarda cifradas tus credenciales de almacenamiento — y restaura cualquier snapshot con un clic. Obtienes las siete reglas por defecto, en lugar de un procedimiento que esperas que aún funcione.
Haz copias como es debido
Plan gratuito — 3 sitios, sin tarjeta de crédito — y puedes instalarlo en cualquier VPS Ubuntu en unos diez minutos:
curl -fsSL https://shadowpanel.de/install.sh | bash