Imagen ornamental

Hasta ahora hemos visto qué son las Plataformas como Servicio (PaaS) y Azure Web Apps dentro de ellas, cómo crear, configurar y montar una aplicación en Azure Web Apps, cómo asociarle dominios y cómo asociarle certificados digitales para SSL. En el artículo de hoy vamos a ver cómo poner en marcha una estrategia de copias de seguridad sencilla pero efectiva, sin esfuerzo, utilizando lo que nos proporciona de serie nuestra Azure Web App.

Azure Web Apps ofrece la posibilidad de efectuar copias de seguridad automáticas de todos los archivos de la aplicación, la configuración y también de las bases de datos SQL Server o MySQL que estemos utilizando. Podremos establecer la frecuencia del backup y también el periodo de retención. Veremos que existen algunas limitaciones (y trucos) que deberíamos tener en cuenta.

¡Vamos allá!

Configurando el backup de la Web App

Desde el portal de Azure, entramos en nuestra Web App y buscamos el apartado Backups:

El diálogo de Backups

No tendremos nada configurado. Podemos hacerlo pulsando el botón Configure en la parte superior del panel o bien usando la barra de color gris que nos dice que no está nada configurado aún. Esto nos abrirá un nuevo panel en el que podremos especificar exactamente cómo será nuestro backup:

Configurar backup

Lo primero que debemos hacer es determinar en dónde se van a almacenar las copias de seguridad. Para ello debemos seleccionar un espacio de almacenamiento en Azure en el primer campo del panel anterior. Al pulsar sobre Storage Settings se nos muestra una lista con las cuentas de almacenamiento que tenemos disponibles en nuestra cuenta (si es que hay alguna):

Cuentas de almacenamiento

Lo mas recomendable es, quizá, crear un nuevo almacenamiento específico para hacer los backups y así controlar los costes independientemente y tenerlo separado de otros archivos, no vaya a ser que los borremos por error.

Si pulsamos el botón + para añadir una cuenta de almacenamiento se abrirá un nuevo panel para especificar los detalles:

Detalles de la nueva cuenta de almacenamiento

Le otorgamos un nombre, que debe ser único para todo Azure, un tipo de rendimiento (solo nos permite el de tipo estándar, pero es que en una copia de seguridad no necesitamos para nada discos de alta velocidad), el tipo de replicación y la zona geográfica.

El tipo de replicación de la información se refiere al modo en el que Azure va a guardar la información de nuestras copias de seguridad. Existen cuatro posibilidades de replicación:

  • Redundancia Local (LRS): todo el almacenamiento que utiliza Azure se replica siempre como mínimo en tres dispositivos físicos al mismo tiempo, para evitar que el fallo de cualquiera de ellos pueda afectar a la información. Este tipo de redudancia es el más básico (y el más barato) pero incluso así ofrece un 99.999999999% de disponibilidad (¡11 nueves!, es decir, disponibilidad total). La única pega que tiene es que si ocurre algo en el Data Center (un terremoto o una inundación, por ejemplo) podría darse el caso de que perdiésemos la información ya que solo está en ese DC. Esta es la más recomendable y ese "problema" se puede solucionar, como veremos en seguida.
  • Redundancia de Zona (ZRS): el almacenamiento se replica no solo localmente sino a otros DCs dentro de la misma área geográfica, de modo que es mucho más complicado que se puedan destruir. Ofrece una disponibilidad de 12 nueves y, curiosamente, es algo más barato que el anterior, lógicamente. En la actualidad se encuentra en pruebas y no está disponible en todas las zonas geográficas (de hecho solo en EEUU y en los DC de Francia, que se consideran en la zona norte de Europa).
  • Almacenamiento Geo-Redundante (GRS): esta es una gran opción si el coste no te preocupa en exceso (para un backup sería muy poco en cualquier caso) ya que replica tu información geográficamente en una segunda zona geográfica del mundo, a miles de kilómetros de donde esté la primera. Esto hace casi imposible que se pierdan los datos, aunque el coste es el doble, claro. La disponibilidad es de 16 nueves.
  • Almacenamiento Geo-Redundante de sólo lectura (RA-GRS): es muy parecido al anterior pero en la zona secundaria a la que se replican los datos, éstos solo se pueden leer, no modificar, y además recibe un punto de acceso independiente. Es, de hecho, más cara que la anterior.

