Copias de seguridad de bases de datos

Opfield crea copias de seguridad nativas de bases de datos PostgreSQL, clave-valor y ClickHouse y las escribe en una conexión de almacenamiento. Las copias de seguridad funcionan tanto para las bases de datos gestionadas como para las conexiones externas y están disponibles en Personal y superiores. Cada copia de seguridad y cada restauración se ejecutan como un trabajo en un nodo Storage que eliges como ejecutor, no en el host de Opfield.

Una copia de seguridad protege los datos de la aplicación. No sustituye al conjunto de recuperación del plano de control de Opfield descrito en Actualizaciones, copias de seguridad y restauración, y no es una recuperación a un punto en el tiempo: la programación determina cuántos datos puedes perder.

Antes de empezar

• Una conexión de almacenamiento con un bucket de destino existente. Opfield escribe en el bucket y el prefijo que selecciones; no crea el bucket. Los nombres de los buckets deben seguir las reglas de nombres de S3 incluso para los destinos FTP, FTPS y SFTP, en los que los buckets son directorios bajo la ruta base.
• Un nodo Storage que ejecute un daemon actualizado y pueda llegar tanto a la base de datos como al endpoint de almacenamiento. Para las bases de datos gestionadas privadas y el almacenamiento de objetos gestionado, Opfield abre rutas privadas temporales mientras dura la ejecución.
• Un destino de almacenamiento gestionado con TLS debe servir un certificado que incluya localhost y 127.0.0.1. Opfield añade esos nombres automáticamente a los clústeres creados con una versión anterior; hasta que se sirve el nuevo certificado, las ejecuciones esperan en la cola con el motivo indicado y se reintentan solas, y fallan con BACKUP_STORAGE_CERTIFICATE_OUTDATED al cabo de 7 horas. Consulta Renovación del certificado TLS.
• Mientras un destino de almacenamiento gestionado tiene sus escrituras congeladas por una migración, las copias de seguridad y las restauraciones que escribirían en él se rechazan con STORAGE_WRITES_FROZEN; mueve o pausa antes sus políticas.
• Para una base de datos externa que usa TLS, los trabajos de copia de seguridad y de restauración aplican el ajuste de verificación del certificado de la conexión y su CA personalizada. Un ejecutor cuyo daemon de Docker es anterior a la 2.11 no puede verificar certificados, así que una ejecución para una conexión verificada falla con BACKUP_EXECUTOR_TLS_VERIFICATION_UNSUPPORTED; actualiza el nodo Storage o desactiva la verificación para esa conexión.
• El nodo Storage debe poder descargar la imagen del runner de copias de seguridad desde GitHub Container Registry. El runner se entrega con la versión de Opfield y está fijado por digest; para PostgreSQL, elige las herramientas cliente que corresponden a la versión del servidor. El runner solo se inicia para una copia de seguridad o una restauración y, como otros contenedores internos de Opfield, está oculto en las listas de contenedores y en las acciones de ciclo de vida de los usuarios. Contiene herramientas nativas fijas; los clientes de la API no pueden proporcionar comandos, scripts, SQL ni otras imágenes.
• Permiso para gestionar las políticas de copia de seguridad de la base de datos, nodes:backups:execute para el nodo ejecutor y los permisos de almacenamiento indicados en Permisos. El grupo integrado operator no los incluye todos.

Crea una política de copias de seguridad

1. Abre la base de datos y selecciona la pestaña Backups.
2. Elige Add policy.
3. En Destination, selecciona la conexión Storage, el Bucket y un Prefix. El prefijo es obligatorio y su valor predeterminado es database-backups; cada ejecución escribe sus artefactos y un manifest.json bajo <prefix>/<run ID>/. Para ClickHouse, añade un almacenamiento S3 staging cuando el motor no pueda escribir directamente en el destino; consulta Cómo se respalda cada motor.
4. En Execution, selecciona el Storage node que ejecutará los trabajos.
5. En Schedule, deja la política manual o introduce una expresión Cron numérica de cinco campos y una Timezone. La consola sugiere 0 2 * * * en la zona horaria de tu navegador.
6. En Retention, fija Completed backups to keep. Las copias de seguridad completadas más antiguas se eliminan del destino.
7. En Resource limits, ajusta el espacio de trabajo, el tiempo de espera, la CPU y la memoria del trabajo si los valores predeterminados no se ajustan a la base de datos.
8. Guarda la política, usa Run now una vez y espera a que termine la ejecución antes de depender de la programación.

En la consola también puedes activar o desactivar la programación de una política y eliminarla. Los demás ajustes de la política se cambian a través de la API.

Ajuste	Rango permitido	Valor predeterminado
Completed backups to keep	1–365	7
Workspace (GiB)	1–1024	20
Timeout (seconds)	60–86 400	3600
CPU cores	1–32	1
Memory (MiB)	128–262 144	1024

Cómo se respalda cada motor

