Mettre un datastore PBS hors ligne avec zfs send

Deux façons de sortir un datastore PBS

PBS propose sa propre voie : un datastore amovible alimenté par un sync job. La réplication ZFS en est une autre. Elles ne copient pas la même chose.

Le sync job n'a rien d'un second choix : il ne demande pas ZFS, et transfer-last divise le volume quand la copie hors ligne n'a pas besoin de tout l'historique. Nous avons retenu ZFS parce que nos datastores y sont déjà, et que la copie est alors le datastore même : rien à reconstituer le jour où il faut le relire.

Le principe : c'est la copie qui tire

La machine qui porte le disque va chercher les données, en SSH. La production ne pousse jamais. Ce n'est pas un détail d'implémentation, c'est ce qui fait tenir le reste :

• la production ne détient aucun identifiant vers la copie, et n'a pas de route vers elle ;
• si la production est compromise, un attaquant qui y obtient root peut voir qu'une copie vient se servir — une clé autorisée, des connexions dans les journaux —, mais il n'a ni identifiant ni route pour ouvrir une connexion vers elle ;
• c'est exactement le modèle d'un support qu'on débranche — il vient se servir, puis il disparaît.

Côté pare-feu, une seule ouverture : de la copie vers la production, en SSH. Les snapshots, et leur destruction, restent décidés par la production elle-même.

1. Sur la production : une clé SSH pour la copie

La copie se connecte à la production avec une clé SSH autorisée sur la production. C'est tout ce dont le montage a besoin, et la production, elle, n'a aucune clé vers la copie. Restreignez cette clé autant que votre exploitation le permet (restrict, from=, commande forcée) : sans restriction, qui prend la main sur la machine de copie la prend aussi sur la production.

La façon dont nous gérons nos propres accès fait partie de notre exploitation : elle n'est pas détaillée ici.

Qui prend les snapshots ? La production, par son propre timer : elle garde la main sur ses snapshots. Le même timer pose un bookmark sur chaque snapshot : cela ne coûte rien, et c'est ce qui servira d'origine aux envois suivants.

S=offline-$(date -u +%Y%m%dT%H%M)
zfs snapshot rpool/datastores/clientX@$S
zfs bookmark rpool/datastores/clientX@$S rpool/datastores/clientX#$S

2. Sur la copie : préparer le disque

ls -l /dev/disk/by-id/ | grep -v part           # le disque, par son identifiant stable

zpool create -o ashift=12 -o compatibility=openzfs-2.2 -O atime=on airgap-A1 /dev/disk/by-id/<disque>
zfs create -o mountpoint=/mnt/datastore airgap-A1/copies

• /dev/disk/by-id, jamais /dev/sdX, qui change d'un branchement à l'autre ;
• compatibility=openzfs-2.2 fige les fonctionnalités du pool à celles d'OpenZFS 2.2 (ou le niveau de votre choix, cf. /usr/share/zfs/compatibility.d/). Un pool créé sur un OpenZFS plus récent peut activer des fonctionnalités qu'un OpenZFS plus ancien ne connaît pas, et zpool import refuse alors le disque : le figer d'avance, c'est garantir qu'il s'importera aussi sur un serveur moins à jour ;
• ashift=12 explicite : un pont USB ou un LUN annonce parfois des secteurs de 512 octets sur un disque qui travaille en 4 Kio ;
• atime=on : le garbage collector de PBS s'appuie sur l'atime des chunks, et PBS le contrôle à la déclaration du datastore ;
• le point de montage sur le parent : les datasets reçus atterriront directement sous /mnt/datastore/<nom>.

Un disque qui quitte la salle peut se perdre : chiffrez le support, et ne rangez jamais la clé avec le disque. Le chiffrement côté client ne dispense pas de le faire — il protège le contenu des sauvegardes, pas le support, et il reste optionnel dans PBS.

3. La première copie

set -o pipefail
SRC=rpool/datastores/clientX
PROD="-i /root/.ssh/id_ed25519_copie pbs-production"

ssh $PROD zfs list -t snapshot,bookmark -o name,creation -r $SRC    # ce qui est disponible
ssh $PROD zfs send -nP -L -c $SRC@offline-20260914T0700                # volume estimé, rien n'est transféré

ssh $PROD zfs send -L -c $SRC@offline-20260914T0700 \
  | pv -L 20m \
  | zfs receive -s -u -x mountpoint airgap-A1/copies/clientX
echo "PIPESTATUS=${PIPESTATUS[*]}"                                  # trois 0, sinon rien n'est acquis

• send -L -c envoie les blocs tels qu'ils sont compressés sur disque, sans les décompresser ni redécouper ceux de plus de 128 Kio ;
• receive -s rend la réception reprenable : si la liaison tombe, on repart où l'on s'était arrêté au lieu de tout recommencer ;
• -u : le dataset reçu n'est pas monté ;
• -x mountpoint : le dataset reçu prend le point de montage de son parent local, même si le flux transporte des propriétés (envoi avec -p ou -R) ;
• pv -L plafonne le débit, pour ne pas manger la ligne pendant les sauvegardes ;
• PIPESTATUS : trois commandes, trois codes de retour. Un seul regard sur le dernier ne suffit pas.