Esto se puede cambiar más tarde si es necesario. Por el momento vamos a elegir LRS, que es de lo más barato (menos de 2 céntimos de euro por GiB) y está sobradamente probado. Su limitación de la zona la podemos suplir con el parámetro que nos falta por establecer: la ubicación.

Dado que el almacenamiento para las copias de seguridad se puede establecer en donde queramos, tampoco es mala idea crear el nuevo almacenamiento en una zona geográfica diferente a aquella en la que está la aplicación. De este modo, en el improbable caso de un grave desastre que pudiera afectar a los Data Centers de Microsoft en esa zona, tendríamos una copia de nuestra aplicación completa a miles de kilómetros de distancia. No nos afectará en el coste y no tendrá efectos negativos para nosotros.

En la figura anterior he elegido almacenamiento redundante local y la zona de Europa Norte, cuando mi Web App está en Europa Occidental. Esto significa que mi Web App estará en un Data Center probablemente de Holanda o Alemania (en cualquier caso dentro de la UE), y mi copia de seguridad en un DC probablemente en Irlanda (también en la UE y cumpliendo con las estrictas leyes de protección de datos europeas). Ambos elementos (app y backups) estarán separados por cientos o incluso miles de kilómetros, y a salvo de lo que pueda ocurrir en un lado u otro. Si pasara una desgracia natural en Alemania dudo que ocurra en Irlanda al mismo tiempo y podría levantar el sitio en otra Web App en minutos desde allí. Y viceversa.

Bien, aceptamos y regresaremos a la lista de cuentas de almacenamiento:

Lista de cuentas de almacenamiento

De momento aún no tenemos esta parte bien configurada, ya que hay que elegir, dentro de la cuenta que acabamos de crear, el espacio de almacenamiento concreto que vamos a emplear. Dentro de una cuenta tendremos que crear un área de almacenamiento de BLOBs (objetos binarios grandes, en general para almacenar cualquier tipo archivo. Se les llama simplemente "blobs") que será en donde se almacenarán verdaderamente las copias de seguridad. Al pulsar sobre la cuenta de almacenamiento que acabamos de crear se nos mostrará una lista (de momento vacía) de los blobs disponibles. Debemos crear uno usando el +

Lista vacía de blobs

Para el blob solo tenemos que establecer dos cosas:

  • Su nombre, que puede ser cualquiera que aún esté disponible en Azure.
  • Su tipo de acceso.

Nuevo blob

De los tres tipos de acceso al blob el único que nos interesa para un backup es el "Privado", que únicamente nos permitirá el acceso a nosotros. Los otros dos darían la posibilidad de descargarse los backups a cualquiera que se supiese su dirección, usando tan solo un navegador, y obviamente esto no nos interesa (no sé ni por qué nos ofrecen esta posibilidad aquí).

Aceptamos y esto nos devuelve al panel anterior:

Lista de blobs con el blob nuevo ya creado

Pulsamos sobre el blob para seleccionarlo y ya podemos seguir configurando el backup.

Lo siguiente a elegir es la frecuencia con la que realizaremos la copia de seguridad. Las opciones son escasas pero suficientes para la mayoría de los casos. Básicamente estableceremos si lo queremos hacer cada x horas o cada x días, y en qué fecha se debe comenzar a realizarlos. Poco que explicar aquí...

Configuración de frecuencia y retención

Se echa en falta poder hacer backups diferenciales e incrementales, y no solo completos, pero siendo gratis y estando orientado a aplicaciones Web (que no suelen ser muy grandes), debería ser suficiente en la mayor parte de los casos. Esto significa que cada vez que se hace un backup se copia todo lo que tengamos en la aplicación, excepto lo que excluyamos expresamente (como veremos luego). Es un backup completo.

Nota: para necesidades mayores de copias de seguridad Microsoft ofrece también el servicio Azure Backup, con muchas más posibilidades, con un (muy) pequeño coste adicional (aunque bastante razonable) pero más complejo de gestionar.

