Sauvegardes des bases de données

Opfield crée des sauvegardes natives des bases PostgreSQL, clé-valeur et ClickHouse et les écrit vers une connexion de stockage. Les sauvegardes fonctionnent aussi bien pour les bases de données managées que pour les connexions externes et sont disponibles à partir de Personal. Chaque sauvegarde et chaque restauration s’exécute comme une tâche sur un nœud Storage que vous choisissez comme exécuteur, et non sur l’hôte Opfield.

Une sauvegarde protège les données applicatives. Elle ne remplace pas le jeu de reprise du plan de contrôle d’Opfield décrit dans Mises à jour, sauvegardes et restauration, et ce n’est pas une restauration à un instant donné : le calendrier détermine la quantité de données que vous pouvez perdre.

Avant de commencer

• Une connexion de stockage avec un bucket de destination existant. Opfield écrit dans le bucket et le préfixe que vous sélectionnez ; il ne crée pas le bucket. Les noms de buckets doivent respecter les règles de nommage S3, même pour les destinations FTP, FTPS et SFTP, où les buckets sont des répertoires sous le chemin de base.
• Un nœud Storage qui exécute un démon à jour et peut joindre à la fois la base de données et le point de terminaison du stockage. Pour les bases de données managées privées et le stockage objet managé, Opfield ouvre des routes privées temporaires pendant la durée de l’exécution.
• Une destination de stockage managé avec TLS doit servir un certificat qui inclut localhost et 127.0.0.1. Opfield ajoute automatiquement ces noms aux clusters créés avec une version antérieure ; tant que le nouveau certificat n’est pas servi, les exécutions attendent dans la file en affichant la raison et réessaient d’elles-mêmes, puis échouent avec BACKUP_STORAGE_CERTIFICATE_OUTDATED au bout de 7 heures. Voir Renouvellement des certificats TLS.
• Tant qu’une destination de stockage managé a ses écritures gelées pour une migration, les sauvegardes et restaurations qui y écriraient sont refusées avec STORAGE_WRITES_FROZEN ; déplacez ou suspendez d’abord leurs politiques.
• Pour une base de données externe qui utilise TLS, les tâches de sauvegarde et de restauration appliquent le paramètre de vérification des certificats de la connexion et sa CA personnalisée. Un exécuteur dont le démon Docker est antérieur à 2.11 ne peut pas vérifier les certificats ; une exécution pour une connexion vérifiée échoue donc avec BACKUP_EXECUTOR_TLS_VERIFICATION_UNSUPPORTED ; mettez à jour le nœud Storage ou désactivez la vérification pour cette connexion.
• Le nœud Storage doit pouvoir récupérer l’image de l’exécuteur de sauvegardes depuis GitHub Container Registry. L’exécuteur est livré avec la version d’Opfield et épinglé par empreinte ; pour PostgreSQL, il choisit les outils clients correspondant à la version du serveur. L’exécuteur n’est démarré que pour une sauvegarde ou une restauration et, comme les autres conteneurs internes d’Opfield, il est masqué des listes de conteneurs et des actions de cycle de vie des utilisateurs. Il contient des outils natifs fixes ; les clients de l’API ne peuvent fournir ni commandes, ni scripts, ni SQL, ni autres images.
• La permission de gérer les politiques de sauvegarde sur la base, nodes:backups:execute pour le nœud exécuteur, et les permissions de stockage listées dans Permissions. Le groupe intégré operator ne les inclut pas toutes.

Créer une politique de sauvegarde

