Tu copia de seguridad no vale nada hasta que la restauras: cómo comprobarlo

Copias y continuidad29 de August de 2026

La única forma de saber si una copia funciona es restaurarla. Todo lo demás —que el programa diga que terminó bien, que el disco parpadee, que la carpeta ocupe muchos gigas— son indicios, y los indicios fallan justo el día que necesitas certezas. La prueba lleva quince minutos al trimestre.

4 min de lectura7 secciones

Por qué fallan las copias que parecen correctas

Las causas se repiten con una regularidad que ya no sorprende.

• Copia una ruta que ya no se usa. Se configuró hace tres años apuntando a una carpeta, el trabajo se movió a otra y nadie actualizó la tarea. La copia se hace todas las noches, correctamente, de una carpeta casi vacía.
• El programa da error y nadie lo lee. El aviso se manda a una dirección de correo de alguien que ya no está.
• El destino se llenó. El disco se quedó sin espacio en marzo y desde entonces no se ha escrito nada nuevo.
• Faltan las bases de datos. Copia los archivos pero no la base de datos del programa de gestión, que suele estar bloqueada mientras el programa está abierto y requiere un método distinto.
• La copia está donde el problema. En el mismo equipo, o en una unidad de red que un ransomware cifra igual que todo lo demás.
• Nadie sabe restaurar. La copia existe y es correcta, pero la única persona que sabía usar el programa ya no trabaja allí.

Fíjate en que ninguna de estas se detecta mirando el panel del programa. Todas se detectan intentando recuperar algo.

La prueba trimestral, paso a paso

No hace falta simular un desastre completo. Con una prueba parcial bien elegida se detectan casi todos los fallos.

1. Elige un archivo real de hace un mes. No el de ayer: uno con cierta antigüedad, para comprobar también el historial. Que sea un archivo de trabajo, no una foto suelta.
2. Pide a alguien que no sea el técnico habitual que intente recuperarlo. Si solo sabe hacerlo una persona, la copia depende de que esa persona esté disponible el día del desastre.
3. Cronometra. Desde que se empieza hasta que el archivo está abierto y es correcto.
4. Ábrelo y compruébalo. Que no esté corrupto ni truncado. Un archivo que se restaura pero no abre no cuenta.
5. Prueba también la base de datos del programa de gestión, al menos una vez al año, con ayuda de quien lo mantenga. Es la parte que más veces falta y la que más duele perder.
6. Anótalo. Fecha, qué se restauró, cuánto se tardó y quién lo hizo.

Ese registro es más importante de lo que parece

Una hoja con cuatro columnas y una línea por trimestre sirve para tres cosas. Demuestra ante un cliente o una auditoría que la medida existe y se comprueba. Permite ver si el tiempo de recuperación empeora con los años, que es lo que suele pasar cuando crecen los datos. Y evita la discusión de «yo creía que lo comprobaba Fulano».

Qué mirar además del archivo

Aprovecha la prueba para responder a estas preguntas, que son las que de verdad describen tu capacidad de recuperación:

• Si hoy se estropea el equipo principal, ¿cuánto tardaríamos en volver a trabajar?
• ¿Cuánto trabajo perderíamos? Es decir, ¿de cuándo es la última copia buena?
• ¿Podríamos recuperar si el edificio no fuera accesible?
• ¿Están las licencias y contraseñas necesarias para reinstalar en un sitio que no dependa de lo que se ha roto?

Las dos primeras preguntas son, en la práctica, lo que en el sector se llama tiempo objetivo de recuperación y punto objetivo de recuperación. Se pueden responder sin usar las siglas.

La prueba anual completa

Una vez al año conviene ir más allá: restaurar un conjunto grande, o levantar el sistema de gestión completo en un equipo distinto. Es más trabajo, pero es la única forma de detectar dependencias que nadie recordaba, como un programa que necesita una licencia atada al equipo original o una configuración que solo existía en la máquina que se rompió.

Ese ensayo se hace con la empresa parada lo mínimo posible, normalmente en horario de baja actividad y sobre una copia, nunca sobre el sistema en producción.

Cuando el resultado es malo

Si la prueba falla, la buena noticia es que ha fallado un martes por la mañana y no el día del incidente. No es un motivo para buscar responsables: es exactamente para lo que sirve la prueba.

Lo que toca entonces es arreglar la causa concreta —la ruta, el espacio, el aviso que nadie lee, la base de datos que no entraba— y volver a probar hasta que salga bien dos veces seguidas.

Cómo lo hacemos nosotros

En los planes de acompañamiento la restauración de prueba es una tarea con fecha, no una recomendación: se ejecuta, se cronometra y se te entrega el registro. Y en la auditoría de seguridad la primera prueba se hace delante de ti, porque es la forma más rápida de saber si el punto de partida es el que creías.

Si no recuerdas cuándo se restauró algo por última vez en tu empresa, esa es la respuesta. Escríbenos y lo comprobamos.