Quiero hacer hincapié en el número de días de retención... Las copias de seguridad se realizan por dos motivos principales:

  1. Poder recuperar los archivos de nuestra aplicación en caso de desastre.
  2. Ser capaces de consultar (y quizá recuperar) el estado que tenía la aplicación en un momento del pasado.

El primer motivo es obvio y es el que todo el mundo tiene claro. Pero el segundo es, de hecho, mucho más importante que el primero y a veces me sorprende escuchar a algunos usuarios e incluso a programadores, hacer caso omiso de éste, realizando tan solo una copia diaria sin retención alguna, en cualquier dispositivo o ubicación. Es más, si despliegan desde Git o Dropbox hay quien dice que ya que tienen la app en estas ubicaciones no necesitan hacer una copia de seguridad de la app en Azure. Si ocurre algo es importante poder ver el estado concreto de la aplicación "x" días atrás. Qué archivos exactamente estaban, y poder ver también la configuración. Nos permitirá diagnosticar problemas, recuperar archivos que se hayan sobrescrito o eliminado, etc...

La retención sirve para decidir cuántos días hacia atrás te quieres remontar en la vida de la aplicación para conocer su estado exacto. No deberíamos escatimar. Un mínimo de 7 días es recomendable, así como marcar la opción de que siempre exista al menos una copia (no vaya a ser que nos equivoquemos y borremos de más).

Finalmente, si nuestra aplicación utiliza alguna base de datos en Azure (SQL Server o MySQL) y su cadena de conexión está registrada en los parámetros de la aplicación, aparecerá en esta lista y podremos incluirla en la copia de seguridad. Algo muy útil, aunque en el caso de bases de datos Azure SQL no es necesario puesto que ya incluyen copia de seguridad integrada en el propio servicio.

Con esto ya tenemos todo lo necesario para poder poner en marcha las copias de seguridad de la aplicación. Tras haber aceptado, veremos que en el panel se nos da la opción de hacer un backup manual en cualquier momento y, si tenemos ya algunas copias almacenadas, de restaurar la aplicación a partir de una copia:

Copias ya configuradas y con algunas copias ya realizadas

En la figura vemos algunas copias que ya se han realizado y su tamaño. Si pulsamos en alguna de ellas se nos ofrece una información básica (en este caso vemos que a llevado poco más de 1 minuto realizarla) y se nos da la posibilidad de descargarla directamente al disco duro:

Info sobre un backup

Dado que están almacenadas en un blob también podemos acceder a ellas si accedemos a dicho blob, desde el propio portal de Azure:

Acceso a backups desde el portal de Azure

o desde otras herramientas como Microsoft Azure Storage Explorer:

Acceso a backups desde Microsoft Azure Storage Explorer

Cada backup consta de tres archivos:

  • .zip: contiene los datos de la aplicación. Incluye no solo la carpeta de la misma, sino otras carpetas con configuraciones, logs, extensiones del sitio, info sobre despliegues, etc... De hecho la raíz del ZIP contiene una carpeta de nombre fs (de File System), y los archivos de nuestra aplicación están en fs/site/wwwroot.
  • .xml: contiene un manifiesto con metadatos sobre el backup, como los dominios que están asociados a la aplicación y cosas así. Puede ser útil si no los teníamos bien documentados.
  • .log: un log (bastante básico) sobfe el proceso de backup.

Con el .zip tenemos lo suficiente para poder recuperar cualquier archivo que hubiera en la app en el momento de hacer la copia de seguridad.

Recuperar una copia a una Web App

Aunque lo más normal será que queramos obtener algún archivo suelto y no restaurar la aplicación, si necesitamos hacerlo ante un desastre grave o si queremos simplemente restaurarla para comprobar su funcionamiento, podemos hacerlo usando el botón de Restaurar que tenemos en el panel de backups.

Al pulsar esta opción se nos muestra otro panel en el que tenemos las opciones de restauración:

Opciones de restauración

Lo primero es elegir el origen del backup. Normalmente usaremos los backups asociados a nuestra aplicación, pero si lo que queremos es restaurar una aplicación diferente (por ejemplo, en caso de que se haya destruido por error la Web App), podremos hacerlo usando la opción Storage que nos mostrará todos los backups que tengamos en nuestro almacenamiento, y no solo los de la aplicación actual.

