Backup y recuperación comprobada: la diferencia real
El backup es lo único que te devuelve la operación tras un ransomware grave. Pero solo sirve si la copia existe, no se puede borrar y se puede restaurar. La diferencia entre tener copias y estar respaldado es enorme, y muchas empresas la descubren en el peor momento. Este artículo explica por qué probar la restauración cambia todo, qué aporta la inmutabilidad y cómo convertir el backup de una esperanza en una garantía real con un checklist aplicable.
La trampa del backup sin prueba
Muchas empresas hacen copias que nunca han restaurado. Cuando llega el incidente, descubren que estaban incompletas, corruptas o que nadie sabe cómo devolverlas a producción. El backup existía, pero la recuperación no.
Probar la restauración de forma periódica es lo que convierte un backup en una garantía real. Una copia que nunca se ha restaurado es una hipótesis, no un respaldo. La prueba revela si la copia sirve, si cubre lo crítico y si el tiempo de recuperación es asumible.
La prueba también entrena al equipo. El primer incidente no es buen momento para aprender a restaurar: la presión y la prisa hacen que los errores se multipliquen. Restaurar en calma, aunque sea una vez al trimestre, prepara para la crisis.
Inmutabilidad: que no puedan borrar tu salvavidas
Si un atacante puede borrar tu backup, no tienes backup. El ransomware moderno busca destruir las copias antes de cifrar, para forzar el pago y reducir las opciones de recuperación.
La inmutabilidad impide que la copia se modifique o elimine durante un tiempo definido. Es una de las defensas más efectivas frente a ransomware que apunta a los respaldos, porque el atacante no puede actuar sobre lo que no puede tocar.
La inmutabilidad no es magia: debe configurarse bien y combinarse con retención suficiente. Una copia inmutable de 24 horas no ayuda frente a un cifrado que se descubre al cuarto día. El periodo de retención debe cubrir el tiempo razonable de detección.
RPO y RTO: decisiones de negocio
Definir cuántos datos puedes perder (RPO) y cuánto tardarás en volver a operar (RTO) convierte la continuidad en una decisión de negocio, no de suerte. Sin estos números, es imposible elegir la tecnología correcta.
El RPO define cada cuánto debes copiar: si puedes perder un día de trabajo, copia diaria basta; si no puedes perder ni una hora, necesitas algo más continuo. El RTO define qué tan rápida debe ser la recuperación: horas o días marcan la diferencia entre sobrevivir o cerrar.
Estos números no los define TI en solitario: los define el negocio. Que finanzas, operaciones y dirección acuerden cuánto pueden perder es lo que convierte el backup en una herramienta de continuidad, no solo de TI.
Recuperación de ransomware
Un plan claro de recuperación, con copias limpias y probadas, reduce de días a horas el tiempo fuera de operación. Pero el plan debe estar escrito y ensayado, no solo imaginado. En la crisis, lo que no se ha practicado no se ejecuta.
La recuperación no es solo restaurar archivos: implica verificar que el atacante ya no está, limpiar credenciales comprometidas y reconstruir confianza en los sistemas. Restaurar sobre un entorno aún comprometido es devolverle el acceso al atacante.
Después de recuperar, conviene documentar qué pasó, cómo se respondió y qué cambiar para la próxima. El incidente es la mejor (y más cara) auditoría que una empresa puede tener; desperdiciarla es dejar la misma puerta abierta.
Errores comunes
Hacer backup en el mismo sitio que los datos. Si el sitio se compromete, la copia también. Se necesita al menos una copia fuera de alcance del entorno principal.
Confiar en copias conectadas permanentemente. Un disco de backup montado todo el tiempo es borrable por el mismo ransomware que cifró los datos. El aislamiento es la defensa.
Asumir que 'la nube ya respalda'. SaaS como Microsoft 365 tiene recuperación limitada; no es un backup completo en el sentido tradicional. Lo que no se copia fuera, se puede perder.
Checklist de backup serio
Al menos una copia inmutable o fuera de alcance del entorno principal.
RPO y RTO definidos por el negocio, no por TI en solitario.
Prueba de restauración documentada al menos una vez al trimestre.
Verificación de que la copia cubre los datos críticos, no solo los fáciles.
Plan de recuperación escrito, con responsables y pasos.