DONNÉES

Sauvegardes et restaurations

Planifiez des sauvegardes, externalisez-les, vérifiez qu’elles sont restaurables, et restaurez à un instant donné.

Une sauvegarde capture les répertoires de données de vos applications, vos bases gérées et vos volumes nommés dans une seule archive chiffrée. Elle peut tourner selon une planification, atterrir hors site sur S3, et — la partie que la plupart des panneaux omettent — être testée sans toucher à quoi que ce soit de vivant.

Une définition, et ses exécutions

Deux objets différents portent le mot « sauvegarde », et la distinction évite bien des confusions :

Une définition: La configuration — quoi capturer, où l’envoyer, à quelle fréquence. Elle ne détient aucune donnée, n’est jamais restaurable, et ne compte pas dans le quota de sauvegardes du projet.
Une exécution: Une archive réalisée, sur disque ou dans un bucket, produite par la planification ou par Sauvegarder maintenant. C’est elle qu’on restaure, vérifie, exporte ou supprime.

Modifier une définition change ce que capturera la prochaine exécution. Cela ne réécrit jamais une archive existante — une ancienne sauvegarde reste exactement ce qu’elle était au moment où elle a été prise.

Ce qui y entre

Une sauvegarde porte soit sur un projet, soit sur un serveur entier, et quatre interrupteurs indépendants décident de ce qu’elle capture :

Interrupteur	Capture
Applications	Le répertoire de données de chaque application sur l’hôte.
Bases de données	Un dump logique par base gérée — `pg_dump`, `mysqldump`, `mongodump`, ou l’équivalent du moteur.
Volumes	Les volumes Docker nommés, un tar par volume.
Instances Linux	Les `/root`, `/home` et `/data` de chaque instance. Son propre interrupteur, parce qu’une instance est une machine entière et peut peser un ordre de grandeur de plus que le répertoire d’une application.

Une sauvegarde limitée à un projet ne capture que ce projet. Une sauvegarde de serveur capture tous les projets de la machine — utile pour un instantané d’exploitant, à proscrire comme réglage par défaut par locataire.

Planification

Une définition accepte @hourly, @daily, @weekly, ou une expression cron de la forme <minute> <heure> * * * :

TEXT

@daily
@weekly
30 4 * * *

Volontairement plus étroit que le cron complet. Une sauvegarde qui part chaque minute n’est pas une politique de sauvegarde, c’est une façon de remplir un disque — la grammaire n’exprime donc que les cadences quotidiennes qu’une sauvegarde souhaite réellement.

Les exécutions sont limitées en largeur : quelques-unes tournent à la fois, les autres attendent leur tour. Une sauvegarde en file n’est pas une sauvegarde échouée, et laisser vingt dumps se disputer le même disque les rend tous lents.

Combien sont conservées

Une planification qui ne supprime jamais rien remplit un disque à échéance fixe. Trois limites indépendantes décident de ce qui survit, chacune réglable par projet et retombant sur la valeur par défaut de la plateforme si elle est laissée vide :

Limite	Porte sur	Désactivée si
Garder les N dernières	Les exécutions d’une planification. Les plus anciennes sont supprimées une fois les N plus récentes en place.	0
Âge en jours	Les sauvegardes terminées plus anciennes que la fenêtre, quelle que soit leur origine. Plafonné à 3650.	0
Maximum par projet	Toutes les sauvegardes détenues par le projet, manuelles et planifiées confondues — un plafond, non un balayage.	0

Les deux premières suppriment des archives ; la troisième refuse d’en créer une. Atteindre le plafond par projet fait passer une exécution planifiée son tour avec un avertissement, plutôt que d’écarter silencieusement une ancienne sauvegarde pour faire de la place — le panneau ne décidera pas à votre place quelle archive est perdable. Les définitions n’y sont jamais comptées.

Une exécution échouée est conservée, non balayée : la purge par âge ne touche que les sauvegardes terminées. C’est délibéré — une ligne disant *ceci a échoué, voici pourquoi* est la seule trace qu’il vous reste que la planification a tourné, et elle ne retient aucune donnée à récupérer.

À distinguer de l’historique que le panneau garde sur lui-même — métriques, déploiements, journal d’audit. Ceux-là sont des lignes en base ; celles-ci sont des archives sur un disque.

Où elle atterrit

Local: Un fichier dans le répertoire de sauvegarde de la plateforme, en 0700. Pratique, mais inutile face à la panne où c’est l’hôte lui-même qui disparaît.
S3, R2 ou B2: N’importe quel bucket compatible S3, configuré par projet. C’est celui qui survit à la perte du serveur.

Une sauvegarde distante fige les coordonnées exactes du bucket où elle a été écrite, chiffrées, au moment où elle se termine. Modifier ou supprimer plus tard la configuration de stockage du projet ne redirige donc jamais une archive existante vers le mauvais bucket — ce qui la rendrait irrestaurable et orphelinerait l’objet réel.

