Un PBS plein, un serveur en fin de vie, un changement d'hébergeur : tôt ou tard, un datastore doit déménager. Le sync job sait le faire, en remplissant un nouveau datastore. Quand le datastore est sur ZFS, on peut déplacer le datastore lui-même, à chaud, et ne suspendre les sauvegardes que le temps d'un dernier incrémental.
C'est le même mécanisme que notre copie hors ligne par zfs send, et c'est ainsi que nous déplaçons un datastore d'un serveur à l'autre : à l'arrivée, le Proxmox VE relit et déchiffre ses sauvegardes sur le nouveau serveur avec le même compte, le même mot de passe et la même clé.
Ce qui voyage avec le dataset, et ce qui reste derrière
Voyage avec zfs send | Reste sur l'ancien serveur, dans /etc/proxmox-backup/ |
|---|---|
| les chunks et les index les groupes, snapshots et namespaces le propriétaire de chaque groupe l'état de vérification des snapshots | la déclaration du datastore — datastore.cfgles comptes — user.cfg, shadow.json, token.shadowles droits — acl.cfgles jobs — prune.cfg, verification.cfg, sync.cfgle certificat — proxy.pem, proxy.key |
Bonne nouvelle pour la colonne de droite : un PBS fraîchement installé n'a ni datastore.cfg, ni acl.cfg, ni token.shadow, ni fichiers de jobs. Ils naissent à l'usage. Sur la cible, il n'y a donc rien à fusionner avec l'existant : seulement ce que vous avez créé sur la source à reprendre.
Prérequis
- ZFS des deux côtés, le datastore source étant un dataset à lui seul ;
- la même version majeure de PBS, la cible au moins aussi récente de préférence ;
- le même nom de datastore sur la cible : c'est ce nom que référencent les Proxmox VE ;
- un accès SSH par clé de la cible vers la source — le même montage que pour la copie hors ligne.
Étape 1 — L'inventaire, avant de toucher à quoi que ce soit
proxmox-backup-manager version --verbose
proxmox-backup-manager datastore show clientX
zfs list -o name,used,avail,recordsize,atime,mountpoint rpool/datastores/clientX
proxmox-backup-manager user list
proxmox-backup-manager acl list
proxmox-backup-manager prune-job list
proxmox-backup-manager verify-job list
proxmox-backup-manager sync-job list
proxmox-backup-manager cert info # l'empreinte que les Proxmox VE ont épinglée
ls -l /etc/proxmox-backup/C'est cette liste qui dira, à la fin, si rien n'a été oublié. Sur la cible, préparez le parent qui recevra le dataset :
zfs create -o mountpoint=/mnt/datastore tank/datastoresÉtapes 2 et 3 — Copie complète puis incrémentaux, à chaud
Les sauvegardes continuent sur l'ancien serveur pendant toute cette phase. Le datastore n'est pas encore déclaré sur la cible : aucun garbage collector, aucun prune ne peut y toucher.
La copie complète, puis autant d'incrémentaux qu'il le faut — chacun plus court que le précédent —, se font exactement comme pour une copie hors ligne : snapshot et bookmark côté ancien serveur, zfs send -L -c puis zfs send -L -c -i depuis le bookmark, reçus avec zfs receive -s -u (et -x mountpoint au premier envoi). Les commandes et les options sont détaillées dans Mettre un datastore PBS hors ligne avec zfs send, étapes 3 et 5 ; la cible est simplement le nouveau PBS au lieu d'un disque.
Dans la suite, les snapshots s'appellent migration-1, migration-2… et le dataset reçu tank/datastores/clientX.
Étape 4 — La bascule
À placer hors de la fenêtre de sauvegarde : pendant la bascule, une sauvegarde lancée vers l'ancien serveur échouera, et c'est voulu.
proxmox-backup-manager datastore update clientX --maintenance-mode type=read-only
proxmox-backup-manager task list # attendre qu'aucune sauvegarde ne soit encore en cours
zfs snapshot rpool/datastores/clientX@migration-final
zfs bookmark rpool/datastores/clientX@migration-2 rpool/datastores/clientX#migration-2Le mode maintenance n'arrête pas ce qui tourne déjà
PBS bloque les nouvelles écritures, mais laisse finir les opérations commencées avant l'activation du mode. Un snapshot pris juste après la commande peut donc contenir une sauvegarde à moitié écrite. Attendez la fin des tâches, puis seulement prenez le snapshot final. En read-only, les restaurations restent possibles pendant toute la bascule.
set -o pipefail
ssh ancien-pbs zfs send -L -c -i rpool/datastores/clientX#migration-2 rpool/datastores/clientX@migration-final \
| zfs receive -s -u tank/datastores/clientX
echo "PIPESTATUS=${PIPESTATUS[*]}"
zfs mount tank/datastores/clientX # reçu avec -u : il n'est pas monté
proxmox-backup-manager datastore create clientX /mnt/datastore/clientX --reuse-datastore trueAttendu : Access time update check successful. puis TASK OK. Sans le zfs mount, le point de montage n'existe pas encore et datastore create tombe sur un répertoire vide : la copie n'est pas perdue, elle n'est simplement pas montée.
Étape 5 — Comptes, mots de passe, jetons et droits
Le propriétaire de chaque groupe est arrivé avec le datastore ; le compte qui porte ce nom, non. Tant qu'il n'existe pas sur la cible, le client ne voit rien. Et l'objectif est qu'il n'ait rien à changer : ni mot de passe, ni jeton.
Le mot de passe en clair n'est jamais nécessaire. On transporte ce que PBS stocke déjà : le hash du mot de passe et le secret haché des jetons. Personne n'a besoin de connaître le mot de passe pour faire la migration.
Tout le serveur déménage
Le nouveau PBS remplace l'ancien : on reprend les fichiers entiers, après avoir sauvegardé ceux de la cible.
cd /etc/proxmox-backup
mkdir -p /root/avant-migration && cp -a user.cfg shadow.json /root/avant-migration/
# depuis l'ancien PBS, en conservant propriétaire et permissions
# user.cfg shadow.json token.shadow acl.cfg
# (+ domains.cfg et tfa.json si vous utilisez LDAP/AD ou la double authentification)
proxmox-backup-manager user list
proxmox-backup-manager acl listUn datastore parmi d'autres déménage
Si l'ancien et le nouveau serveur hébergent d'autres comptes, on ne copie jamais les fichiers entiers : ils contiennent les comptes de tout le monde. On reporte quatre fragments, ceux du seul compte concerné :
user.cfg → la section "user: client@pbs" et ses lignes
(et ses sections "token: client@pbs!<id>", s'il en a)
shadow.json → l'entrée "client" ← SANS le suffixe @pbs
token.shadow → l'entrée "client@pbs!<id>", s'il y a des jetons
acl.cfg → la ligne "acl:1:/datastore/clientX:client@pbs:DatastoreBackup"Deux pièges qui coûtent cher
shadow.json s'indexe sans le royaume. L'entrée s'appelle client, pas client@pbs. La chercher avec le suffixe répond « absent » alors qu'elle existe.
user.cfg est un fichier à sections, et une section sans propriété doit être suivie d'une ligne vide. Une section token: créée par generate-token n'a souvent aucune propriété. Collez une section juste derrière, et PBS répond syntax error — puis rejette le fichier entier : plus aucun utilisateur, plus aucune ACL, y compris pour les comptes qui fonctionnaient. Sauvegardez avant d'éditer, et relisez avec proxmox-backup-manager user list immédiatement après.
Étape 6 — Les jobs
Prune, verify, sync, notifications : rien de tout cela n'a suivi. Leur absence ne gêne aucune restauration, mais un datastore sans prune se remplit en silence — d'autant plus vite que les clients, s'ils sont en écriture seule, ne peuvent pas élaguer eux-mêmes. Recréez-les d'après l'inventaire de l'étape 1, et laissez le garbage collector de côté jusqu'à l'étape 8.
Étape 7 — Ce que voit Proxmox VE : le nom et l'empreinte
Proxmox VE épingle l'empreinte du certificat du PBS dans /etc/pve/storage.cfg. Un nouveau serveur a un nouveau certificat : c'est le point qui décide si la migration est invisible.
| Situation | Ce que voit Proxmox VE | À faire côté PVE |
|---|---|---|
| un frontal (reverse proxy) termine le TLS devant les PBS | le certificat du frontal, inchangé | rien |
le certificat de l'ancien PBS est repris sur le nouveau (proxy.pem + proxy.key, puis redémarrage de proxmox-backup-proxy) | le même certificat, donc la même empreinte | rien, hormis l'adresse si elle change |
| nouveau certificat, ou frontal en simple passe-plat TLS | le certificat du nouveau PBS | pvesm set <stockage> --fingerprint <empreinte> sur chaque PVE |
Le nom : basculer le DNS, ou changer l'adresse
Si les Proxmox VE visent un nom DNS, on fait pointer ce nom vers le nouveau serveur, et la configuration des stockages ne change pas. Une fois le DNS propagé, il suffit de déconnecter puis reconnecter le datastore côté Proxmox VE pour qu'il rejoigne le nouveau serveur — dans l'interface (Datacenter → Stockage → désactiver, puis réactiver) ou en ligne de commande :
pvesm set backup --disable 1
pvesm set backup --disable 0
pvesm status --storage backupSinon, on change l'adresse : pvesm set <stockage> --server <nouveau>. Dans les deux cas, l'empreinte suit les règles du tableau ci-dessus. Au bout du compte, l'entrée du stockage ne diffère au plus que par sa ligne server — et avec un DNS basculé, même celle-là ne bouge pas :
pbs: backup pbs: backup
datastore clientX datastore clientX ← identique
server pbs.example.com server pbs.example.com ← identique si le DNS bascule
fingerprint <empreinte> fingerprint <empreinte> ← selon le cas ci-dessus
username client@pbs username client@pbs ← identique
encryption-key <empreinte de la clé> encryption-key <empreinte> ← identiqueLa clé de chiffrement client, elle, ne bouge pas : elle vit côté Proxmox VE, dans /etc/pve/priv/storage/<stockage>.enc, et le nouveau PBS ne la voit pas plus que l'ancien. Déclarer un second stockage plutôt que modifier le premier est aussi possible : c'est ce que décrit la réactivation d'un datastore.
Étape 8 — Prouver que ça marche, avant de décommissionner
Avant de décommissionner l'ancien serveur, il faut la preuve qu'on restaure depuis le nouveau : verify forcé, extraction d'une configuration de VM qui met la clé de chiffrement en jeu, puis une vraie restauration vers un identifiant neuf. Ces contrôles sont détaillés, commandes comprises, dans Réactiver un datastore PBS après la perte du serveur (étapes 3 et 6). Côté migration, seul l'ordre compte :
- les preuves : verify forcé, extraction de configuration, restauration ;
- seulement ensuite, le premier garbage collector sur le nouveau datastore ;
- les jobs réactivés, une nuit de sauvegardes réussies, et alors seulement le décommissionnement de l'ancien serveur.
Le retour arrière
Tant que l'ancien serveur existe, il suffit de lever le mode maintenance — proxmox-backup-manager datastore update clientX --delete maintenance-mode — et de remettre les Proxmox VE sur l'ancienne adresse. Rien n'a été détruit côté source : des snapshots et des bookmarks, c'est tout.
Chez Nimbus
C'est ainsi que nous déplaçons un datastore d'un de nos serveurs à un autre. On transporte le hash du mot de passe et les jetons : vous n'avez ni nouveau mot de passe ni nouveau jeton à saisir. Le seul point qui pourrait vous concerner est l'empreinte épinglée dans votre Proxmox VE, et c'est précisément ce que nous vérifions avant de déplacer quoi que ce soit.
Questions fréquentes
Peut-on migrer un datastore PBS sans interrompre les sauvegardes ?
Presque. La copie complète et les incrémentaux se font à chaud, pendant que les sauvegardes continuent sur l'ancien serveur. L'interruption se limite à la bascule : le datastore source passe en maintenance read-only, les tâches en cours se terminent, puis un dernier incrémental, court, part vers le nouveau serveur. Pendant ce temps, les restaurations restent possibles.
Faut-il la même version de PBS sur l'ancien et le nouveau serveur ?
La même version majeure. Une cible plus récente que la source ne pose pas de problème. Dans l'autre sens, lors de notre essai, un datastore venu d'un PBS 4.2.5 relu sur un 4.2.0 n'a rien gêné, mais ce n'est pas une raison pour migrer vers plus ancien. Côté ZFS, un flux zfs send se reçoit sans difficulté sur un OpenZFS plus récent ; c'est l'import d'un disque qui demande un OpenZFS connaissant toutes les fonctionnalités actives du pool.
Les utilisateurs et les Proxmox VE doivent-ils changer de mot de passe ou de jeton ?
Non. Le mot de passe en clair n'est jamais nécessaire : on reporte le hash (shadow.json) et le secret haché des jetons (token.shadow), avec la définition des comptes (user.cfg) et leurs droits (acl.cfg). Attention, shadow.json est indexé par le nom d'utilisateur sans le royaume : la clé est « client », pas « client@pbs ».
Pourquoi Proxmox VE refuse-t-il de se connecter au nouveau PBS ?
Le plus souvent, c'est l'empreinte du certificat. Proxmox VE l'épingle dans /etc/pve/storage.cfg. Un nouveau serveur a un nouveau certificat, donc une nouvelle empreinte : soit on reprend le certificat de l'ancien serveur, soit un frontal qui termine le TLS présente toujours le même, soit on met à jour l'empreinte avec pvesm set <stockage> --fingerprint.
Sync job ou zfs send pour migrer un PBS ?
Le sync job ne demande pas ZFS et reste la voie officielle : il remplit un nouveau datastore snapshot par snapshot. Mais les groupes synchronisés prennent le propriétaire défini dans le job (root@pam par défaut), qu'il faut alors corriger pour chaque client. zfs send déplace le datastore lui-même, propriétaires, namespaces et état de vérification compris, à condition d'avoir ZFS des deux côtés.
Un PBS hors site que vous n'aurez jamais à migrer
Datastore en France, serveurs remplacés et migrés par nos soins, copie hors ligne en option. Vous gardez votre PBS local ; nous portons la copie externalisée.