Luego debemos elegir en dónde lo vamos a restaurar. Hay que tener mucho cuidado con esto. Por defecto se selecciona la opción de sobrescribir la aplicación actual. Esto quitará todo lo que tengamos actualmente para poner lo que hay en la copia de seguridad. Podemos perder mucha información y quizá no sea lo que queremos. Solo deberíamos usarlo en casos extremos en los que se haya perdido casi todo o haya un problema grave (por ejemplo tras una actualización, pero par evitar eso están los "slots").

Lo más recomendable suele ser usar la otra opción llamada New or existing app que nos permite elegir otra Web App en la que restaurar (por ejemplo una nueva que hayamos creado ex-profeso) o bien un slot dentro de la actual, que deberemos haber creado previamente.

Finalmente debemos decidir si queremos que restaure también las cadenas de conexión a las bases de datos (no debería ser necesario si es la misma app y esto no ha cambiado) y que haga caso omiso de que los nombres de dominio asociados ya existan en otras aplicaciones de nuestra suscripción (por si estamos duplicando una: luego podemos gestionarlo como ya hemos visto).

Excluyendo archivos

Existen algunas limitaciones de los backups de Azure Web Apps aparte de los que ya hemos visto (¡solo copias completas!). La mayor limitación es el tamaño máximo de backup que podemos crear: 10GB. Si tenemos más de 10GB entre archivos y base de datos, se producirá un error y no se realizará la copia de seguridad. Si necesitas más que esto debes recurrir a Azure Backup, como ya he comentado antes.

Por ello y otros motivos, en ocasiones puede ser útil eliminar del backup algunos archivos. Por ejemplo si hay una carpeta "gorda" con imágenes y vídeos que no cambian nunca y que tenemos en otro lado, o si no queremos guardar los logs y otros archivos operativos... Cosas por el estilo.

Si queremos que ciertos archivos no se almacenen en el backup por el motivo que sea, podemos conseguirlo creando un archivo de texto especial en la raíz de nuestra aplicación con el nombre _backup.filter. En este archivo mete, una por línea, las rutas de las carpetas y archivos que quieras excluir de la copia de seguridad. Estas rutas se deben dar desde el raíz (la carpeta fs) de la que hablé antes y que está en la base del ZIP resultante, de este modo:

\site\wwwroot\Videos\
\site\wwwroot\Descargas\ArchivoGiganteQueTengoEnOtroLado.zip

Por desgracia no se pueden especificar comodines ni nada similar, por lo que si queremos excluir varias carpetas o archivos que se llamen muy parecido hay que especificarlos uno a uno

Posibles errores

Aunque no es frecuente que falle una copia de seguridad, cuando lo hace podremos consultar en su panel de información el motivo de dicho fallo. Aunque los mensajes tratan de explicar el motivo, a veces son un tanto crípticos.

Por suerte Ahmed Elnably un Program Manager de Azure Web Sites, escribió un post recogiendo todos los errores con sus soluciones. Ten este enlace a mano por si te fallan alguna vez. Te puede venir muy bien.

En resumen

Los backups de Azure Web Apps, aún siendo limitados en cuanto a funcionalidad y tamaño, son una forma gratuita, eficaz y muy sencilla de tener a buen recaudo nuestras aplicaciones y sitios web, de modo que no los perdamos en caso de una desgracia por nuestra culpa o causas ajenas. En este artículo hemos aprendido a configurarlos bien, a restaurarlos y también sus limitaciones y posibles errores.

Las Azure Web Apps tiene todavía muchas más cosas que aprender y a las que sacarles partido. Sin embargo con esta serie de artículos he procurado repasar todo lo importante para que puedas crear y mantener tus aplicaciones y sitios web en Azure sin complicarte la vida y de forma rápida y sencilla. Espero haberlo conseguido.

Quizá en el futuro añada más información sobre características concretas de esta interesante tecnología. Pero de momento voy a dar por terminada la serie.

¡Espero que te sea útil!

Si te interesa este tema, he publicado un eBook gratuito titulado "Guía Práctica - Azure Web Apps". Puedes descargarlo desde el enlace anterior.

Escrito por un humano, no por una IA