Vérification de restauration de sauvegarde

Un backup qui se termine sans erreur n'est pas la même chose qu'un backup que vous pouvez réellement restaurer. La seule vraie preuve, c'est de le restaurer. Databasus le fait pour vous, selon un planning :

• il prend le dernier backup
• il le restaure dans un conteneur de base de données jetable
• il compare la base restaurée à la source
• il détruit le conteneur
• il rapporte le résultat

Qu'est-ce qu'un agent de vérification ?

L'agent de vérification est un petit binaire Go que vous lancez sur une machine que vous contrôlez : tout ce qui a du CPU, de la RAM et du disque disponibles convient. L'agent s'enregistre auprès de Databasus, récupère les tâches de vérification depuis une file d'attente, les exécute localement et renvoie les résultats.

Ce dont vous avez besoin

• Un hôte avec un accès HTTPS sortant vers votre URL Databasus.
• Docker disponible sur cet hôte : l'agent démarre pour chaque tâche des conteneurs de base de données éphémères de la version majeure correspondante.
• De la capacité disque pour chaque tâche de vérification couvrant la taille du fichier de backup, la taille brute de la base et une marge de sécurité en plus.
• Au moins 1 cœur CPU et 512 Mo de RAM disponibles par tâche simultanée.

Pourquoi pas de simples checksums ?

Les checksums et les codes de sortie détectent certains modes de défaillance mais en ratent d'autres complètement :

• Les checksums détectent la corruption de bits du fichier d'archive, mais ne disent rien sur le fait que le dump lui-même soit complet ou sémantiquement valide.
• Le code de sortie du dump dit que la commande de dump s'est exécutée. Il ne détecte pas un rôle sans permission de lecture sur certains objets, une extension manquante sur la source ou une incohérence de tablespace, autant de causes d'objets silencieusement ignorés ou tronqués.
• La vérification de restauration fait réellement passer l'archive par l'outil de restauration natif de la base et compte les lignes par table. C'est le seul contrôle qui détecte tout ce qui précède : si un backup ne se restaure pas, vous le découvrez avant d'en avoir besoin, pas pendant un sinistre.

Configuration

Créer un agent dans l'interface

Ouvrez Settings → Verification agents et cliquez sur Create verification agent. Choisissez un nom parlant comme staging-verifier ou eu-west-host-1. La boîte de dialogue suivante affiche le jeton et l'ID de l'agent.

Le jeton n'est affiché qu'une seule fois : copiez-le avant de fermer la boîte de dialogue. Si vous le perdez plus tard, utilisez l'action Rotate token sur la ligne de l'agent pour en émettre un nouveau ; l'ancien jeton cesse de fonctionner au heartbeat suivant de l'agent. La boîte de dialogue qui suit montre les commandes d'installation pour l'architecture de votre serveur, les mêmes commandes que celles décrites ci-dessous.

Lancer l'agent sur votre serveur

Connectez-vous en SSH à la machine qui exécutera les vérifications. Téléchargez d'abord le binaire de l'agent. Remplacez https://your-databasus-host par votre propre URL Databasus, et remplacez amd64 par arm64 si votre serveur est en ARM :

curl -L -o verification-agent "https://your-databasus-host/api/v1/system/verification-agent?arch=amd64" \
  && chmod +x verification-agent

Puis lancez l'agent. L'ID de l'agent et le jeton proviennent de la boîte de dialogue de l'étape précédente :

./verification-agent start \
  --databasus-host=https://your-databasus-host \
  --agent-id=<AGENT_ID> \
  --token=<TOKEN> \
  --max-cpu=2 \
  --max-ram-mb=2048 \
  --max-disk-gb=20 \
  --max-concurrent-jobs=1

start lance l'agent en démon et écrit ses options dans databasus-verification.json dans le répertoire de travail, si bien que les redémarrages suivants peuvent utiliser ./verification-agent start sans aucune option. Les logs sont écrits dans databasus-verification.log à côté du binaire.