Motor	Copia de seguridad	Restauración
PostgreSQL	Volcado nativo en formato personalizado	En una base de datos vacía
Almacén clave-valor	Instantánea RDB nativa, registrada con su motor (Redis o Valkey)	Solo en el mismo motor: una copia de Redis en un almacén que ejecuta Redis o en un almacén nuevo, una copia de Valkey en un almacén que ejecuta Valkey o en un almacén nuevo. El RDB verificado se carga en un servidor temporal de ese motor, se replica por completo en un destino vacío y después se desconecta. Un destino externo necesita privilegios de replicación y de configuración y debe poder conectarse de vuelta al ejecutor
ClickHouse	BACKUP y RESTORE nativos a través de S3	En un destino vacío por el mismo camino S3

ClickHouse escribe su copia de seguridad a través de S3, así que el propio servidor ClickHouse debe llegar al endpoint S3. Para un destino S3 gestionado privado sin staging, el origen debe ser una base de datos ClickHouse gestionada y su nodo Storage debe ser el ejecutor. Un servidor ClickHouse externo necesita una conexión S3 de staging a la que pueda llegar directamente. Los destinos FTP, FTPS y SFTP también requieren una conexión S3 de staging y un bucket; Opfield transfiere los artefactos entre el staging y el destino final, conserva la estructura de directorios nativa de ClickHouse y elimina después la copia de staging.

Para un destino clave-valor externo, la restauración ejecuta un servidor temporal protegido con contraseña en la red del host del ejecutor, en un puerto aleatorio entre 20000 y 39999, y el destino se replica desde la dirección de servicio del ejecutor. Permite esa conexión desde el destino hacia el ejecutor mientras dure la restauración.

Ejecuciones, cola y programaciones

Un nodo Storage ejecutor ejecuta una copia de seguridad o una restauración a la vez. Una ejecución admitida mientras el nodo está ocupado queda Queued y empieza por orden de creación cuando el nodo queda libre; una ejecución en cola se puede cancelar de inmediato. Cancelar un trabajo en ejecución espera a que el ejecutor lo confirme; Force cancel termina la ejecución sin esa confirmación mientras Opfield sigue conciliando el trabajo en segundo plano. Una ejecución que supera su tiempo de espera en más de 15 minutos se marca como fallida. Una política tiene como máximo una copia de seguridad en cola o en ejecución: Run now mientras hay una copia activa de la política se rechaza con 409 BACKUP_ALREADY_RUNNING, que indica la ejecución activa, y una ejecución programada se omite, con un error en la política. Del mismo modo, solo puede haber una restauración en cola o en ejecución hacia el mismo nombre de base de datos gestionada nueva; otra se rechaza con 409 BACKUP_RESTORE_ALREADY_RUNNING. La base de datos aplica ambas reglas, así que también se cumplen entre varios procesos de Opfield. Si una política tenía varias copias de seguridad activas cuando Opfield se actualizó a la 2.11, una siguió ejecutándose (una en ejecución antes que una en cola y, si no, la más reciente) y las demás se marcaron como fallidas y se cancelaron; consulta Conflictos resueltos por la actualización a la 2.11. Si Opfield estaba caído cuando pasó una hora programada, solo ejecuta la franja perdida más reciente dentro de las últimas 24 horas, no un atraso acumulado.

Una copia de seguridad solo está completa cuando se ha validado su manifiesto. El manifiesto registra la identidad del origen, la versión del servidor, los tamaños y las sumas de comprobación SHA-256 de los artefactos; una subida correcta por sí sola no cuenta. La retención conserva las copias de seguridad completadas más recientes por política y elimina solo los artefactos más antiguos bajo el prefijo de la política, omitiendo los artefactos que está usando una restauración.

Las ejecuciones programadas y la retención actúan como el propietario de la política (el usuario que la guardó por última vez), y Opfield vuelve a comprobar los permisos de ese usuario antes de cada ejecución. Si el propietario pierde el acceso o se elimina, las ejecuciones programadas se omiten y la política muestra el error hasta que un usuario con los permisos necesarios guarda la política y pasa a ser su propietario.

Restaura una copia de seguridad

1. En la pestaña Backups, abre Backup history y elige Restore en una ejecución completada.
2. Elige el Storage node que ejecutará la restauración, introduce un nombre para la nueva base de datos gestionada y, opcionalmente, elige una carpeta de bases de datos para ella. Cuando el motor usa un nombre de base de datos, puedes cambiar el nombre de la base de datos de destino. Ajusta Storage (GB), CPU cores, Memory (MB) y Swap (MB) si hace falta.
3. Sigue la ejecución de la restauración hasta el final y verifica después la nueva base de datos con consultas de la aplicación antes de pasar los clientes a ella.

La restauración desde la consola crea una base de datos gestionada nueva en el nodo Storage ejecutor y nunca sobrescribe bases de datos existentes. Requiere permiso para crear bases de datos en ese nodo o en la carpeta elegida. Opfield usa la versión más reciente del catálogo con la versión mayor del motor de la copia de seguridad y falla si no existe ninguna. La nueva base de datos no tiene publicación TCP y tiene TLS activado. Su almacenamiento, su CPU, su memoria y su swap toman por defecto el tamaño de la base de datos gestionada de origen; si no, y para los campos vacíos, recibe 1 CPU, 1024 MB de memoria (2048 MB para ClickHouse), sin swap, y un almacenamiento de 20 GB o tres veces el tamaño de la copia de seguridad, lo que sea mayor. El propio trabajo de restauración usa los límites de recursos predeterminados (20 GiB de espacio de trabajo y un tiempo de espera de una hora) en lugar de los límites de la política; la API puede sustituirlos.