1. Ouvrez la base de données et sélectionnez l’onglet Backups.
2. Choisissez Add policy.
3. Sous Destination, sélectionnez la connexion Storage, le Bucket et un Prefix. Le préfixe est obligatoire et vaut database-backups par défaut ; chaque exécution écrit ses artefacts et un manifest.json sous <prefix>/<run ID>/. Pour ClickHouse, ajoutez un stockage de transit S3 staging lorsque le moteur ne peut pas écrire directement vers la destination ; voir Mode de sauvegarde de chaque moteur.
4. Sous Execution, sélectionnez le Storage node qui exécutera les tâches.
5. Sous Schedule, laissez la politique manuelle ou saisissez une expression Cron numérique à cinq champs et un Timezone. La Console suggère 0 2 * * * dans le fuseau horaire de votre navigateur.
6. Sous Retention, définissez Completed backups to keep. Les sauvegardes terminées plus anciennes sont supprimées de la destination.
7. Sous Resource limits, ajustez l’espace de travail, le délai d’expiration, le CPU et la mémoire de la tâche si les valeurs par défaut ne conviennent pas à la base.
8. Enregistrez la politique, puis utilisez Run now une fois et attendez la fin de l’exécution avant de vous fier au calendrier.

Dans la Console, vous pouvez aussi activer ou désactiver le calendrier d’une politique et supprimer la politique. La modification des autres paramètres de la politique est disponible via l’API.

Paramètre	Plage autorisée	Valeur par défaut
Completed backups to keep	1–365	7
Workspace (GiB)	1–1024	20
Timeout (secondes)	60–86 400	3 600
CPU cores	1–32	1
Memory (MiB)	128–262 144	1 024

Mode de sauvegarde de chaque moteur

Moteur	Sauvegarde	Restauration
PostgreSQL	Dump natif au format custom	Dans une base de données vide
Stockage clé-valeur	Instantané RDB natif, enregistré avec son moteur (Redis ou Valkey)	Uniquement dans le même moteur : une sauvegarde Redis dans un stockage qui exécute Redis ou dans un nouveau stockage, une sauvegarde Valkey dans un stockage qui exécute Valkey ou dans un nouveau stockage. Le RDB vérifié est chargé dans un serveur temporaire de ce moteur, entièrement répliqué dans une cible vide, puis détaché. Une cible externe nécessite des privilèges de réplication et de configuration et doit pouvoir se connecter en retour à l’exécuteur
ClickHouse	BACKUP et RESTORE natifs via S3	Dans une cible vide via le même chemin S3

ClickHouse écrit sa sauvegarde via S3 ; le serveur ClickHouse lui-même doit donc joindre le point de terminaison S3. Pour une destination S3 managée privée sans transit, la source doit être une base ClickHouse managée et son nœud Storage doit être l’exécuteur. Un serveur ClickHouse externe nécessite une connexion S3 de transit qu’il peut joindre directement. Les destinations FTP, FTPS et SFTP nécessitent aussi une connexion et un bucket S3 de transit ; Opfield transfère les artefacts entre le transit et la destination finale, conserve la structure de répertoires native de ClickHouse et supprime ensuite la copie de transit.

Pour une cible clé-valeur externe, la restauration exécute un serveur temporaire protégé par mot de passe sur le réseau de l’hôte de l’exécuteur, sur un port aléatoire compris entre 20000 et 39999, et la cible se réplique depuis l’adresse de service de l’exécuteur. Autorisez cette connexion de la cible vers l’exécuteur pendant la durée de la restauration.

Exécutions, file d’attente et calendriers

Un nœud Storage exécuteur exécute une sauvegarde ou une restauration à la fois. Une exécution admise pendant que le nœud est occupé reste Queued et démarre dans l’ordre de création lorsque le nœud est libre ; une exécution en file d’attente peut être annulée immédiatement. L’annulation d’une tâche en cours attend la confirmation de l’exécuteur ; Force cancel met fin à l’exécution sans cette confirmation, tandis qu’Opfield continue de réconcilier la tâche en arrière-plan. Une exécution qui dépasse son délai de plus de 15 minutes est marquée en échec. Une politique a au plus une sauvegarde en file d’attente ou en cours : Run now pendant qu’une sauvegarde de la politique est active est refusé avec 409 BACKUP_ALREADY_RUNNING, qui nomme l’exécution active, et une exécution planifiée est ignorée, avec une erreur sur la politique. De même, une seule restauration vers le même nom de nouvelle base managée peut être en file d’attente ou en cours à la fois ; une autre est refusée avec 409 BACKUP_RESTORE_ALREADY_RUNNING. La base de données applique ces deux règles ; elles valent donc aussi entre plusieurs processus Opfield. Si une politique avait plusieurs sauvegardes actives lors de la mise à jour d’Opfield vers 2.11, une seule a continué — une sauvegarde en cours plutôt qu’une sauvegarde en file d’attente, sinon la plus récente — et les autres ont été marquées en échec et annulées ; voir Conflits résolus par la mise à jour 2.11. Si Opfield était en panne lorsqu’une heure planifiée est passée, il n’exécute que le créneau manqué le plus récent dans les dernières 24 heures plutôt qu’un arriéré.

