7. 6
¿Qué es un Desastre?
Tipos de desastre
# rm -rf /
# chmod -R 000 /
8. 7
¿Qué es un Desastre?
Principales causas de pérdida de servicio
**The State Of Business Technology Resiliency, Q2 2014 (FORRESTER)
9. 8
Algunos conceptos básicos
BIA, RPO & RTO
Recovery Point Objective (RPO)
El objetivo de tiempo de recuperación (RTO) es la máxima cantidad
de tiempo que un sistema, aplicación o red puede estar inactiva
después de que ocurra un desastre o fallo.
.
Recovery Time Objective (RTO)
El objetivo de punto de recuperación (RPO) es el punto máximo
asumible de pérdida de datos después de un desastre. El RPO
determina la frecuencia con la que se deben realizar las copias de
seguridad.
El análisis de impacto de negocio (BIA) es el proceso que identifica
y evalúa los efectos potenciales de los eventos causados por
desastres naturales y/o artificiales en las operaciones.
.
Business Impact Analysis (BIA)
10. 9
Algunos conceptos básicos
Disaster Recovery & Business Continuity
Disaster Recovery (DR)
La continuidad del negocio (BC) describe los procesos y
procedimientos para garantizar que una funcion de negocio pueda
continuar durante un desastre y hasta recuperar un estado estable.
.
Business Continuity (BC)
La recuperación ante desastres (DR) se refiere al proceso de
recuperación de una función del negocio a un estado estable
después de un desastre.
12. 11
High
Availability
Data Backup
& Replication
Disaster
Recovery
Garantiza la disponibilidad del
servicio eliminando los puntos únicos
de fallo, normalmente duplicando la
infrastructura.
Garantiza la restauación de manera
rápida y eficaz de los servicios en
caso de desastre.
Garantiza los datos y su
consisténcia junto con su
disponibilidad en diferentes
localizaciones.
High Availability Disaster RecoveryData Backup & Replication
Business Continuity
3 factores muy importantes
Business
Continuity
13. 12
High
Availability
Data Backup
& Replication
Disaster
Recovery
Garantiza la disponibilidad del
servicio eliminando los puntos únicos
de fallo, normalmente duplicandoo la
infrastructura.
Garantiza la restauación de manera
rápida y eficaz de los servicios en
caso de desastre.
Garantiza los datos y su
consisténcia junto con su
disponibilidad en diferentes
localizaciones.
High Availability Disaster RecoveryData Backup & Replication
Bussiness Continuity
3 factores muy importantes
Bussiness
Continuity
14. 13
High
Availability
Data Backup
& Replication
Disaster
Recovery
Garantiza la disponibilidad del
servicio eliminando los puntos únicos
de fallo, normalmente duplicando la
infrastructura.
Garantiza la restauación de manera
rápida y eficaz de los servicios en
caso de desastre.
Garantiza los datos y su
consisténcia junto con su
disponibilidad en diferentes
localizaciones.
High Availability Disaster RecoveryData Backup & Replication
Bussiness Continuity
3 factores muy importantes
Business
Continuity
15. 14
High
Availability
Data Backup
& Replication
Disaster
Recovery
Garantiza la disponibilidad del
servicio eliminando los puntos únicos
de fallo, normalmente duplicando la
infrastructura.
Garantiza la restauación de manera
rápida y eficaz de los servicios en
caso de desastre.
Garantiza los datos y su
consisténcia junto con su
disponibilidad en diferentes
localizaciones.
High Availability Disaster RecoveryData Backup & Replication
Bussiness Continuity
3 factores muy importantes
Business
Continuity
Business Continuity
16. 15
Sistema Operativo Datos de aplicación
OS vs App Data
Diferencias entre backups de sistema y datos
Requisitos restore:
- HW (Phys-Virt)
- Red
RPO vs RTORTO vs RPO
Requisitos restore:
- Sistema configurado
- Agente instalado
SysAdmin Backup Admin
32. 31
DRLM
Features
●
Gestión centralizada
●
Reporte de errores automático en caso de fallo
●
Migración de sistemas GNU/Linux
●
Recuperación completamente por red
●
Debugging/Troubleshooting integrado en la DRLM CLI
●
Desarrollado completamente en Bash
●
Open Source
33. 32
DRLM
Roadmap
●
Implementación GRUB2 para homogenización del netboot (multiarch)
●
Mejoras en automatización
●
Logs de ReaR en DRLM
●
Export/Import de imágenes DR
●
Backups incrementales
●
Añadir soporte para CIFS, ISO, RSYNC, ...
●
Integración con APIs de Virtualización y Cloud
●
Mejoras en instalador y configuración DRLM
●
Etc, etc, etc ...
34. 33
DRLM
Un poco de historia...
Ago 2013: Arranca el proyecto DRLM (aka DRLS)
Oct 2013: Primera publicación del código DRLM en Github.
Dic 2013: Primera versión estable de DRLM (v1.0.0)
Dic 2014: Integración completa de DLRM con ReaR
(issue #522) – ReaR 1.17
Ene 2015: Publicadas las webs del proyecto DRLM
www.drlm.org y docs.drlm.org
35. 34
DRLM
Un poco de historia...
Mar 2015: Publicada la versión 1.1.1 de DRLM
May 2015: Se define Roadmap para DRLM versión 2
Ene 2016: DRLM presente en el FOSDEM’16
Jun 2016: Congelado el código DRLM v2.0.0
- pendientes los últimos tests
- cerrar nueva versión de la documentación
Jun 2016: DRLM presente en OpenExpo’16
36. 35
DRLM
Caso de éxito: GRIFOLS
GRIFOLS es la tercera empresa del mundo en el sector de los
hemoderivados y la primera en Europa.
El proyecto DRLM nace de la necesidad de GRIFOLS para gestionar el
DR de sus sistemas GNU/Linux.
Como empresa del sector farmacéutico debe cumplir con estrictos
controles que agencias como la FDA (USA) y EMEA (Europa) les exigen
para todo sistema y/o servicio relacionado con medicamentos.
En Marzo de 2014 se finaliza la implementación de DLRM para la gestión
del DR en Linux en los centros de datos de GRIFOLS.
Además de la gestión de DR también lo usan como herramienta para las
migraciones de sistemas P2P, P2V, V2P, V2V, despliegues de sistemas
con una imagen template y clonación de entornos..