Saltar al contenido
dumaloor.dev
~/academia
Fundamentos

Tener copia de seguridad no es lo mismo que poder restaurar

Casi todo el mundo tiene backups. Mucha menos gente ha comprobado alguna vez que sirven, y eso solo se descubre el peor día posible.

7 min de lecturabackupcontinuidadriesgoinfraestructura

«Tranquilo, tenemos copia de seguridad.» Es una de las frases que más tranquilidad transmite en una reunión de negocio, y una de las que menos garantiza en realidad. Casi todo negocio con algo de tamaño tiene, hoy, algún sistema haciendo copias de sus datos. Mucho menos habitual es que alguien haya comprobado, de verdad, que esas copias sirven para volver a poner el negocio en marcha. Esa comprobación suele hacerse por primera vez el día que hace falta, y ese es exactamente el peor momento para descubrir que no funciona.

#Hacer copias y poder volver a funcionar son dos cosas distintas

Hacer una copia de seguridad es guardar, en algún sitio, una versión de los datos de hoy. Poder volver a funcionar es conseguir que el negocio recupere esos datos y siga operando, con el sistema completo en marcha, en un tiempo razonable. Entre una cosa y la otra hay pasos que casi nunca se prueban hasta que hacen falta: si el archivo guardado se puede leer, si el proceso de traerlo de vuelta funciona, si el sistema arranca de nuevo con esos datos dentro, y si todo eso se puede hacer en horas y no en días. Una empresa puede llevar años haciendo copias impecables y aun así no ser capaz de volver a funcionar cuando de verdad las necesita.

#Las dos preguntas que definen tu protección real

Detrás de cualquier estrategia de copias de seguridad hay dos preguntas, y las dos tienen una respuesta que se puede poner en horas, sin jerga técnica de por medio.

¿Cuántas horas de datos puedes permitirte perder? Si el sistema falla a media tarde y la última copia buena es de la noche anterior, todo lo que ha pasado desde entonces —pedidos, cobros, cambios— se pierde. Esa distancia, medida en horas, es lo primero que hay que decidir: no es lo mismo poder asumir perder un día entero de trabajo que no poder permitirse perder ni una hora.

¿Cuánto tiempo puedes estar parado? Aunque la copia se recupere perfecta, montar de nuevo el sistema completo —la base de datos, la aplicación, las conexiones con otros programas— lleva un tiempo. Ese tiempo, medido también en horas, es la segunda cifra que decide si una interrupción es una molestia o un problema serio: no es lo mismo estar parado dos horas que estar parado tres días.

Ninguna de las dos preguntas exige entender de tecnología. Exigen que alguien las haya respondido antes de que haga falta, y que la respuesta sea la que el negocio puede permitirse, no la que resulta más barata de ofrecer.

Cómo hacer estas dos preguntas sin tecnicismos

En vez de preguntar por el nombre técnico de cada cosa, basta con preguntar así: «si el sistema se cae ahora mismo, ¿desde qué momento recuperamos los datos, y cuánto tardamos en volver a estar funcionando?». Cualquier proveedor serio debería poder responder con dos cifras concretas, no con una explicación vaga.

#Cómo esas dos respuestas cambian lo que hay que montar

Las dos preguntas no son un ejercicio teórico: cada respuesta obliga a un diseño distinto. Si el negocio puede asumir perder hasta un día entero de datos, basta con una copia diaria, guardada por la noche cuando el sistema está tranquilo. Si no puede permitirse perder ni una hora —porque cada hora son cobros, reservas o pedidos que no se pueden reconstruir de memoria—, hace falta que las copias se hagan varias veces al día, o de forma continua, lo cual es más caro de mantener pero es exactamente lo que esa respuesta exige.

Lo mismo pasa con el tiempo de parada. Si el negocio puede aguantar un día sin sistema mientras alguien reconstruye todo desde cero, no hace falta invertir en nada especial. Si una hora parado ya supone un problema serio —una tienda que no puede cobrar, un servicio que sus clientes esperan siempre disponible—, hace falta tener preparado de antemano un camino de vuelta rápido, probado y automático, no algo que alguien improvise sobre la marcha el día que haga falta. La cifra que el negocio necesita no la decide el proveedor: la decide el negocio, y luego el proveedor construye alrededor de ella.

