Una recuperación ante desastres que sobrevive a una caída real
Un plan de recuperación ante desastres solo vale algo cuando se ha restaurado, ensayado y mantenido al día. Esta página dice qué debe contener, cómo se fija un objetivo de tiempo de recuperación y cómo se relaciona con la continuidad de negocio.
Las cuatro magnitudes en las que se apoya un plan
Quien pueda rellenarlas por sistema tiene un plan. Quien no pueda, tiene una copia de seguridad.
Qué contiene un plan de recuperación ante desastres
Describe cómo vuelve la TI tras una caída: qué sistemas primero, desde qué copia, quién lo hace y cómo se sabe que ha terminado.
- Una lista de sistemas, en ordenNo todo tiene que volver a la vez. El plan ordena los sistemas según los necesita el trabajo, y ese orden sale del negocio y no del armario de servidores. Lo que no está en la lista vuelve más tarde, y todo el mundo lo sabe de antemano.
- Un RTO y un RPO por sistemaCuánto puede estar caído y cuánto trabajo puede perderse. Esos dos deciden qué tiene que poder hacer la técnica; al revés no funciona. Una hora de RPO exige algo distinto que una noche.
- Dónde está la copia y cómo se llega a ellaUna copia a la que solo se llega a través del sistema caído no es una copia. El plan nombra el lugar, la vía y quién tiene las llaves, también cuando la red está fuera y nadie puede iniciar sesión.
- Quién hace qué, con un teléfono al ladoFunciones, no solo nombres, porque la gente se va de vacaciones. Quién decide conmutar, quién llama al proveedor, quién informa a la organización. En papel, porque en este escenario la intranet también está caída.
Cómo construimos ese plan
Cinco pasos, en este orden. Los dos primeros son sobre el negocio y los tres últimos sobre la técnica; al revés se construye algo que nadie necesitaba.
Averiguar qué se para
Qué procesos se detienen cuando un sistema cae, y a partir de cuándo empieza a doler. Esa conversación la tenemos con quien hace el trabajo y no solo con TI, porque el departamento que más se queja no siempre es el que debe volver primero.
Fijar un RTO y un RPO por sistema
Ponemos las cifras al lado de lo que cuestan en técnica y en esfuerzo. Casi siempre se mueve algo: una hora de RTO suena bien hasta que se ve lo que exige, y entonces cuatro horas resultan suficientes para la mitad de los sistemas.
Montar la técnica sobre esas cifras
Copias inmutables, replicación o conmutación: lo que encaja sale de las cifras de arriba. Lo montamos y nos aseguramos de que un sistema infectado no pueda arrastrar la copia; ese es el escenario en el que se rompen la mayoría de los planes.
Restaurar, de verdad
Una recuperación hecha en un entorno aparte, con el tiempo medido. Solo entonces se sabe si el RTO se sostiene. Casi cada primer intento da una sorpresa: un certificado, una licencia, una integración que nadie había anotado.
Ensayar y mantener
Una vez al año accionar el interruptor de verdad, y actualizar el plan en cuanto entra o sale un sistema. Un plan de hace dos años describe un entorno que ya no existe, y eso se descubre en el peor momento.
Recuperación ante desastres y continuidad de negocio
Se usan como sinónimos y no lo son. La continuidad de negocio trata de seguir trabajando; la recuperación ante desastres, de la TI que para eso debe volver.
- La continuidad de negocio es más ampliaUn plan de continuidad describe cómo sigue funcionando la organización cuando algo falla: personas, edificios, proveedores, comunicación. La caída de TI es un escenario dentro de él. Sin ese plan, un plan de recuperación es un documento técnico sin destinatario.
- La recuperación ante desastres es la parte de TIEs el capítulo que dice cómo vuelven los sistemas y a qué velocidad. Recibe el encargo del plan de continuidad: allí figura cuánto puede estar parado un proceso, y de ahí sale el RTO.
- La alternativa sin TIPara las horas en que no funciona nada: dónde están los pedidos en papel, cómo siguen localizables los clientes, quién dice qué. Eso pertenece al plan de continuidad y no a nosotros, pero preguntamos por ello: un RTO de ocho horas solo es aceptable si hay ocho horas que salvar.
- Notificar forma parte del asuntoSi la organización está sujeta a NIS2, junto a la recuperación corre un reloj de notificación. Mezclar las dos cosas cuesta tiempo en el peor momento; el plan las pone una al lado de la otra, con quién hace cada una.
Qué hacemos nosotros y qué se queda con usted
La continuidad no es un producto que se compra. Este es el reparto que sostenemos, y la parte que debe quedarse en la organización.
- Lo que hacemosEscribir y mantener el plan, montar la copia y la conmutación, ejecutar y medir la restauración, y participar en el ensayo. El servicio lo prestan nuestros propios técnicos y no un subcontratista.
- Lo que dejamos por escritoQué copia está dónde, cuándo se restauró por última vez y cuánto tardó. Es el material que pide un auditor, una aseguradora o un regulador, y justamente la parte que ya no existe si hay que reconstruirla después.
- Lo que se queda con ustedLa decisión de conmutar, y el juicio sobre cuánto puede estar parado cada proceso. Es una elección sobre el negocio y no sobre la técnica; nosotros calculamos lo que cuesta y lo que aporta.
- Lo que nadie puede prometerQue no pase nada. Lo que sí es posible es que la caída transcurra de forma previsible: orden conocido, duración conocida, responsabilidades conocidas. Esa es la diferencia entre un incidente y una crisis.
¿Funciona de verdad su restauración? La única manera de saberlo es ejecutarla. Llame al +31 85 060 9347 o escriba a info@itproposal.com y repasamos lo que hay. Le atiende alguien que habla su idioma.
Seguir leyendo
Las páginas de este bloque y con qué enlazan.
Preguntas que nos hacen sobre esto
Las más habituales, respondidas en breve.
¿Qué diferencia hay entre un plan de recuperación ante desastres y una copia de seguridad?
Una copia de seguridad es una copia de sus datos. Un plan de recuperación describe cómo vuelven sistemas completos a partir de ella, en qué orden, en cuánto tiempo y quién lo hace. Una copia sin plan deja una copia cuyo tiempo de restauración nadie conoce.
¿Con qué frecuencia hay que ensayar un plan de recuperación?
Al menos una vez al año accionando el interruptor de verdad, y además actualizarlo con cada cambio que añade o quita un sistema. Un plan de hace dos años describe un entorno que ya no existe, y eso se descubre en el peor momento.
¿Pueden hacer un plan para un entorno que gestiona otra empresa?
Sí. Escribimos el plan, medimos la restauración y participamos en el ensayo, también cuando la gestión diaria está en otras manos. Lo que sí pedimos es acceso a los hechos: qué copias existen, dónde están y cuándo se restauró la última.
¿Quiere saber si su plan aguanta?
Cuéntenos qué tiene en marcha y qué está resuelto ahora. Repasamos los sistemas, les ponemos RTO y RPO al lado y decimos cuáles no se van a cumplir, antes de que lo diga una caída.
Conocimiento práctico de TI en tu bandeja
Nuevas guías sobre gestión, seguridad y el puesto de trabajo, escritas por quienes hacen el trabajo. Sin discursos comerciales, y puedes darte de baja con un clic.