Azure Backup: Optimización del Coste y RTO

Algo que todo tenemos siempre muy presente son las copias de seguridad de nuestros datos, desde los servidores virtuales hasta los datos que generamos a diario. Siempre hemos estado muy concienciados con su configuración y sus procesos de recuperación, tratando de tener siempre las suficientes copias para poder recuperar “casi cualquier cosa en cualquier momento”. Muchas veces no olvidamos de su coste, tanto operativo como económico y, aunque siempre deberíamos tenerlo presente, se ha vuelto más “crítico” cuando hemos empezado a disponer del servicio de backup en modo SaaS.

Los servicios SaaS no son infinitos aunque lo parezcan… ni por volumen, ni por coste, ni por impacto en nuestras infraestructuras de IT. El servicio de backup no será una excepción y, debemos tenerlo muy presente para poder buscar una relación entre la seguridad de recuperar un dato como el coste que ello nos supondrá.

Hoy voy a comentar algunas buenas prácticas/recomendaciones cuando configuramos nuestra copias de seguridad en Azure, buscando equilibrar la recuperación de nuestro entorno y que no excedamos unos costes tangibles (€) y “intangibles” (operacionales). Antes de continuar, aquí os dejo la infografía para este artículo:

No será un artículo con un gran componente técnico, más bien de gestión de copias de seguridad y que cosas debemos tener en cuanto cuando utilizamos Azure Backup. Este será el guion para este articulo:

• Establecer el tipo de replicación de nuestras copias de seguridad (LRS, GRS o RA-GRS)
• Definir los puntos de definición para cada servidor y datos de los cuales realizar copias de seguridad
• Optimizar las copias de seguridad de servidores  de datos

Cuando iniciamos la configuración de copias de seguridad en Azure, lo que haremos es crear un nuevo recurso: Almacén de Recovery Services. Una vez creado, las primeras cosas que debemos revisar son :

• Tipo de replicación de almacenamiento: por defecto la replicación será geográfica, una vez que hayamos configurado una copia de seguridad ya no podemos modificarlo.
• Eliminación temporal: habilitado por defecto, esto permita que no se elimine de forma inmediata las copias de seguridad eliminadas (accidentalmente o no) durante 14 días
• Restauración entre regiones: si habilitamos la configuración de réplica geográfica de las copias de seguridad tendremos la opción de restaurar VM en una región secundaria

Si queremos que las copias de seguridad estén replicadas geográficamente, evitando que, ante cualquier desastre de la región actual tenga algún problema podamos restaurar las copias de seguridad sin problema. Como había comentado, la replicación geográfica está habilitada por defecto en cada almacén de recuperación. Para poder cambiar el tipo de replicación debéis acceder a la cuenta de recuperación – Propiedades y pulsar en actualizar en la sección de Configuración de copias de seguridad:

Si queremos cambiar la replicación del almacenamiento donde se alojarán nuestras copias de seguridad, debemos pulsar en Redundancia Local. Sino es así, podemos dejarlo tal cual viene por defecto y, en ese caso, tendremos la posibilidad de habilitar la

Vamos a pararnos aquí, puesto que la elección del tipo de replicación es un elemento importante a tener en cuenta en cuanto al costo del servicio.  Aquí os muestro una simulación rápida del coste de una misma copia de seguridad de ficheros (500GB) en los diferentes tipos de replicación:

• LRS: la copia de datos tiene un coste de 15,11€ + 8,43€ de la instancia protegida

• GRS: la copia de datos tiene un coste de 30,22€ + 8,43€ de la instancia protegida

Como podéis ver, el coste de almacenamiento es exactamente el doble, con lo que debemos tener cuidado con el tipo de replicación en función del tipo de activo del cual haremos copia de seguridad. Es posible que, para muchos servicios de los cuales haremos copia de seguridad podemos utilizar LRS. Las copias con replicación local (LRS), replican los datos tres veces dentro del mismo centro de datos en la misma región, esto nos protege los datos frente a errores secciones de servidores y en unidades:

Si por el contrario necesitamos mantener las copias replicadas geográficamente, igualmente tendremos las tres copias síncronas en la misma ubicación física en la región primaria. Luego, de forma asíncrona se replicará en una zona región secundaria y, por último en la región secundaria se replicará nuevamente tres veces nuevamente vía LRS.

Esto permite a Microsoft ser altamente tolerante a fallas, permitiendo ofrecernos ese 99,99999999999999 % de disponibilidad mínima en un año.

Una vez que tenemos claro el funcionamiento de la replicación de nuestras copias, debemos establecer unos puntos de recuperación que nos permitan recuperar nuestra información sin que por ello tengamos cientos de puntos de recuperación o infinitos GB almacenados de los cuales no haremos uso en ningún momento.