Une sauvegarde n’est terminée qu’une fois son manifeste validé. Le manifeste enregistre l’identité de la source, la version du serveur, les tailles et les sommes de contrôle SHA-256 des artefacts ; un téléversement réussi seul ne compte pas. La conservation garde les sauvegardes terminées les plus récentes par politique et ne supprime que les artefacts plus anciens sous le préfixe de la politique, en ignorant les artefacts qu’utilise une restauration.

Les exécutions planifiées et la conservation agissent au nom du propriétaire de la politique — l’utilisateur qui a enregistré la politique en dernier — et Opfield revérifie les permissions de cet utilisateur avant chaque exécution. Si le propriétaire perd l’accès ou est supprimé, les exécutions planifiées sont ignorées et la politique affiche l’erreur jusqu’à ce qu’un utilisateur disposant des permissions requises enregistre la politique et en devienne le propriétaire.

Restaurer une sauvegarde

1. Dans l’onglet Backups, ouvrez Backup history et choisissez Restore sur une exécution terminée.
2. Choisissez le Storage node qui exécute la restauration, saisissez un nom pour la nouvelle base managée et choisissez éventuellement un dossier de bases de données pour elle. Lorsque le moteur utilise un nom de base, vous pouvez modifier le nom de la base cible. Ajustez Storage (GB), CPU cores, Memory (MB) et Swap (MB) si nécessaire.
3. Suivez l’exécution de la restauration jusqu’au bout, puis vérifiez la nouvelle base avec des requêtes applicatives avant d’y faire passer les clients.

La restauration depuis la Console crée une nouvelle base managée sur le nœud Storage exécuteur et n’écrase jamais les bases existantes. Elle nécessite la permission de créer des bases de données sur ce nœud ou dans le dossier choisi. Opfield utilise la version du catalogue la plus récente correspondant à la version majeure du moteur de la sauvegarde, et échoue s’il n’en existe aucune. La nouvelle base ne dispose d’aucune publication TCP et TLS y est activé. Son stockage, son CPU, sa mémoire et son swap reprennent par défaut la taille de la base managée source ; sinon, et pour les champs vides, elle reçoit 1 CPU, 1024 Mo de mémoire (2048 Mo pour ClickHouse), pas de swap, et un stockage de 20 Go ou de trois fois la taille de la sauvegarde, selon la plus grande valeur. La tâche de restauration elle-même utilise les limites de ressources par défaut — 20 Gio d’espace de travail et un délai d’une heure — plutôt que celles de la politique ; l’API peut les remplacer.

Via l’API, vous pouvez aussi restaurer une sauvegarde managée ou externe dans une connexion de base de données existante et vide du même moteur, qui n’est pas la source. Cela nécessite la permission de restauration sur la base de la sauvegarde et la permission de modification sur la cible. Une vérification préalable native confirme que la cible est vide, et Opfield vérifie à nouveau juste avant la restauration. Une restauration dans la connexion source de la sauvegarde elle-même est refusée avant la création d’une exécution, avec 409 BACKUP_RESTORE_SOURCE_REJECTED ; restaurez plutôt dans une autre connexion vide ou dans une nouvelle base managée.

Permissions

