Ir al contenido

Copias de seguridad

Pier hace copias de seguridad de las bases de datos volcándolas dentro del contenedor en ejecución, comprimiendo la salida y enviándola al almacenamiento de objetos. Las copias de seguridad se configuran por servicio y se ejecutan según una programación cron, aplicando la retención después de cada ejecución exitosa.

Las copias de seguridad están disponibles para PostgreSQL (incluidos PostGIS y TimescaleDB), MySQL, MariaDB y MongoDB. Cada motor produce un formato en disco diferente:

MotorHerramienta de volcadoFormato almacenado
PostgreSQL / PostGIS / TimescaleDBpg_dump -Fc (formato personalizado).dump (autocomprimido)
MySQL / MariaDBmysqldump.sql.gz (comprimido con gzip en Pier)
MongoDBmongodump --archive --gzip.archive.gz

Los volcados de PostgreSQL siempre se ejecutan como el superusuario del clúster, de modo que los esquemas de extensiones (p. ej., tiger/topology de PostGIS) se capturan de forma limpia.

Una programación con database_name establecido hace copia de seguridad de una única base de datos lógica. Una programación sin nombre de base de datos abarca todo el clúster: para los motores SQL, recorre todas las bases de datos que conoce y las agrupa en un único .tar.gz (entradas nombradas <db>.dump o <db>.sql); para MongoDB ejecuta un mongodump completo de la instancia.

La restauración es únicamente por base de datos. Los archivos tar de todo el clúster se admiten como origen —Pier extrae la única base de datos en la que estás restaurando—, pero no puedes restaurar un clúster completo en una sola acción.

Cada programación almacena una expresión cron, un recuento de retención y el almacenamiento S3 de destino. Valores predeterminados al crear una:

CampoPredeterminado
Cron0 2 * * * (diariamente a las 02:00)
Retención7 copias de seguridad conservadas

Las programaciones funcionan mediante el planificador unificado (consulta Tareas programadas): una programación de copia de seguridad aparece en la lista de Programaciones como una acción backup. También puedes lanzar una ejecución puntual en cualquier momento; una ejecución puntual por base de datos recurre al almacenamiento de la programación de todo el clúster si aún no existe una programación por base de datos.

Las copias de seguridad se cargan en almacenamiento de objetos compatible con S3 o en Bunny.net. Una entrada de almacenamiento contiene el endpoint, la región, el bucket, la clave de acceso, la clave secreta y un prefijo de clave opcional (predeterminado pier-backups). Las claves se organizan como {prefix}/{service}/{filename}. Usa Test para verificar la conexión antes de apuntar una programación hacia ella.

Tras cada copia de seguridad exitosa, Pier conserva las retention_count copias de seguridad completadas más recientes de esa programación y elimina el resto — tanto el blob del almacenamiento de objetos como el registro de la base de datos. Una limpieza fallida se registra, pero nunca hace fallar la propia copia de seguridad.

Existen dos rutas de restauración, ambas por base de datos y ambas destructivas — la base de datos de destino se elimina y se vuelve a crear, por lo que el destino ya debe existir en el servicio (sus credenciales almacenadas proporcionan el rol de propietario y la contraseña):

  • Restaurar desde una copia de seguridad almacenada — descarga el blob del almacenamiento, extrae la base de datos de un tar de clúster si es necesario, y la reproduce mediante pg_restore/psql/mysql/mongorestore.
  • Restaurar desde una carga directa — sube un archivo .dump, .sql.gz, .tar.gz o .archive.gz manualmente. Esta es la ruta de recuperación ante desastres entre clústeres: funciona en una instancia nueva de Pier sin almacenamiento configurado. El formato se detecta a partir del nombre del archivo y se valida contra el motor de destino.

Las copias de seguridad también pueden descargarse como archivos y eliminarse de forma individual.

Copia de seguridad del sistema de pier.db + .env

Sección titulada «Copia de seguridad del sistema de pier.db + .env»

Independientemente de las copias de seguridad de las bases de datos, Pier toma una instantánea local diaria de su propio estado: pier.db y .env se copian en data/backups/system/, con marca de tiempo por día, conservando los últimos 7 días. Esto protege la base de datos del plano de control y la configuración de cifrado; no se envía a un almacenamiento externo.