Cada que vez que realizamos una copia de seguridad se realizan puntos de recuperación, a partir de los cuales podemos llevar a cabo operaciones de recuperación. Es importante que definamos correctamente los puntos de recuperación en base a los requisitos de negocio, criticidad de la información o por cualquier otro motivo, pero debemos definir una estrategia clara en cuanto a los puntos de recuperación definidos en nuestras políticas de backup. A continuación, os voy a mostrar los puntos de recuperación de un servidor de ficheros, en donde queremos configurar una copia de seguridad:

Por un lado definimos el momento del día (hasta 3 copias diarias) en el que queremos crear un punto de recuperación:

Y por otro lado, definimos los puntos de recuperación y sus retenciones: Diarias, Semanales, Mensuales y Anuales (los colores no aparecen en la configuración del backup, los he puesto yo para que los podáis identificar en la infografía)

Es importante tener claro los puntos de recuperación y sus retenciones, a mas puntos de recuperación más histórico de backup tendremos, pero también más almacenamiento ocuparemos y más costo tendrá. Para calcularlo el coste, podéis ayudaros con la calculadora de Azure y os podéis hacer una idea del tamaño que podrían ocupar vuestros puntos de recuperación y su coste:

Cuando realizamos copias de seguridad de las máquinas virtuales, ahora, tenemos la posibilidad de solo copiar el disco de sistema operativo. Esto nos viene perfecto cuando por ejemplo queremos hacer copia de seguridad de la MV de un SQL Server, el cual tiene disco de sistema (126G) y varios discos de datos (2TB), pero además se su correspondiente backup con Azure Backup SQL. Queremos hacer copia de la VM  puesto que queremos tener una copia de las configuraciones del SO y del SQL, pero no de discos que no queremos hacer copia porque ya lo estamos haciendo con otra solución de backup.

Hacer copia de una VM siempre es interesante, pero como os comentaba en muchas ocasiones solo queremos llevarnos el disco de SO, evitando así realizar una copia de seguridad con datos que no nos hacen falta (aplicaciones, ISOS, etc..) o que ya estamos incluyendo en otras copias.  Además del ahorro de coste del backup, también reducimos la ventana de copia de seguridad  pudiendo ajustarse a horas de poca actividad sin impactar en el rendimiento del servidor.

A continuación, voy a mostraros como podemos hacer copia de seguridad de una VM pero solo incluir el disco de Sistema Operativo. Desde el Almacén de Recovery Services en el cual queréis configurar la copia de seguridad de VM accedéis a Copia de Seguridad, elegís que la carga de trabajo se ejecuta en Azure y máquina virtual como elemento del cual queremos hacer copia de seguridad, luego pulsamos en Copia de seguridad:

Pulsamos en Agregar:

Elegimos la VM de la cual queremos hacer copia de seguridad y, ahora marcamos la casilla de Solo disco SO:

Una vez que pulsemos en Habilitar Backup ya tenemos nuestra copia de seguridad de la VM, pero sin el disco de SO. No lo he comentado, pero deberíamos definir también la política de copia de seguridad, para que se ajuste a nuestras expectativas. Con la copia de de seguridad de la VM sin disco, el proceso de copia será más rápido, puesto que copiaremos únicamente el espacio ocupado en el disco del sistema.

Esta configuración a buen seguro que es muy útil para muchos de nuestros servidores, puesto que no necesitamos que copiar más que el disco del SO y el resto de datos con el Agente de Backup de Azure o con las copias por ejemplo de Azure Backup SQL. Además, cada servidor con sus diferentes roles tendrán unos puntos de recuperación u otros. Por ejemplo, un servidor de ficheros el cual a nivel de SO no tiene muchas modificaciones o ninguna en meses, sería suficiente la siguiente configuración para las copias de la MV:

• Diarias: 0
• Semanal: 0
• Mensual: 2
• Anual: 0

Pero el mismo servidor para las carpetas compartidas, podría tener los siguientes puntos de recuperación:

• Diarias: 7
• Semanal: 4
• Mensual: 12
• Anual: 5

Esto mismo podría servidor para una VM con SQL Server u otro servidor con modificaciones muy ocasionales en cuanto a configuraciones de la aplicación o sistema, de tal forma que nos ahorramos mucho dinero y tiempo de procesamiento de la copia de seguridad.

Como veis no es un proceso complejo, pero necesita su análisis para que pueda cubrir las dos expectativas de negocio más importantes:

• Recuperar información
• Coste

Aunque el coste siempre es una conversación controvertida con cualquier cliente, porque cuanto costaría no tener un backup que cumpla expectativas y no poder restaurar tu infraestructura?… yo no estoy hablando de esto, sino de una vez que se cumplan las expectativas de negocio en cuanto a recuperar la infraestructura, sea con el menor coste económico y de operaciones posible.

Espero que os haya aclarado algo con respecto a las copias de seguridad, optimizar los costes y los proceso de copia de seguridad. Igualmente, para que podáis tener más claridad en este asunto, aquí os dejo un artículo muy interesante de MSFT: Copia de seguridad en la nube de cargas de trabajo locales y en la nube

Ahora, como siempre, os toca a vosotros probarlo!!