Configurez le bucket, puis utilisez Tester le stockage — il liste le bucket avec les identifiants enregistrés. Découvrir une faute de frappe la nuit où la planification se déclenche est la manière coûteuse de la trouver.

Chiffrement et intégrité

Les archives sont chiffrées AES-256-GCM au repos avec la clé de sauvegarde de l’installation, distincte de l’accès à la base.
Un sha256 du fichier final est enregistré à l’écriture et revérifié avant chaque restauration. Un écart refuse la restauration plutôt que de rejouer une archive corrompue ou altérée sur des données vivantes.
Lire les sauvegardes exige backups:view ; les créer backups:create ; restaurer et exporter backups:restore. La restauration a sa propre permission parce qu’elle écrase.

Prouver qu’une sauvegarde est restaurable

Vérifier rejoue chaque dump de base de l’archive dans un conteneur jetable, attend que ce conteneur accepte les connexions, puis compte les objets qu’il contient. Ensuite le conteneur est détruit. Les données vivantes ne sont jamais touchées.

Une sauvegarde non testée est une hypothèse. Un dump peut être écrit, chiffré, haché, externalisé, et se rejouer dans le vide — base vide, dump tronqué, version de moteur qui refuse de le lire. On l’apprend soit un mardi après-midi avec un conteneur jetable, soit à 3 h du matin avec la production disparue.

La même sonde de disponibilité et le même comptage d’objets s’exécutent à la fin d’une vraie restauration : « prêt » signifie donc la même chose des deux côtés. Une restauration qui se rejoue proprement dans une base injoignable renvoie un avertissement plutôt qu’une coche verte — la pire chose que cette fonctionnalité puisse dire est « Restauration terminée » sur une base à l’arrêt, parce qu’alors on cesse de chercher.

Restaurer

Une restauration prend une exécution COMPLETED et la rejoue. Vous pouvez la restreindre à des applications, bases ou volumes précis plutôt que de rejouer toute l’archive — utile quand une seule base a été perdue et que le reste du projet va bien.

Une restauration écrase. Les données actuellement présentes dans les bases et volumes ciblés sont remplacées par le contenu de l’archive. Il n’y a pas d’annulation, et l’état précédent n’est conservé nulle part sauf si vous l’avez sauvegardé au préalable.

Avant une restauration dont vous n’êtes pas parfaitement sûr, prenez une sauvegarde fraîche de l’état courant. Cela coûte quelques minutes et c’est la seule chose qui sépare « on a restauré le mauvais jour » d’une perte définitive.

Emporter une sauvegarde ailleurs

Exporter produit un .dcbak — une copie portable d’une sauvegarde réalisée, chiffrée avec une phrase secrète que vous choisissez plutôt qu’avec la clé de l’installation. C’est ce qui la rend lisible par une autre installation DockBoard :

01Exportez l’exécution en choisissant une phrase secrète. Conservez-la ailleurs qu’à côté du fichier.
02Sur l’installation cible, Importez le .dcbak en fournissant la même phrase secrète et le serveur de destination.
03L’import restaure immédiatement — c’est une restauration, avec toutes les conséquences d’une restauration.

Perdez la phrase secrète et l’archive est illisible. Personne ne peut la récupérer — c’est précisément cette propriété qui rend son stockage hors site acceptable.

L’import accepte aussi une archive brute au repos de cette même installation, sans phrase secrète. C’est la forme reprise après sinistre : vous avez le fichier et la clé de cette installation, rien d’autre — exiger une phrase secrète qu’il n’a jamais eue refuserait justement la restauration pour laquelle ce fichier existe.

Sauvegarder DockBoard lui-même

Tout ce qui précède sauvegarde vos données. La base de la plateforme elle-même — quels projets existent, quels serveurs, quels identifiants — se sauvegarde à part, depuis Admin → Sauvegardes :

Dump du plan de contrôle: Un dump logique quotidien de la base de la plateforme. Petit — schéma et lignes, pas de blobs — donc quinze jours d’historique ne coûtent presque rien et couvrent une corruption remarquée tardivement.
Restauration à un instant donné: Une sauvegarde physique de base hebdomadaire plus l’archivage WAL. Ensemble, ils restaurent n’importe quel instant intermédiaire. Isolément, ni l’un ni l’autre ne restaure quoi que ce soit d’utile — d’où la page d’état qui rapporte les deux, séparément.

Ces dumps se déchiffrent en tous les identifiants de la plateforme : ils sont donc protégés par une autorité de flotte entière (servers:manage) et restent inaccessibles à un membre de projet comme à une clé API. Traitez le fichier téléchargé avec le même soin que la base de la plateforme elle-même.