Copia de seguridad y recuperación#

Este artículo describe el contenido de la copia y la preparación de recuperación de Docker con MariaDB o PostgreSQL integradas. Antes de operar, el administrador necesita el procedimiento de la versión y motor utilizados. Para una base externa, se acuerda con su administrador.

Contenido de la copia#

Una copia completa de la instalación incluye:

Las bases principal y de archivo de MariaDB, o toda la base PostgreSQL, incluidos sus esquemas principal y de archivo.
.env, docker-compose.yml y el docker-compose.override.yml utilizado.
backend/config, la configuración de nginx y los certificados.
Los datos de Almacenamiento del volumen orchestrator-storage.
Los datos de Vault, .vault_keys.json y vault/config/vault.hcl, si se utiliza Vault.

El volcado de la base de datos no contiene los demás archivos y volúmenes enumerados. Es necesario conservar el ORCHESTRATOR_ENCRYPTION_KEY original y las claves de desbloqueo de Vault; sin ellos, los secretos restaurados podrían ser inaccesibles.

Creación y verificación#

Antes de detener los servicios, es necesario obtener del soporte técnico de Sherpa el procedimiento de copia de seguridad y restauración de la base de datos para la versión y el motor utilizados. Contiene comandos para la base de datos. Por separado, es necesario preparar y probar la copia y restauración de configuración, certificados, Almacenamiento y Vault según los volúmenes montados. La copia de la instalación no está completa hasta verificar la recuperación de todos los componentes.

Es necesario acordar una ventana de mantenimiento, comprobar el espacio libre y seleccionar un directorio protegido.
Se deben detener el backend, WebSocket, nginx y las integraciones externas que escriben datos. El contenedor de la base seleccionada debe permanecer activo.
Es necesario crear un volcado del motor seleccionado siguiendo el procedimiento recibido y una copia de archivos y volúmenes coherente en el tiempo. Los comandos deben adaptarse antes de ejecutarlos si los nombres de las bases no son estándar.
Es necesario comprobar el código de salida de cada comando, que el volcado no esté vacío y las sumas de verificación. La copia debe trasladarse fuera del servidor manteniendo las restricciones de acceso.
La recuperación se prueba en una instancia de base de datos y volúmenes separados. La existencia del archivo de volcado no demuestra por sí sola que la copia sea utilizable.

Si no se prevé actualizar ni restaurar, después de copiar es necesario reiniciar los servicios según el procedimiento recibido para el motor seleccionado.

No deben reiniciarse los procesos de escritura entre el volcado y la actualización. De lo contrario, la copia ya no coincidirá con el estado previo a la actualización.

Recuperación y reversión#

La recuperación sustituye los datos actuales de la base de destino. Se requieren previamente un volcado verificado y una copia nueva e independiente del estado actual. La aplicación y los procesos externos de escritura deben permanecer detenidos.

Para revertir, primero se restauran imágenes y configuración compatibles con el volcado. Después se inicia únicamente la base de datos y se sigue la sección del motor correspondiente del procedimiento recibido para la versión y el motor utilizados. PostgreSQL se restaura en una base creada de nuevo para no conservar objetos de migraciones posteriores. La recuperación de prueba de MariaDB solo se realiza en una instancia y un volumen aislados.

No deben eliminarse los volúmenes de producción con docker compose down -v. El backend se inicia solo después de restaurar la base de datos, los archivos y los secretos, ya que puede aplicar migraciones al arrancar.

Después del inicio, es necesario comprobar el acceso, los Procesos y Almacenamiento, las Licencias, la lectura de secretos y un escenario de prueba seguro. La copia original se conserva hasta confirmar el resultado.