¿TENER BACKUP SIGNIFICA ESTAR PREPARADO PARA RECUPERAR?
Disponer de una solución de backup es una parte fundamental de cualquier estrategia de protección de la información.
Sin embargo, tener copias de seguridad no garantiza por sí mismo que una organización pueda recuperar sus datos, sistemas y servicios cuando realmente lo necesite.
La capacidad de recuperación depende de qué estamos protegiendo, cómo se realizan las copias, dónde se almacenan, durante cuánto tiempo se conservan y, sobre todo, de si hemos comprobado que pueden restaurarse dentro de los tiempos que necesita la organización.
TENER COPIAS ES SOLO EL PRIMER PASO
Una tarea de backup puede finalizar correctamente y, aun así, no garantizar una recuperación completa.
Puede existir una copia válida de los datos pero faltar información necesaria para reconstruir el servicio, existir dependencias no contempladas, disponer de tiempos de restauración incompatibles con las necesidades de la organización o descubrir durante una incidencia que nunca se había probado el procedimiento completo.
Por eso, evaluar una estrategia de protección no consiste únicamente en comprobar si los backups se están ejecutando.
Debemos determinar qué podremos recuperar, hasta qué punto y en cuánto tiempo.
TENER UNA COPIA NO ES LO MISMO QUE TENER CAPACIDAD DE RECUPERACIÓN
BACKUP, RECUPERACIÓN Y CONTINUIDAD NO SON LO MISMO
Conseguir que los servicios críticos puedan mantenerse o recuperarse dentro de los tiempos asumibles para la organización.
BACKUP
Proteger la información
Generar y conservar copias de los datos y sistemas necesarios.
RECUPERACIÓN
Restaurar la operación
Disponer de los medios y procedimientos necesarios para recuperar datos, sistemas y servicios.
CONTINUIDAD
Responder a una interrupción
Conseguir que los servicios críticos puedan mantenerse o recuperarse dentro de los tiempos asumibles para la organización.
BACKUP · RECUPERACIÓN · CONTINUIDAD
¿QUÉ ESTAMOS PROTEGIENDO REALMENTE?
Uno de los primeros pasos consiste en identificar qué elementos necesita realmente la organización para recuperar su actividad.
No siempre es suficiente con proteger archivos o máquinas virtuales. Un servicio puede depender de bases de datos, configuraciones, credenciales, certificados, aplicaciones, infraestructura, almacenamiento o servicios externos.
La recuperación debe analizarse desde la perspectiva del servicio completo y sus dependencias, no únicamente desde la existencia de una copia.
DATOS
• Archivos
• Bases de datos
• Información crítica
SISTEMAS
• Servidores
• Máquinas virtuales
• Aplicaciones
CONFIGURACIÓN
• Equipos
• Políticas
• Parámetros
IDENTIDAD
• Credenciales
• Directorios
• Certificados
DEPENDENCIAS
• Red
• Almacenamiento
• Cloud
• Servicios externos
PARA RECUPERAR UN SERVICIO DEBEMOS CONOCER TODO AQUELLO DE LO QUE DEPENDE
¿CUÁNTA INFORMACIÓN PODEMOS PERDER Y CUÁNTO PODEMOS ESPERAR?
No todos los servicios necesitan el mismo nivel de protección ni tienen el mismo impacto sobre la organización.
Para diseñar una estrategia de recuperación es necesario determinar cuánto dato podemos asumir perder y durante cuánto tiempo puede permanecer indisponible cada servicio.
RPO — RECOVERY POINT OBJECTIVE
¿Hasta qué momento necesitamos recuperar la información?
Ayuda a determinar cuánto dato podría perderse entre la última copia disponible y el momento de la incidencia.
RTO — RECOVERY TIME OBJECTIVE
¿Cuánto tiempo puede permanecer indisponible el servicio?
Ayuda a determinar el tiempo máximo objetivo para recuperar su funcionamiento.
Estos valores no deberían establecerse únicamente desde IT. Deben responder al impacto que la pérdida de información o la indisponibilidad tendría sobre la organización.
LA ESTRATEGIA DE BACKUP DEBE ADAPTARSE A LAS NECESIDADES DEL NEGOCIO, NO AL REVÉS.
UNA COPIA CORRECTA NO GARANTIZA UNA RESTAURACIÓN CORRECTA
Los sistemas de backup proporcionan información sobre la ejecución de las tareas, pero una operación finalizada correctamente no sustituye una prueba real de restauración.
Las pruebas permiten comprobar que los datos son recuperables, que conocemos el procedimiento, que disponemos de los recursos necesarios y que los tiempos reales son compatibles con los objetivos definidos.
Además, permiten detectar problemas antes de que la recuperación tenga que realizarse bajo la presión de una incidencia real.
INTEGRIDAD
¿Los datos pueden restaurarse correctamente?
PROCEDIMIENTO
¿Sabemos exactamente cómo realizar la recuperación?
RECURSOS
¿Disponemos de la infraestructura y accesos necesarios?
TIEMPO
¿La recuperación real cumple los objetivos establecidos?
UN BACKUP NO ESTÁ REALMENTE VALIDADO HASTA QUE HEMOS COMPROBADO QUE PODEMOS RECUPERARLO
¿QUÉ OCURRE SI EL PROPIO BACKUP SE VE AFECTADO?
La infraestructura de backup también forma parte del entorno tecnológico y, por tanto, puede verse afectada por fallos, errores, accesos indebidos o incidentes de seguridad.
Una estrategia de recuperación debe contemplar qué ocurriría si el problema afectara simultáneamente a los sistemas de producción y a parte de las copias disponibles.
Separación, control de acceso, diferentes ubicaciones, protección frente a modificaciones y mecanismos de inmutabilidad pueden reducir el riesgo de que una única incidencia comprometa simultáneamente producción y recuperación.
PRODUCCIÓN ≠ BACKUP
Cuanto mayor sea la dependencia entre ambos entornos,
mayor puede ser el impacto de una incidencia común
RECUPERAR DATOS NO SIEMPRE SIGNIFICA RECUPERAR EL SERVICIO
Una restauración puede devolver los datos y, sin embargo, el servicio continuar indisponible.
Puede ser necesario recuperar servidores, aplicaciones, bases de datos, configuraciones, comunicaciones, identidades o servicios auxiliares en un orden determinado.
Por este motivo, una estrategia de recuperación debe contemplar no solo qué restaurar, sino también cómo, dónde y en qué secuencia hacerlo.
DATOS → SISTEMAS → DEPENDENCIAS → SERVICIO → OPERACIÓN
EL OBJETIVO FINAL NO ES RECUPERAR UNA COPIA. ES RECUPERAR EL SERVICIO
SEÑALES DE QUE LA ESTRATEGIA DE BACKUP NECESITA UNA REVISIÓN
COBERTURA
• No existe un inventario claro de qué se protege
• Se han incorporado sistemas sin revisar el backup
• Existen dependencias no contempladas
• La retención no responde a necesidades actuales
RECUPERACIÓN
• Las restauraciones apenas se prueban
• Se desconoce cuánto tardaría una recuperación completa
• No existen procedimientos documentados
• La recuperación depende de conocimiento individual
CONTINUIDAD
• No están definidos RPO y RTO
• Producción y backup comparten demasiadas dependencias
• No se ha planteado la pérdida simultánea de varios sistemas
• La estrategia no se revisa desde
hace años
«EL BACKUP FUNCIONA» NO SIGNIFICA NECESARIAMENTE «ESTAMOS PREPARADOS PARA RECUPERAR»
LA ESTRATEGIA DE RECUPERACIÓN TAMBIÉN DEBE EVOLUCIONAR
Las infraestructuras cambian.
Aparecen nuevas aplicaciones, servicios Cloud, máquinas virtuales, sedes, usuarios, volúmenes de información y nuevas dependencias.
Una estrategia que era adecuada hace dos años puede dejar de cubrir correctamente el entorno actual aunque todas las tareas de backup continúen ejecutándose sin errores.
Por eso, la protección y recuperación deberían revisarse cuando cambia la infraestructura y también de forma periódica.
SI LA INFRAESTRUCTURA CAMBIA, LA ESTRATEGIA DE RECUPERACIÓN TAMBIÉN DEBE HACERLO
ESTAR PREPARADO PARA RECUPERAR EMPIEZA ANTES DE LA INCIDENCIA
La capacidad de recuperación no debería comprobarse por primera vez cuando se produce una incidencia.
Conocer qué debemos proteger, establecer prioridades, identificar dependencias, definir objetivos y probar periódicamente los procedimientos permite afrontar una interrupción con mucha más información y capacidad de respuesta.
En ORION Technology analizamos la protección y recuperación desde una perspectiva global, considerando los datos, los sistemas, sus dependencias, los tiempos necesarios y la continuidad de los servicios.
El objetivo no es simplemente disponer de backups.
Es saber que podremos recuperar cuando realmente sea necesario.