# Backups, Restores, Upgrades y Rollbacks

## Realizando un Backup <a href="#backups" id="backups"></a>

Los archivos de backup involucran por un lado, archivos de configuración personalizados de Asterisk (/etc/asterisk/custom). Por otro lado, se efectúa un respaldo de la Base de Datos Relacional de Postgres.&#x20;

Para correr un backup, se debe ejecutar el siguiente script:

```
./deploy.sh --action=backup --tenant=<tenant-folder>
```

Dicho respaldo es depositado en el Bucket asociado a la instancia durante su proceso de despliegue. Recordemos que los escenarios expuestos permiten incorporar MinIO como bucket por default, o bien sumar soluciones populares de Cloud Providers orientadas a Object Storage, como Spaces (Digital Ocean) o S3 (Amazon).

Dentro del bucket, se observará una carpeta de backup con un archivo .sql precedido por el timestamp de ejecución (marca de tiempo). A su vez, otro directorio contará con los respaldos de Asterisk correspondientes.

<figure><img src="/files/FslAUdeiEqsjwPFVasZj" alt=""><figcaption></figcaption></figure>

## Realizando un Recovery <a href="#restore" id="restore"></a>

Frente a un escenario de Disaster, es posible proceder a un Fresh Install de una instancia productiva y aplicar una acción de restauración de información desde un backup (Recovery).

Para que ésto suceda de manera efectiva, debemos modificar los últimos dos parámetros del inventory.yml correspondiente a nuestra carpeta de tenants. Ésto último es necesario para indicar que el bucket no maneja certificados confiables, y para configurar el timestamp del backup a restaurar:

```
restore_file_timestamp: 1681215859 
```

De esta manera, ejecutando el siguiente script con la action "restore", se procederá a reinstaurar el backup tomado en el paso previo sobre la nueva instancia desplegada y contar asi con un ambiente recuperado:

```
./deploy.sh --action=restore --tenant=<tenant-folder>
```

## &#x20;<a href="#upgrades" id="upgrades"></a>

## Realizando un Upgrade <a href="#upgrades" id="upgrades"></a>

El Equipo de OMniLeads construye imágenes de todos los componentes que conforman su arquitectura (builds). Los mismos están hosteados en Docker Hub en el siguiente enlace:

{% embed url="<https://hub.docker.com/repositories/omnileads>" fullWidth="false" %}

Es importante diferenciar el Repositorio principal de Aplicación (Web) del resto de los repositorios de componentes (asterisk, rtpengine, kamailio, nginx, websockets y postgres).

La Web App utiliza una semántica de definición de releases que implica RC (releases candidatos) y STABLE (releases aptos para ambientes productivos), como se observa a continuación:

```
pre-release-X.Y.Z
X.Y.Z
```

Sin embargo, el resto de los componentes utilizan semánticas de fechas seguidas por el número de versión de dicho release, por ejemplo:

```
230204.01
```

Cada vez que un release de WebApp es liberado, el mismo se disponibiliza por medio de una imágen en el registro de containers (Container Registry). A su vez el archivo el archivo **Releases-Notes.md** en la raiz del repositorio es actualizado para contemplar un correcto "mapping" entre las versiones de los componentes y la versión del Release de aplicación.

Por lo tanto, para aplicar actualizaciones de manera correcta es importante "traernos" los últimos cambios correspondientes a la rama estable. Ésto lo logramos con el siguiente comando:

```
git fetch all
git pull origin main
git checkout release-2.3.1
```

A partir de alli, el próximo paso es actualizar el archivo inventory.yml (correspondiente al tenant) con la versión "target". Por ejemplo, "2.X.X" en la captura debajo:

```
omnileads_img: docker.io/omnileads/omlapp:250201.01
asterisk_img: docker.io/omnileads/asterisk:250102.01
```

Por último, procedemos a ejecutar el script con la acción "upgrade" a los efectos de proceder a la actualización del/de el/los componente/s en cuestión.

```
./deploy.sh --action=upgrade --tenant=<tenant_folder>
```

## Realizando un Rollback <a href="#rollback" id="rollback"></a>

El uso de Contenedores en OMniLeads permite ejecutar procedimientos de rollbacks de manera rápida y segura. De esta manera podemos recuperar las versiones previas a la actualización en caso la misma no haya generado resultados satisfactorios.

```
omnileads_img: docker.io/omnileads/omlapp:240117.01
asterisk_img: docker.io/omnileads/asterisk:240102.01
```

Con el inventory.yml modificado, es posible entonces volver a la versión previa al cambio:

```
./deploy.sh --action=upgrade --tenant=tenant_name_folder
```

Para mayor información, sugerimos visitar la documentación expuesta en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.omnileads.net/instalacion-de-omnileads/deploy-utilizando-ansible/backups-restores-upgrades-y-rollbacks.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