Scope	Autorise
databases:backups:view	Consulter les politiques et l’historique des exécutions
databases:backups:manage	Créer, modifier et supprimer des politiques et retirer l’historique des exécutions
databases:backups:run	Lancer et annuler des exécutions
databases:backups:restore	Restaurer une sauvegarde terminée
nodes:backups:execute	Utiliser un nœud Storage comme exécuteur

Le stockage de destination et le stockage de transit sont vérifiés séparément. Créer ou modifier une politique, lancer ou annuler une exécution, la conservation, la suppression des fichiers de sauvegarde et la restauration ne nécessitent que storage:credentials:use sur la destination, ainsi que sur le stockage de transit lorsqu’il est utilisé. Ce scope permet à l’exécuteur de sauvegardes de recevoir les identifiants de stockage enregistrés sans les montrer à l’utilisateur, et il n’ouvre pas l’explorateur d’objets ; storage:credentials:reveal l’inclut. Aucun scope storage:objects:* n’est nécessaire.

Les groupes intégrés admin et operator incluent storage:credentials:use. Le groupe operator peut créer des politiques et lancer des sauvegardes, mais n’inclut pas databases:backups:restore. Les jetons d’API et autorisations OAuth limités conservent leur propre autorité, plus restreinte. Voir la référence des scopes.

Règles de suppression et de conservation

Supprimer une politique arrête les exécutions futures. Pour retirer une exécution terminée de Backup history, choisissez ce qu’il advient de ses fichiers dans le stockage :

• Une exécution sans fichiers restants, par exemple après leur suppression par la conservation, est retirée directement.
• Delete backup and files supprime les fichiers de sauvegarde puis l’entrée d’historique ; la sauvegarde ne peut plus être restaurée. Cela nécessite storage:credentials:use sur la destination. Si le stockage refuse la suppression, l’entrée est conservée, la raison est affichée, et vous pouvez réessayer ou oublier l’entrée à la place.
• Forget entry ne retire que l’entrée d’historique et laisse les fichiers dans le stockage ; le journal d’audit enregistre leur bucket et leur préfixe.

Via l’API, DELETE /api/databases/{id}/backups/runs/{runId} accepte artifacts=delete ou artifacts=forget. Sans ce paramètre, une exécution dont les fichiers existent encore est refusée avec BACKUP_HISTORY_HAS_ARTIFACTS (409) ; un échec de suppression des fichiers renvoie BACKUP_ARTIFACT_DELETE_FAILED (502) et conserve l’entrée ; une exécution dont une restauration lit encore les fichiers renvoie BACKUP_ARTIFACT_IN_USE. L’outil de sauvegarde d’AI Workspace et de MCP accepte le même choix sous la forme config.artifacts. Les exécutions en file d’attente et en cours ne peuvent pas être retirées.

Un bucket auquel des politiques de sauvegarde ou un historique de sauvegardes font référence ne peut pas être supprimé. Une connexion de stockage à laquelle une politique de sauvegarde ou une exécution active fait référence ne peut pas non plus être supprimée ; lorsque seul un historique de sauvegardes terminées y fait référence, vous pouvez la supprimer en oubliant cet historique ; voir Stockage.

Une base de données ne peut pas être supprimée tant que l’une de ses sauvegardes ou restaurations est en cours. Lorsqu’une base est supprimée, ses politiques sont désactivées et retirées, et son historique de sauvegardes est conservé : Backups of deleted databases sur la page Databases liste ces sauvegardes et permet d’en restaurer une dans une nouvelle base. Dans MCP, les actions list_orphaned_runs, restore_orphaned, cancel_orphaned et delete_orphaned_run de manage_database_backups font de même ; elles nécessitent les scopes databases:backups:* sans restriction de base, car la suppression d’une base retire les droits qui la désignent. Planifiez le chiffrement côté destination, la conservation et le contrôle d’accès dans le système de stockage lui-même, et conservez au moins une copie hors du domaine de panne de la base et de son nœud Storage.

Testez régulièrement les restaurations sur une cible distincte. Une sauvegarde qui n’a jamais été restaurée ne constitue pas une preuve de reprise ; voir l’exercice de restauration.