Casi todas las empresas con las que hablamos tienen copias. Muy pocas saben decir cuándo fue la última vez que alguien recuperó algo de ellas, y menos todavía cuánto tardó.
No es un detalle. Una copia que nunca se ha restaurado es una suposición, y el día que hace falta es el peor día posible para descubrir que la suposición era falsa.
¿No basta con que la copia se haga todas las noches?
No. Que el programa diga «copia completada» significa que ha copiado algo, no que ese algo sirva para volver a trabajar.
El aviso verde mide lo que el programa sabe medir: que los ficheros que le dijeron que copiara se han copiado. No sabe si alguien añadió una carpeta nueva fuera de la lista hace un año, si la base de datos estaba abierta mientras se copiaba o si la copia depende de una contraseña que solo conocía quien la configuró.
¿Qué significa de verdad probar una restauración?
Recuperar los datos en otro sitio, como si el original se hubiera perdido, y comprobar que con eso se puede trabajar. Abrir un documento suelto de la copia no es una prueba; ver que el fichero de copia existe, tampoco.
Una prueba que sirve tiene tres partes:
- Restaurar en otro equipo, no encima del original. Si sale mal, no se ha roto nada, y además se comprueba que la copia no depende del servidor que se quiere proteger.
- Usarlo. Arrancar el programa de gestión contra los datos recuperados, abrir las facturas de la última semana, buscar un pedido concreto. Si la gente no podría trabajar con eso, la prueba ha fallado aunque todos los ficheros estén.
- Cronometrarlo. Apuntar cuánto se tarda desde que se decide restaurar hasta que alguien puede volver a trabajar. Ese número es el que importa el día malo.
¿Qué se suele descubrir al hacerlo?
Casi siempre algo, y casi nunca lo que uno espera. Estas son las sorpresas que más se repiten:
- Falta media base de datos. Se copiaba la carpeta del programa, pero los datos vivían en otro disco, o estaban abiertos durante la copia y salieron a medias.
- Nadie sabe la contraseña. La copia está cifrada, que está bien, y la clave la puso alguien que ya no está o que la tenía apuntada en el equipo que se acaba de perder.
- Tarda tres días. Todo funciona, pero bajar los datos, reinstalar y volver a dejarlo como estaba lleva mucho más de lo que la empresa puede estar parada.
- El correo no estaba. Se daba por hecho que el proveedor lo guardaba, y lo que guarda no es lo que se había borrado.
Ninguna de estas cosas se arregla el día del desastre. Todas se arreglan en una tarde cuando se descubren en una prueba.
¿Cada cuánto hay que probarla?
Una prueba completa al menos una vez al año, y pruebas pequeñas —un fichero, una carpeta, un buzón— cada pocos meses. Y siempre después de un cambio grande: un servidor nuevo, un programa nuevo o una mudanza a la nube.
Lo que no conviene es atar la prueba a «cuando haya tiempo», porque no lo hay nunca. Que tenga fecha en el calendario y alguien con nombre que la haga.
¿Y si el ransomware también cifra la copia?
Entonces no tienes copia. Un ataque que cifra los equipos de la oficina busca también todo lo que esos equipos pueden ver, y una copia en un disco que está siempre enchufado al servidor, o en una carpeta compartida de la red, entra en el lote.
Por eso al menos una de las copias tiene que quedar fuera de su alcance: desconectada de la red, o guardada de forma que nadie desde la oficina —ni el propio atacante con las credenciales de alguien— pueda borrarla ni modificarla durante un tiempo. Es la copia que se prueba con más cuidado, porque es la única que va a quedar.
¿Qué hay que tener escrito?
Una hoja con cuatro cosas: dónde están las copias, cómo se restaura paso a paso, quién tiene las contraseñas y cuánto tardó la última prueba.
Parece burocracia y es lo contrario. El día que hace falta restaurar, la persona que lo montó puede estar de vacaciones, y lo que no está escrito depende de que alguien se acuerde con prisa y con nervios.
Si quieres saber si tus copias aguantarían una prueba de verdad, empezamos por ahí en Copias de seguridad y continuidad.