Les quatre options --max-* sont des budgets, pas des allocations par tâche. L'agent les rapporte à Databasus à chaque heartbeat, et Databasus les répartit entre les tâches simultanées que vous autorisez. Avec --max-cpu=2 --max-ram-mb=2048 --max-concurrent-jobs=1 l'unique tâche obtient les 2 CPU et les 2 Go de RAM. Avec --max-concurrent-jobs=2, chaque tâche obtient 1 CPU et 1 Go. Le plancher est de 1 CPU et 512 Mo par tâche : si votre budget ne peut pas le satisfaire, l'agent annonce une concurrence plus basse. Le budget disque est le plus facile à rater : chaque tâche a besoin d'assez d'espace pour la taille du fichier de backup, la taille brute de la base et une marge de sécurité pouvant atteindre 5 Go en plus, donc réglez --max-disk-gb confortablement au-dessus de ce total pour votre plus grosse base.

Gérer l'agent

Le même binaire fournit quatre sous-commandes :

• ./verification-agent status — indique si le démon tourne et sur quelles tâches il travaille actuellement.
• ./verification-agent stop — arrête le démon. Les vérifications en cours sont rapportées à Databasus comme échouées et remises en file d'attente.
• ./verification-agent start — relance le démon. Les options sont mémorisées depuis le premier lancement ; passez --token=<NEW> après une rotation pour mettre à jour le jeton enregistré.
• ./verification-agent run — exécute au premier plan plutôt qu'en démon. Utilisez cette commande pour encapsuler l'agent dans une unité systemd ou un conteneur Docker : ces superviseurs s'attendent à ce que le processus reste au premier plan.

La page Settings affiche trois actions sur chaque ligne d'agent : revoir les commandes d'installation (sans révéler le jeton), effectuer une rotation du jeton et supprimer l'agent. La suppression est sûre : les vérifications actuellement assignées à cet agent retournent dans la file et sont reprises par un autre agent s'il y en a un de disponible.

Planification et notifications

La vérification de restauration se configure par base de données. Ouvrez les paramètres de vérification de la base, activez Scheduled verification, puis choisissez un intervalle.

Options d'intervalle

• After backup — la garantie la plus forte : chaque backup réussi est vérifié dès qu'il se termine.
• Hourly, daily, weekly, monthly — choisissez une cadence et une heure de la journée.
• Cron — une expression cron en UTC pour tout ce que les préréglages ne couvrent pas. Exemples : 0 4 * * 0 (chaque dimanche à 4 h 00 UTC) et 0 */6 * * * (toutes les six heures).

Comment la file gère "After backup"

Une vérification est généralement plus lente que le backup qui l'a produite, donc si les backups arrivent plus vite que les vérifications ne se terminent, la file grandirait sans fin. Databasus l'évite en annulant toute vérification en attente pour la même base dès qu'un nouveau backup arrive : seul le backup le plus récent attend son tour. Ce compromis est voulu : mieux vaut sauter la vérification d'un backup obsolète que passer des heures à vérifier quelque chose que vous ne restaureriez de toute façon jamais.

Exécutions manuelles

Vous pouvez aussi déclencher une vérification ponctuelle depuis l'onglet Restore verifications de la base, sans modifier la planification. Utile pour contrôler un backup précis ou tester un nouvel agent de bout en bout avant de lui confier la charge planifiée.

Notifications

Les succès et les échecs peuvent être envoyés via n'importe quel notificateur déjà relié à la base. Les deux cases à cocher, Verification success et Verification failed, sont indépendantes. La plupart des équipes n'activent que celle des échecs pour ne pas crouler sous les notifications. Consultez la documentation des notificateurs pour connecter Slack, Microsoft Teams, Discord, l'email et d'autres.

Lire les résultats

Chaque tentative de vérification apparaît comme une ligne dans l'onglet Restore verifications de la base. Le statut est Pending, Running, Successful, Failed ou Canceled. Cliquer sur une ligne ouvre un panneau avec la chronologie complète, le code de sortie de la restauration, la taille de la base restaurée, le nombre de schémas et de tables, et le détail du nombre de lignes par table. Les exécutions échouées affichent le message d'erreur en haut du panneau.