TOKEN=$(zfs get -H -o value receive_resume_token airgap-A1/copies/clientX)
ssh $PROD zfs send -t $TOKEN | pv -L 20m | zfs receive -s -u airgap-A1/copies/clientX

Ne vous fiez pas aux premières minutes : l'envoi commence par parcourir les métadonnées de millions de chunks, cache froid, et démarre lentement avant de trouver son régime.

4. Vérifier la copie avant qu'elle parte au coffre

On ne déclare jamais le dataset reçu lui-même dans PBS pour un contrôle de routine : un datastore en service écrit (verrous, atime), le dataset diverge, et l'incrémental suivant est refusé. On relit un clone jetable — ce qui suppose que PBS soit installé sur la machine qui porte les disques, ZFS seul ne suffit pas :

zfs clone -o readonly=off -o mountpoint=/mnt/controle \
  airgap-A1/copies/clientX@offline-20260914T0700 airgap-A1/controle

proxmox-backup-manager datastore create controle /mnt/controle --reuse-datastore true
proxmox-backup-manager verify controle --ignore-verified false

proxmox-backup-manager datastore remove controle   # retire la déclaration, pas les données
zfs destroy airgap-A1/controle
zpool status airgap-A1                             # 0 erreur

5. Au retour d'un disque : l'incrémental

Chaque disque revient avec un retard différent, donc repart de son dernier envoi. Le dernier snapshot présent sur le disque porte le même nom qu'un bookmark côté production : c'est l'origine de l'incrémental.

zpool import airgap-A1
zfs list -t snapshot -o name airgap-A1/copies/clientX       # dernier snapshot reçu par CE disque

ssh $PROD zfs send -nP -L -c -i $SRC#offline-20260829T0700 $SRC@offline-20260914T0700   # volume du delta
ssh $PROD zfs send -L -c -i $SRC#offline-20260829T0700 $SRC@offline-20260914T0700 \
  | pv -L 20m | zfs receive -s -u airgap-A1/copies/clientX
echo "PIPESTATUS=${PIPESTATUS[*]}"

Les options qui comptent pour un incrémental

• si zfs receive refuse parce que la destination a été modifiée, quelqu'un a écrit sur le dataset reçu — le plus souvent en le montant ;
• si le bookmark a disparu côté production, il n'y a plus de point commun : on repart sur une copie complète ;
• -x mountpoint ne sert qu'au premier envoi, qui crée le dataset ;
• sur le disque, seul le dernier snapshot reçu sert au prochain incrémental. Les précédents retiennent des blocs que PBS a libérés depuis.

6. Débrancher

zpool export airgap-A1        # toujours avant de débrancher, jamais après

Si le disque est en USB, quatre vérifications, une fois par modèle de boîtier :

• UAS ou BOT (lsusb -t, chercher Driver=uas). En mode usb-storage, une commande à la fois : le débit plafonne. Si c'est le noyau qui a désactivé UAS pour ce pont, il a ses raisons — changez de boîtier plutôt que de forcer ;
• SMART à travers le pont : smartctl -a -d sat. Si aucun -d ne passe, ce boîtier ne permet pas de surveiller le disque ;
• le numéro de série vu dans /dev/disk/by-id est parfois celui du pont, identique pour tous les disques. Fiez-vous au nom du pool, que ZFS lit sur le disque lui-même ;
• un boîtier alimenté pour un 3,5 pouces. Une déconnexion en pleine écriture suspend le pool : zpool clear, puis reprise au jeton.

Ce que cette copie apporte, et ce qu'elle n'apporte pas

• Débranché, le disque est hors d'atteinte : un ransomware ne chiffre ni n'efface un support connecté à rien ;
• une production compromise ne mène pas à la copie : la copie tire, et la production n'a ni identifiant ni route vers elle ;
• un disque perdu ou volé ne livre rien sans sa clé de chiffrement, qui ne voyage jamais avec lui ;
• avec le chiffrement client activé, le contenu reste illisible pour qui n'a pas votre clé — nous compris ;
• ce qui a été sauvegardé depuis le dernier envoi n'est pas sur le disque : la copie hors ligne a l'âge de sa dernière mise à jour ;
• une suppression sur la production se recopie : si les sauvegardes y sont effacées, l'incrémental suivant reporte l'effacement sur le disque rafraîchi. C'est voulu — la copie est le datastore lui-même. Ce qui protège alors, ce sont les autres supports, restés au coffre avec l'état d'avant ;
• une copie jamais relue n'est pas une sauvegarde : le verify forcé, puis une vraie restauration de temps en temps, sont la seule preuve.

Questions fréquentes