#No hace falta un desastre grande para necesitarlo

Cuando se habla de copias de seguridad, es fácil imaginar solo los escenarios más dramáticos: un incendio, un ataque, un servidor destruido. La mayoría de las veces en que de verdad hacen falta son mucho más discretas. Alguien borra por error un cliente entero en vez de solo un pedido suyo. Una actualización mal aplicada deja una tabla de datos corrupta. Un cambio que parecía inofensivo sobrescribe información que no se podía perder. En ninguno de esos casos hay ningún desastre visible: el negocio sigue en pie, el edificio está intacto, y aun así hace falta volver atrás a un momento anterior a ese error. Es, con diferencia, el uso más habitual de una copia de seguridad, y el que menos se tiene en mente cuando se piensa en «para qué sirve esto».

#Los fallos que se descubren tarde

Hay un puñado de fallos que, por su propia naturaleza, no se notan hasta el día en que hacen falta las copias:

  • La copia que lleva meses fallando en silencio. El proceso automático dejó de funcionar hace tiempo —un cambio en el sistema, un permiso caducado, un disco lleno— y nadie lo revisó porque nadie mira algo que «ya funciona solo».
  • La copia guardada en el mismo sitio que se ha estropeado. Si la copia vive en el mismo servidor, el mismo edificio o la misma cuenta que el sistema original, un incendio, un robo o un fallo grave se lleva por delante las dos cosas a la vez.
  • La copia que nadie ha intentado restaurar nunca. Existe, ocupa espacio, se genera puntualmente. Pero el proceso de traerla de vuelta y ponerla a funcionar no se ha probado ni una sola vez, y un proceso sin probar tiene una probabilidad real de fallar justo cuando más falta hace.
  • La copia que se restaura, pero tarda tres días. Técnicamente funciona. En la práctica, si el negocio no puede permitirse tres días parado, ese backup no está cumpliendo su función, por mucho que exista y esté bien hecho.

#Por qué el cifrado y la ubicación importan

Una copia de seguridad guarda, casi siempre, los datos más sensibles del negocio: clientes, cobros, contratos. Si esa copia no está cifrada, cualquiera que consiga acceder a ella —por un robo, por un fallo de permisos— puede leerla directamente, sin necesitar ninguna otra llave. Y si esa copia se guarda en el mismo sitio físico o en la misma cuenta que el sistema original, deja de proteger frente a los fallos más graves, que son precisamente los que afectan a todo un lugar o a toda una cuenta a la vez: un incendio, una inundación, un ataque que borra o cifra todo lo que encuentra a su paso. Una copia útil vive en otro sitio y está protegida por su cuenta, no solo por la suerte de que nadie más llegue hasta ella.

#La prueba que casi nadie hace

La única forma de saber si una copia de seguridad sirve es restaurarla de verdad: coger esa copia, ponerla en marcha en un entorno aparte, con cronómetro en mano, y comprobar cuánto se tarda y si el resultado funciona como debería. No basta con que el archivo exista ni con que el proceso de guardar la copia no dé error. Hay que probar el camino de vuelta, que es el que casi nunca se prueba. Hacerlo una vez al año, como mínimo, convierte una promesa de tranquilidad en un dato comprobado.

#El ejercicio que pedirle a tu proveedor

Pide, una vez al año, una restauración de prueba completa: que se recupere una copia real en un entorno separado y se mida cuánto tarda, de principio a fin. La respuesta que deberías recibir tiene que incluir tres cosas, sin rodeos: desde qué momento exacto se recuperan los datos, cuánto ha tardado todo el proceso, y si algo ha fallado por el camino. Si tu proveedor no puede ofrecerte esa prueba, o no la ha hecho nunca, esa es la señal más clara de que lo que tienes hoy es una copia de seguridad sin comprobar, no una protección real.