La pregunta que de verdad importa sobre tus copias de seguridad no es «¿se hacen?». Es «¿cuándo fue la última vez que restaurasteis una de verdad?». En las auditorías, la primera se responde con un sí tranquilo y la segunda con un silencio incómodo. Ese silencio es el agujero: un backup que se ejecuta cada noche sin dar error parece un backup que funciona, y no siempre lo es. Solo lo sabes cuando lo restauras.
Este artículo va de la parte que casi nadie hace: probar la restauración de copias de seguridad. Montar el ensayo, cronometrarlo y encontrar lo que falla en frío, no el día del incendio. Porque la copia que nunca se ha restaurado no es una copia: es una promesa sin comprobar.
La copia que nunca se ha restaurado no es una copia
Un trabajo de backup que termina en verde te dice una sola cosa: que se leyeron unos datos y se escribieron en otro sitio. No dice que estén completos, que el fichero no esté corrupto, que la base de datos sea consistente ni que puedas arrancar el sistema con ellos. El «verde» mide la escritura, no tu capacidad de recuperar. Confundirlos es la falsa sensación de seguridad más cara que existe en IT.
El día que necesitas restaurar nunca es un martes tranquilo. Es a las tres de la madrugada, con el ransomware ya dentro o el servidor sin arrancar y dirección preguntando cuándo se vuelve a facturar. El peor momento para descubrir que la copia de la base de datos estaba a medias, que faltaba una carpeta o que restaurar 2 TB por tu línea tarda tres días. La prueba de restauración existe para que esos descubrimientos ocurran hoy, en frío y sin coste, y no entonces.
Nadie tiene un problema de copias de seguridad. Todo el mundo tiene un problema de restauraciones. Solo que la mayoría no lo sabe todavía.
Qué es una prueba de restauración y cada cuánto hacerla
Una prueba de restauración es recuperar de mentira para saber que el día real puedes de verdad: coges una copia, la levantas en un entorno controlado y verificas que los datos están, son consistentes y el sistema funciona. No es mirar el informe ni comprobar que el fichero pesa lo esperado; es tocar los datos recuperados y confirmar que sirven. Y no todas son iguales: cada nivel prueba una cosa distinta y tiene su frecuencia sensata.
- Restaurar un fichero o carpeta (mensual). El ensayo más barato y el más frecuente en la vida real: alguien borró algo. Recupera un archivo de hace una semana y de hace un mes y comprueba que abre. Valida la retención, no solo la copia de anoche.
- Restaurar un buzón o cuenta de correo (trimestral). Prueba recuperar un buzón completo o mensajes concretos, sobre todo con Microsoft 365 o Google Workspace, donde mucha gente cree —erróneamente— que el proveedor ya le hace backup.
- Restaurar un servidor o aplicación completa (trimestral o semestral). Levantar el servidor de ficheros, el ERP o la base de datos en aislado y verificar que arranca y es coherente. Aquí aparecen las dependencias olvidadas: servicios que no levantan, licencias, conexiones a otras máquinas.
- Recuperación bare-metal o del entorno entero (anual). Reconstruir desde cero, como si no quedara nada. El simulacro de desastre real: aquí se mide de verdad tu RTO y salen los tiempos que nadie había cronometrado.
La regla práctica: cuanto más crítico y difícil de reconstruir, más a menudo se prueba. Y siempre que cambie algo relevante —un servidor nuevo, una migración— toca repetir el ensayo. Un backup que funcionaba en enero puede llevar roto desde la migración de marzo sin que nadie se entere.
Cómo montar un test de restauración serio
Una prueba mal hecha da una tranquilidad todavía peor que no probar. «Abrí un PDF de la copia y se veía» no demuestra nada. Un ensayo serio se hace en un entorno aislado, sigue un guion y produce un número medido, no una sensación. Este es nuestro checklist:
- Entorno aislado, nunca producción. Se restaura en una red o máquina separada, sin tocar los sistemas vivos. Restaurar sobre producción para «ver si va» es la mejor forma de convertir un ensayo en un incidente real.
- Partir del escenario, no del fichero. Define qué desastre simulas: borrado accidental, servidor perdido, ransomware que cifró producción y las copias accesibles. Restaura como lo harías ese día real.
- Verificar el dato, no que «existe». Que la base de datos abra y sea consistente, que las cifras cuadren, que la fecha de la copia sea la esperada. Un fichero restaurado que no abre es un fichero perdido con más pasos.
- Cronometrar el RTO de verdad. Mide desde «decidimos restaurar» hasta «el servicio está usable», incluyendo lo que nadie cuenta: descargar la copia desde fuera, descifrar, reinstalar, reconfigurar. Ese reloj es tu RTO real, no el del folleto.
- Confirmar el RPO real. Comprueba cuántas horas de trabajo se pierden con la copia que has usado. Si copias una vez al día, el peor caso son 24 horas. Que ese número lo conozca y lo acepte dirección, por escrito.
- Documentar y comparar con lo acordado. Deja constancia del resultado y contrástalo con el RTO/RPO que la empresa dijo poder aguantar. Si el plan dice ocho horas y la prueba dice veintiséis, tienes un problema que arreglar hoy, con calma.
Ese último punto convierte el ejercicio en algo útil. Sin un RTO y un RPO acordados con dirección, la prueba no tiene contra qué medirse y se queda en anécdota técnica. Con ellos, cada ensayo te dice si estás dentro o fuera del margen que tu negocio soporta.
Errores típicos que solo se ven al restaurar
Hay fallos que ningún informe de backup detecta porque no ocurren al copiar, sino al recuperar. Son invisibles hasta el día que restauras; por eso el ensayo los saca antes de que hagan daño.
- Backups incompletos. La copia se hace, pero no incluye todo: falta una base de datos, una carpeta compartida o el servidor que se añadió hace ocho meses y nadie metió en el trabajo. En verde toda la vida; recuperas y falta justo lo que importaba.
- Dependencias olvidadas. Restauras la aplicación y no arranca porque le falta un servicio, una versión, un certificado o la máquina vecina con la que hablaba. Recuperar un sistema casi nunca es recuperar un solo servidor.
- Cifrado y llaves perdidas. La copia está cifrada —bien— pero la clave estaba en el mismo servidor que se perdió, o nadie sabe dónde vive. Una copia que no puedes descifrar es ruido perfectamente inútil.
- Datos inconsistentes. La copia se tomó con la base de datos en marcha y sin volcado consistente: el fichero está, pero corrupto o a medias de una transacción. Solo lo descubres al intentar montarlo.
- RTO real inasumible. Todo está y todo es correcto, pero restaurarlo por tu línea de internet tarda cuatro días y el negocio aguanta uno. Tenías la copia; no tenías el tiempo.
Ninguno se arregla comprando más discos. Se arreglan probando: solo el ensayo los hace visibles mientras aún puedes corregirlos sin prisa ni pérdidas.
Cómo lo hace MagicBoxDesk
Probar restauraciones a mano, con criterio y de forma periódica, es justo el tipo de tarea que una empresa ocupada en lo suyo nunca acaba haciendo: importante, no urgente, hasta el día que es urgentísima. Por eso en MagicBoxDesk lo llevamos nosotros. Nuestro backup gestionado incluye restauraciones probadas periódicamente: no te entregamos un software y te deseamos suerte, sino un servicio que responde por el resultado. Levantamos tus copias en entorno aislado según su criticidad, verificamos que los datos son consistentes, cronometramos el RTO real y te entregamos un informe con lo que funciona y lo que hay que ajustar antes de que sea un problema.
Todo esto encaja con nuestra monitorización 24/7, que vigila cada trabajo de copia y avisa si algo falla —te enteras por nosotros, no por un desastre—, y con el resto de servicios IT gestionados que forman tu IT externalizado. La diferencia es concreta: pasas de creer que estás protegido a tener la prueba, con fecha y tiempos medidos.
Deja de confiar en que tu copia restaure y compruébalo. Pide presupuesto sin compromiso y montamos las pruebas de restauración de tu empresa para que el día malo recuperes de verdad, no de fe.
