El backup de Schrödinger
Hay una verdad incómoda en la protección de datos: no sabes si tu respaldo funciona hasta que intentas restaurarlo. Mientras no lo abras, vive en una superposición —sirve y no sirve a la vez—, y la mayoría de las empresas descubre en cuál de los dos estados estaba justo el peor día. Una copia de la que nunca recuperaste no es un control de seguridad; es una hipótesis sobre el futuro. Y las hipótesis no devuelven la facturación cuando un servidor cae.
¿Por qué fallan los backups justo cuando los necesitas?
Porque las formas en que un respaldo se rompe no hacen ruido. Las más frecuentes:
- Alcance incompleto: el job copia menos de lo que crees —una carpeta nueva, una base de datos, un recurso compartido quedaron fuera.
- Inconsistencia con la aplicación: los archivos «casi» restauran, pero la base de datos o el sistema no arranca porque la copia no era consistente.
- Corrupción silenciosa: el medio o el propio archivo de respaldo se degradó sin que nadie lo notara.
- Retención vencida: cuando descubres el problema, la versión buena ya expiró.
- Backups comprometidos: viven en la misma red y con las mismas credenciales que producción, así que el ransomware los alcanza primero.
El hilo común es que ninguna de estas fallas aparece en el informe nocturno. El trabajo termina «correcto» y nadie se entera hasta el momento de la verdad.
RTO y RPO: ¿cuánto tardas en volver y cuánto pierdes?
Dos números ordenan toda la conversación. El RTO —objetivo de tiempo de recuperación— responde cuánto puede estar caído un sistema antes de que el impacto sea inaceptable. El RPO —objetivo de punto de recuperación— responde cuánto dato puedes permitirte perder; si respaldas cada noche, tu RPO es de un día. Lo importante es que sean números acordados con el negocio y verificados en pruebas reales, no estimaciones optimistas. Conviene saberlo: según datos de 2025, más de uno de cada tres sistemas críticos no logra cumplir su RTO cuando llega el momento, y la recuperación media de un ataque de ransomware se mide en semanas. La distancia entre el RTO que crees tener y el que de verdad logras solo se descubre probando.
Probar es restaurar, no mirar el log
Aquí está el cambio de mentalidad clave: que el trabajo de respaldo termine «en verde» solo dice que algo se escribió, no que ese algo sirva. Probar de verdad es restaurar en un entorno aislado —para no reintroducir malware ni pisar producción—, verificar que los datos están completos e íntegros (con checksums) y comprobar que la aplicación efectivamente arranca y opera. Cada prueba debería medir el tiempo real contra el RTO y tener un resultado claro de aprobado o fallado; y un test que falla se trata como un incidente prioritario, que se corrige antes del siguiente ciclo. Restaurar es la única auditoría que cuenta.
¿Cada cuánto probar?
No hace falta convertir la oficina en un laboratorio, pero sí tener una rutina. Una cadencia sensata combina tres niveles: restauraciones de archivos sueltos cada mes, pruebas de recuperación de aplicaciones completas cada trimestre y una recuperación de todo el entorno al menos una vez al año. Cada prueba deja dos cosas: un número real de cuánto tardaste y una lista de lo que hay que arreglar. Con el tiempo, esos números mejoran y los procedimientos dejan de vivir en la cabeza de una sola persona, que es otro punto único de fallo.
El número que le falta a tu regla: el cero
La regla clásica de respaldo es 3‑2‑1: tres copias, dos medios, una fuera de sitio. Los entornos modernos le suman dos dígitos para resistir el ransomware: el «1» de una copia inmutable o aislada, y el «0» de cero errores de verificación. Ese cero es justamente lo que pide este artículo, y ya no es solo una buena práctica: el marco de ciberseguridad NIST lo eleva a requisito formal de que los backups se prueben. Es la misma lección que recorre toda la protección de datos: igual que un RAID no es un respaldo y la nube tampoco lo es, un respaldo sin probar es solo una promesa. El cero es lo que la convierte en una certeza.
La conclusión
La pregunta que vale la pena hacerse no es «¿tengo backups?», sino «¿cuándo fue la última vez que restauré desde ellos y cuánto tardé?». Si la respuesta es «nunca» o «no me acuerdo», ahí está el hueco, y es de los más baratos de cerrar: no cuesta comprar nada nuevo, cuesta probar lo que ya tienes. Te ayudamos a diseñar un respaldo empresarial y a verificar que tus copias de servidores y máquinas virtuales de verdad restauran, para que el día del incidente sea recuperable y no terminal. Y si ya pasó lo peor, también está la recuperación de ransomware.
Preguntas frecuentes
Por alcance incompleto, copias inconsistentes con la aplicación (la base de datos «casi» restaura pero no arranca), corrupción silenciosa, retención vencida o un servidor de backup comprometido con las mismas credenciales que producción. El trabajo puede dar «correcto» durante años mientras la restauración real fallaría.
El RTO (objetivo de tiempo de recuperación) es cuánto puedes tardar en volver a operar; el RPO (objetivo de punto de recuperación) es cuánto dato puedes permitirte perder. Deben ser números acordados con el negocio y documentados, no estimaciones, porque son la vara con la que mides si tu recuperación es lo bastante rápida.
Una cadencia razonable es: restauraciones de archivos cada mes, pruebas de recuperación de aplicaciones cada trimestre y una recuperación completa al menos una vez al año. En cada prueba se mide el tiempo real frente al RTO y se trata cualquier fallo como un incidente a corregir antes de la siguiente.
No. Que el log esté «en verde» solo dice que la copia se escribió, no que sirva. Probar de verdad es restaurar en un entorno aislado y verificar que los datos están completos e íntegros (con checksums) y que la aplicación arranca. Es el «0» del 3‑2‑1‑1‑0: cero recuperaciones sin probar.
Sí, y es lo habitual: la mayoría de los ataques de 2025 apuntan primero a los respaldos para eliminar la vía de recuperación. Por eso conviene una copia inmutable o aislada que el ataque no pueda tocar, y validar siempre antes de restaurar para no reintroducir la infección.