Tu copia de seguridad informa de que ha ido bien: ¿cómo sabes que es verdad?
En resumen
Un informe de copia de seguridad dice que un trabajo se ejecutó, no que los datos sirvan. Las copias se paran en silencio y el informe se queda en verde o deja de llegar. Dos comprobaciones resuelven casi todo: que el trabajo se anuncie al terminar y que vigiles la antigüedad de la última copia buena.
Casi todas las empresas tienen copias de seguridad. Menos tienen una copia que las devolvería a la vida mañana por la mañana. La diferencia rara vez está en el software de copia: está en que una copia de seguridad que deja de funcionar lo hace sin ruido, y el silencio se parece a que todo va bien.
¿Qué demuestra de verdad un informe de copia correcta?
Demuestra que un trabajo se ejecutó, y nada más. No demuestra que los ficheros estén completos, que el destino tuviera espacio, que la clave de cifrado esté disponible ni que alguien pudiera restaurar a partir de ahí.
Entre los profesionales de la informática las historias son casi intercambiables, y lo que duele son los plazos: un mes sin una copia buena porque los avisos iban al buzón de alguien que ya se había ido; un conjunto de copias que llevaba unos cuatro meses corrompido, descubierto en el momento de restaurar; cintas que estaban en blanco porque el trabajo nunca se había llegado a programar.
Ninguno de esos sistemas pedía ayuda a gritos. Todos parecían normales hasta que alguien necesitó los datos.
¿Qué dos comprobaciones detectan casi todo?
Dos: que el trabajo avise cuando ha terminado, y que un número diga qué antigüedad tiene la última copia buena.
Primera: haz que el trabajo hable. Al final de tu script de copia, haz que llame a una URL. Si la llamada no llega dentro de la ventana prevista, recibes un aviso. Este solo cambio le da la vuelta al problema: ya no dependes de que el fallo se comunique, notas el silencio. Detecta el trabajo que nunca arrancó, la máquina que estaba apagada, el servicio que se cayó, el script que murió a mitad.
Segunda: vigila un número. Haz que un comando pequeño imprima algo que te importe —horas desde la última copia correcta, o el tamaño del fichero más reciente— y trata ese número como un valor monitorizado con un umbral. Un trabajo puede completarse y no escribir nada; un número lo detecta, un informe en verde no.
Las dos funcionan en cualquier sistema capaz de ejecutar un comando o hacer una llamada HTTP, lo que incluye casi todos los productos de copia de seguridad, scripts o programadores que ya usas.
¿Por qué el NAS no te salva aquí?
Porque no puede avisarte: un dispositivo de almacenamiento en red solo contesta cuando algo externo le pregunta. La propia guía MIB de Synology afirma que DSM no admite traps SNMP: el dispositivo no puede enviar un aviso por su cuenta. Se le puede preguntar —salud de los discos, estado del RAID, incluidos degradado y caído, espacio libre—, pero solo desde algo externo que lo consulte.
Y el resultado de los propios trabajos de copia no se expone en absoluto. Así que “ya me lo dirá el NAS” tiene dos problemas: solo te lo dice si se lo preguntan, y del trabajo no te dice nunca nada.
Qué hacer esta semana
- Añade la línea del anuncio al final del trabajo de copia y define la ventana prevista.
- Imprime un número —horas desde la última copia buena— y vigílalo.
- Vigila el destino: espacio libre y salud de los discos, para enterarte de que un volumen está lleno antes de que falle el trabajo.
- Reserva una prueba de restauración. Ponla en el calendario con un nombre, no con un “alguien debería”.
Una copia de seguridad que nunca has restaurado es una esperanza. Una copia que te dice cada mañana que sigue ahí, y qué antigüedad tiene, es un sistema.
Lo que no podemos decirte
- No podemos leer el resultado de un trabajo de copia de seguridad dentro de un NAS: el software habitual de los NAS domésticos y de empresa no lo expone por red, y no vamos a fingir lo contrario.
- No podemos decirte que una copia de seguridad se puede restaurar: eso solo lo demuestra una prueba de restauración.
- Solo podemos ver lo que tu sistema nos cuenta: un trabajo que se anuncia, un número que imprime tu script o un dispositivo que responde.
Las preguntas que se hacen de verdad
¿Por qué fallan las copias de seguridad en silencio en lugar de dar un error?
Porque la parte que daría el error suele ser justo la que se ha parado. Un trabajo programado que nunca arranca no envía nada. Un servicio que se ha caído no envía nada. Un buzón que rechaza el aviso se lo traga. El silencio se parece exactamente al éxito, y por eso hay tantos fallos que duran meses.
¿Cuál es la comprobación más sencilla que funciona de verdad?
Haz que el trabajo de copia se anuncie al terminar, y que salte un aviso cuando ese anuncio no llegue a tiempo. Le da la vuelta a la lógica: en vez de esperar una mala noticia que quizá nunca se envíe, notas el silencio. Es una línea al final del script que ya tienes.
¿Qué más debería vigilar aparte del propio trabajo?
La antigüedad de la última copia buena, como número: horas desde la última ejecución correcta, o el tamaño del fichero de copia más reciente. Un trabajo puede terminar y producir un fichero vacío. Un número que miras cada día lo detecta; un informe en verde, no.
¿Cada cuánto hay que probar una restauración?
Al menos dos veces al año, en una máquina que no sea la de producción, con un cronómetro en la mano. Aprendes dos cosas que ningún informe te dirá: si los datos vuelven, y cuánto tiempo estaría parado el negocio. Apunta las dos.