A través de la API también puedes restaurar una copia de seguridad gestionada o externa en una conexión de base de datos existente y vacía del mismo motor que no sea el origen. Esto requiere permiso de restauración sobre la base de datos de la copia y permiso de edición sobre el destino. Una comprobación previa nativa confirma que el destino está vacío, y Opfield lo vuelve a comprobar justo antes de restaurar. Una restauración en la propia conexión de origen de la copia se rechaza antes de crear una ejecución, con 409 BACKUP_RESTORE_SOURCE_REJECTED; restaura en otra conexión vacía o en una base de datos gestionada nueva.

Permisos

Ámbito	Permite
databases:backups:view	Ver las políticas y el historial de ejecuciones
databases:backups:manage	Crear, cambiar y eliminar políticas y eliminar el historial de ejecuciones
databases:backups:run	Iniciar y cancelar ejecuciones
databases:backups:restore	Restaurar una copia de seguridad completada
nodes:backups:execute	Usar un nodo Storage como ejecutor

El almacenamiento de destino y el de staging se comprueban por separado. Crear o cambiar una política, iniciar o cancelar una ejecución, la retención, eliminar archivos de copias de seguridad y restaurar solo requieren storage:credentials:use sobre el destino, y sobre el almacenamiento de staging cuando se usa. Permite que el runner de copias de seguridad reciba las credenciales de almacenamiento guardadas sin mostrárselas al usuario, y no abre el explorador de objetos; storage:credentials:reveal lo incluye. No se necesita ningún ámbito storage:objects:*.

Los grupos integrados admin y operator incluyen storage:credentials:use. El grupo operator puede crear políticas y ejecutar copias de seguridad, pero no incluye databases:backups:restore. Los tokens de API y las concesiones OAuth con ámbitos limitados conservan su propia autoridad más restringida. Consulta la referencia de ámbitos.

Reglas de eliminación y retención

Eliminar una política detiene las ejecuciones futuras. Para eliminar una ejecución terminada de Backup history, elige qué ocurre con sus archivos en el almacenamiento:

• Una ejecución sin archivos restantes, por ejemplo después de que la retención los haya eliminado, se elimina directamente.
• Delete backup and files elimina los archivos de la copia de seguridad y después la entrada del historial; la copia ya no se puede restaurar. Esto requiere storage:credentials:use sobre el destino. Si el almacenamiento rechaza la eliminación, la entrada se conserva, se muestra el motivo y puedes reintentarlo u olvidar la entrada en su lugar.
• Forget entry elimina solo la entrada del historial y deja los archivos en el almacenamiento; el registro de auditoría anota su bucket y su prefijo.

A través de la API, DELETE /api/databases/{id}/backups/runs/{runId} acepta artifacts=delete o artifacts=forget. Sin ese parámetro, una ejecución cuyos archivos todavía existen se rechaza con BACKUP_HISTORY_HAS_ARTIFACTS (409); una eliminación de archivos fallida devuelve BACKUP_ARTIFACT_DELETE_FAILED (502) y conserva la entrada; una ejecución cuyos archivos todavía está leyendo una restauración devuelve BACKUP_ARTIFACT_IN_USE. La herramienta de copias de seguridad de AI Workspace y de MCP acepta la misma elección como config.artifacts. Las ejecuciones en cola y en ejecución no se pueden eliminar.

Un bucket al que hacen referencia políticas de copia de seguridad o el historial de copias no se puede eliminar. Una conexión de almacenamiento a la que hace referencia una política de copia de seguridad o una ejecución activa tampoco se puede eliminar; cuando solo hace referencia a ella historial de copias terminadas, puedes eliminarla olvidando ese historial; consulta Almacenamiento.

Una base de datos no se puede eliminar mientras se esté ejecutando una de sus copias de seguridad o restauraciones. Cuando se elimina una base de datos, sus políticas se desactivan y se eliminan, y su historial de copias de seguridad se conserva: Backups of deleted databases, en la página Databases, enumera esas copias y permite restaurar una en una base de datos nueva. En MCP, las acciones list_orphaned_runs, restore_orphaned, cancel_orphaned y delete_orphaned_run de manage_database_backups hacen lo mismo; requieren los ámbitos databases:backups:* sin restricción de base de datos, porque eliminar una base de datos elimina las concesiones que la nombran. Planifica el cifrado, la retención y el control de acceso en el lado del destino, en el propio sistema de almacenamiento, y conserva al menos una copia fuera del dominio de fallo de la base de datos y de su nodo Storage.

Prueba las restauraciones con regularidad en un destino separado. Una copia de seguridad que nunca se ha restaurado no es una prueba de recuperación; consulta el ejercicio de restauración.