Une copie hors ligne ne sert qu'une fois : le jour où il faut la relire. Le disque sort du coffre, ou le serveur qui portait le datastore n'est plus là, et le datastore doit repartir sur un PBS qui ne l'a jamais vu.
Voici comment nous réactivons un simple datastore sur un nouveau PBS, à partir d'un dataset répliqué par zfs send — celui de notre copie hors ligne.
Ce qu'il faut réunir
| Élément | Pourquoi |
|---|---|
| le support, ou le dataset répliqué | les données : chunks, index, groupes, propriétaires |
| un PBS de même version majeure | au moins aussi récent que la source, de préférence |
| un OpenZFS qui connaît les fonctionnalités du pool | au moins aussi récent que celui qui a créé le pool, ou que le niveau de compatibility choisi à sa création — sinon zpool import refuse le disque |
| la clé du support, s'il est chiffré | sans elle, le disque n'est qu'un bloc d'octets ; elle ne voyage jamais avec lui |
| la clé de chiffrement client | PBS ne l'a jamais eue et ne peut pas la reconstituer. C'est le seul élément dont la perte est définitive. |
| un Proxmox VE | pour restaurer les VM et les conteneurs |
1. Importer le pool et monter le dataset
zpool import # liste les pools visibles, sans rien importer
zpool import airgap-A1
zfs list -r -o name,mounted,mountpoint airgap-A1
zfs mount airgap-A1/copies/clientX # reçu avec -u : il n'est pas montéSi le support est chiffré, déverrouillez-le avant le zfs mount, avec la clé qui a voyagé séparément. Si zpool import refuse le pool pour des fonctionnalités non supportées, c'est l'OpenZFS de ce serveur qui est trop ancien pour lui : mettez-le à jour, rien n'est perdu sur le disque.
Le zfs mount n'est pas facultatif. Un dataset reçu avec -u n'est pas monté, et son point de montage n'existe même pas encore. Sans lui, la déclaration du datastore tombe sur un répertoire vide — et l'on croit la copie perdue alors qu'elle est intacte.
Le disque doit-il repartir en rotation ? Alors ne déclarez pas le dataset lui-même : PBS y écrirait, et l'incrémental suivant serait refusé. Travaillez sur un clone, comme pour le contrôle avant le coffre.
2. Déclarer le datastore, sans toucher au contenu
proxmox-backup-manager datastore create clientX /mnt/datastore/clientX --reuse-datastore true
proxmox-backup-manager datastore listSortie attendue : Access time update check successful. puis TASK OK. PBS vérifie au passage que l'atime fonctionne, parce que son garbage collector en dépend. Les groupes, les snapshots et leurs propriétaires sont là. Un PBS plus récent que la source ne pose pas de problème ; dans l'autre sens, lors de notre essai, un datastore venu d'un 4.2.5 relu sur un 4.2.0 n'a rien gêné.
Prenez le même nom de datastore que sur l'ancien serveur si des Proxmox VE doivent s'y reconnecter sans changer leur configuration.
3. Relire avant de restaurer
proxmox-backup-manager verify clientX --ignore-verified falsecurl -sk -X POST -H "Authorization: PBSAPIToken=<authid>:<secret>" \
-d backup-type=vm -d backup-id=<id> -d backup-time=<epoch> -d ignore-verified=0 \
"https://localhost:8007/api2/json/admin/datastore/clientX/verify"Sans ignore-verified, le verify ne lit rien
L'état de vérification a voyagé avec le dataset. Un verify ordinaire répond SKIPPED: … (recently verified) sans lire un octet. Et tant que le verify et une première restauration ne sont pas passés, pas de garbage collector sur ce datastore.
4. Donner accès
Deux situations, qui ne demandent pas la même chose.
Un PBS de secours, le temps de restaurer
Mode dégradé et temporaire : un compte neuf, en lecture seule. Le rôle DatastoreReader lit et restaure les sauvegardes de tous les propriétaires : inutile de recréer le compte d'origine. Il se pose deux fois, sur l'utilisateur et sur son jeton : les droits effectifs d'un jeton sont l'intersection des siens et de ceux de son utilisateur. Avec l'ACL sur un seul des deux, la lecture est refusée (missing Datastore.Audit|Datastore.Backup). Et laissez quelques secondes aux droits pour s'appliquer : un refus immédiatement après acl update n'est pas forcément une erreur.
proxmox-backup-manager user create restore@pbs
proxmox-backup-manager user generate-token restore@pbs pve # le secret est le champ "value"
proxmox-backup-manager acl update /datastore/clientX DatastoreReader --auth-id restore@pbs
proxmox-backup-manager acl update /datastore/clientX DatastoreReader --auth-id 'restore@pbs!pve'
proxmox-backup-manager cert info # l'empreinte à donner à Proxmox VELe datastore reprend du service pour les mêmes clients
Là, personne ne doit rien changer : on reporte les comptes, leurs mots de passe hachés, leurs jetons et leurs droits depuis l'ancien serveur. C'est exactement l'étape « comptes » d'une migration de PBS, avec ses deux pièges.
5. Déclarer le datastore dans Proxmox VE
pvesm add pbs pbs-secours \
--server <nouveau-pbs> --datastore clientX \
--username 'restore@pbs!pve' --password '<secret du jeton>' \
--fingerprint '<empreinte du certificat>' \
--encryption-key /etc/pve/priv/storage/<stockage-habituel>.enc \
--nodes <noeud> --content backup
pvesm status
pvesm list pbs-secours | wc -l- Un stockage supplémentaire, dans aucun job de sauvegarde : le PVE voit maintenant les mêmes sauvegardes deux fois, et rien ne doit écrire sur la copie par erreur ;
--encryption-keyaccepte un chemin de fichier et recopie la clé sous le nouvel identifiant de stockage. Sur un Proxmox VE neuf, pointez vers la copie de la clé que vous avez conservée ;- le
.encrecopié fait un octet de plus que l'original :pvesmajoute un saut de ligne. Ce n'est pas une autre clé — l'empreinte inscrite dansstorage.cfgfait foi.
6. Prouver qu'on restaure, puis restaurer
Lister les sauvegardes ne prouve rien : les index se parcourent sans la clé. Ce qui met le chiffrement en jeu, c'est l'extraction d'une configuration de VM :
pvesh get /nodes/<noeud>/vzdump/extractconfig --volume 'pbs-secours:backup/vm/<id>/<date>'
qmrestore pbs-secours:backup/vm/<id>/<date> <vmid-neuf> --storage local-lvm
pct restore <ctid-neuf> pbs-secours:backup/ct/<id>/<date> --storage local-lvmAttendu, pour des sauvegardes chiffrées : Using encryption key from file descriptor.. Fingerprint: …, puis la configuration de la VM en clair. Restaurez ensuite toujours vers un identifiant neuf, jamais au-dessus d'une VM existante. La restauration de fichiers se fait depuis l'interface de Proxmox VE, bouton File Restore.
Restaurer depuis le disque, ou réhydrater d'abord ?
Un disque de rotation est un plateau unique : rapide pour lire d'un bout à l'autre, lent pour des milliers de lectures éparpillées — ce qu'est une restauration. Pour une VM ou quelques fichiers, on restaure directement : on ne lit que les chunks concernés.
Pour tout remonter, on peut d'abord recopier le dataset vers un stockage rapide, en séquentiel, et déclarer le datastore là-bas :
zfs send -L -c airgap-A1/copies/clientX@<snapshot> | zfs receive -u tank/datastores/clientX
zfs mount tank/datastores/clientX
proxmox-backup-manager datastore create clientX <point de montage> --reuse-datastore trueOù se situe la bascule dépend du disque, du volume et du nombre de VM : mesurez-le sur votre matériel avant d'en avoir besoin.
Si le datastore reprend du service
Garbage collector seulement après le verify et une restauration réussie. Pour le reste — comptes reportés, jobs à recréer, empreinte TLS vue par les Proxmox VE —, c'est une migration de PBS (étapes 5 à 7).
Chez Nimbus
Avec des supports hors ligne dédiés, nous pouvons vous prêter vos disques, sous réserve de caution : cette procédure est alors celle que vous suivez sur votre propre PBS. Avec un PBS hors ligne dédié, c'est un serveur qui arrive, prêt à démarrer. Dans les deux cas, la clé du support ne voyage jamais dans le colis. Et les pools de nos supports hors ligne sont créés avec un jeu de fonctionnalités ZFS figé à l'avance, pour s'importer aussi sur un serveur moins à jour que les nôtres.
Questions fréquentes
Peut-on relire un datastore PBS sur un serveur qui n'a jamais vu l'ancien ?
Oui. Un datastore PBS contient tout ce qu'il faut pour être relu : chunks, index, groupes, snapshots et propriétaires. proxmox-backup-manager datastore create avec --reuse-datastore true le déclare sans toucher au contenu, sur n'importe quel PBS de même version majeure. Rien de l'ancien serveur n'est nécessaire pour restaurer, hormis la clé de chiffrement client si les sauvegardes sont chiffrées.
Pourquoi datastore create tombe-t-il sur un répertoire vide ?
Parce que le dataset n'est pas monté. Un dataset reçu avec zfs receive -u n'est pas monté, et son point de montage n'existe même pas encore. Un zfs mount avant la déclaration, et le contenu apparaît : la copie n'était pas perdue.
Faut-il recréer le compte propriétaire des sauvegardes pour restaurer ?
Non. Le rôle DatastoreReader sur le datastore permet de lire et de restaurer les sauvegardes de tous les propriétaires. Le compte d'origine n'est nécessaire que si le datastore doit reprendre du service pour les mêmes clients sans qu'ils changent quoi que ce soit : il faut alors reporter les comptes, comme lors d'une migration.
Que faut-il en plus du disque pour restaurer ?
Un PBS de même version majeure, la clé du support s'il est chiffré, et la clé de chiffrement client si les sauvegardes le sont. La clé client est le seul élément dont la perte est définitive : PBS ne l'a jamais eue. Côté Proxmox VE, elle se trouve dans /etc/pve/priv/storage/<stockage>.enc — une copie doit exister hors de l'infrastructure sauvegardée.
Une copie hors ligne qu'on peut vous prêter
AirGapped Drive PBS à 34 € HT/To/mois, et en option des supports dédiés — disques ou PBS hors ligne — que nous vous prêtons le jour où vous en avez besoin, sous réserve de caution. Sur devis.