Todos los sistemas de copias que alguna vez han fallado a un cliente informaban de éxito cada día hasta el día en que hizo falta. El informe dice que el archivo se escribió. No dice que se pueda leer, que contenga lo que tú crees ni que al restaurarlo salga un sitio que funcione.
Prueba la restauración, no la copia
- Coge el archivo más reciente — No uno que hayas hecho a propósito. La idea es probar el proceso que se ejecuta sin nadie delante.
- Restáuralo en otro sitio — Un subdominio, un segundo VPS, un contenedor local. Nunca encima del sitio en producción.
- Abre el sitio restaurado — Inicia sesión. Carga una página que lea la base de datos. Comprueba que hay un archivo subido hace poco.
- Anota la fecha del contenido más reciente — Ese es tu punto de recuperación real, y suele ser más antiguo de lo que sugiere el calendario de copias.
Lo que suele revelar una restauración
- La base de datos está pero los archivos subidos no: la copia cubría una cosa y no la otra.
- Se restaura pero no arranca: un archivo de configuración con las rutas o las credenciales del servidor antiguo.
- El archivo está truncado: el disco se llenó durante la copia y nadie miró el código de salida.
- Está cifrado y nadie tiene la clave: la clave estaba en el servidor que murió.
Una copia en el mismo disco que el sitio no es una copia. Protege de un error, no del disco, del servidor ni de la cuenta. Al menos una copia vive en otro sitio.
Con qué frecuencia
La pregunta honesta no es cada cuánto copiar sino cuánto trabajo estás dispuesto a rehacer. Diario significa hasta un día de pedidos perdidos. Si eso es inaceptable, diario es el calendario equivocado, cueste lo que cueste el otro.
Pon una prueba de restauración en el calendario, cada trimestre. Es la única prueba que demuestra algo, y la única que no hace nadie.