Guide de migration de Borg Backup pour déplacer un dépôt vers un nouveau stockage

L’approche sûre consiste à traiter la mise en pause des écritures, la copie ou le transfert selon la méthode adaptée à la version, la vérification de la destination et la bascule avec possibilité de retour arrière comme une séquence de contrôles observables, et non comme une seule commande.

Pour un dépôt BorgBackup sur un stockage local, un NAS ou un stockage accessible via SSH, le risque pratique est de devoir déplacer un dépôt Borg sans créer de copie fragmentée ou silencieusement incomplète. Enregistrez l’identité actuelle et le point de récupération, commencez par le critère le moins intrusif, interprétez les résultats de réussite et d’échec avant de modifier une autre variable, et arrêtez-vous si le stockage devient instable ou si la seule copie récupérable risque d’être exposée. Le flux de travail ci-dessous ne se termine qu’une fois que la charge de travail d’origine fonctionne ou que les éléments disponibles atteignent un seuil nécessitant une escalade.

Consignez les paramètres du dépôt avant la copie

Enregistrez la version de Borg, l’URL du dépôt, l’identifiant du dépôt, le mode de chiffrement, l’emplacement de la clé, le processus de récupération de la phrase secrète, la liste des archives, la taille, l’espace libre, les paramètres append-only, ainsi que chaque client ou tâche automatisée susceptible d’écrire. Le dépôt ne peut pas être récupéré à partir du seul cache local, et les dépôts chiffrés peuvent dépendre de clés stockées en dehors de la destination.

L’article de ZimaSpace sur un guide de récupération après la perte du cache Borg distingue l’état du cache, qui peut être reconstruit, des clés manquantes ou des dommages au dépôt. Effectuez cette vérification avant la migration afin de ne pas découvrir un problème de clé seulement après la disparition de l’ancien stockage.

Déterminez s’il s’agit d’une relocalisation octet par octet du même dépôt ou d’un transfert vers un dépôt nouvellement initialisé. La version et le format de Borg déterminent les méthodes disponibles ; ne mélangez pas les exemples de commandes Borg 1 et Borg 2 et ne supposez pas que l’identité du dépôt doit changer.

Mettez les écritures en pause et créez un point source cohérent

Désactivez les minuteurs, les tâches cron, les conteneurs et les clients distants, puis vérifiez qu’aucun processus Borg ni verrou de dépôt n’est actif. Exécutez borg list et une commande borg check appropriée avant la copie. Si la vérification de la source échoue, préservez-la et diagnostiquez cette situation au lieu de cloner l’incertitude vers la destination.

Une discussion sur Super User souligne le risque de copier un dépôt actif avec rsync pendant la modification d’un dépôt Borg dédupliqué. La règle sûre consiste à copier un dépôt dont les écritures sont suspendues, ou à utiliser un instantané du système de fichiers créé après l’arrêt de toutes les écritures Borg, afin que les index, segments, états des nonces et données correspondent à un même point dans le temps.

Laissez les planifications de sauvegarde désactivées jusqu’à la fin de la validation de la destination. Si l’interruption est trop longue, effectuez une copie initiale lorsque le dépôt est inactif, arrêtez les écritures, puis exécutez une synchronisation finale ; n’autorisez jamais la source et la destination à accepter des sauvegardes indépendantes pendant la bascule.

Copiez avec la méthode prise en charge par votre version de Borg

Pour une relocalisation du même dépôt, préservez tous les fichiers, les permissions, le comportement des fichiers creux et les propriétaires avec un outil de copie local ou distant adapté, puis examinez son journal d’erreurs. Copiez la racine du dépôt comme une unité, et non certaines archives ou certains répertoires de données apparemment volumineux. Ne modifiez plus la source après la synchronisation finale.

Pour un nouveau dépôt ou une migration de format, utilisez la fonctionnalité de transfert uniquement si elle est prise en charge par les versions de Borg installées et le plan de chiffrement. Une réponse sur Server Fault décrit le transfert de dépôt Borg comme le mode de transfert d’un dépôt à un autre associé à Borg 2, qui ne peut pas être assimilé à une copie du système de fichiers avec Borg 1.

Après la copie, montez ou exposez d’abord la destination en lecture seule aux clients. Si l’identifiant du dépôt, l’accès à la clé, les permissions ou le format sont inattendus, arrêtez-vous et corrigez la destination ; ne l’« initialisez » pas par-dessus les données copiées et n’exécutez pas de réparation pour forcer sa reconnaissance.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vérifiez les archives, basculez les clients et conservez une possibilité de retour arrière

Exécutez Borg list, info ainsi que les vérifications appropriées du dépôt et des archives sur la destination. Extrayez des fichiers témoins d’une archive récente et d’une archive plus ancienne vers un répertoire distinct, puis comparez leur contenu, leurs métadonnées et leurs permissions. Effectuez le test avec le même binaire Borg et le même chemin distant que ceux utilisés par l’automatisation.

Mettez à jour un client vers la nouvelle URL, puis effacez ou reconstruisez uniquement l’état du cache que Borg indique comme nécessaire, et créez une petite archive de test. Restaurez cette archive et vérifiez que la planification de l’élagage ou du compactage reste désactivée jusqu’à ce que tous les clients utilisent le nouvel emplacement.

La bascule est validée lorsque l’inventaire des archives correspond, que les vérifications réussissent, que deux restaurations sont utilisables et qu’une nouvelle sauvegarde réussit après un redémarrage ou le redémarrage du planificateur. Conservez la source en lecture seule pendant au moins un cycle normal ; supprimez-la uniquement après l’expiration du délai de retour arrière, ou déclenchez une escalade si les vérifications diffèrent entre la source et la destination.