Ma stratégie de sauvegarde pour mon homelab : PBS, Plakar et S3

Introduction

Perdre des données, ça n’arrive pas qu’aux autres. Une fausse manipulation, un disque qui lâche, un ransomware, et c’est des semaines voire des mois de configuration qui disparaissent. Pour un homelab, on a souvent tendance à remettre ça à plus tard. On se dit que ce n’est “qu’un” homelab, que ça ne vaut pas la peine de mettre en place quelque chose de complexe. Et puis un jour, ça arrive. Heureusement ça n’a pas été mon cas, mais je préfère anticiper.

Dans cet article, je vous présente la stratégie de sauvegarde que j’ai mise en place sur mon homelab. Elle combine deux outils complémentaires, Proxmox Backup Server (PBS) et Plakar, avec des sauvegardes locales sur un disque ZFS dédié et une copie hors site sur S3 (Exoscale dans mon cas, mais n’importe quel fournisseur S3 convient). L’objectif : respecter la règle 3-2-1 recommandée par l’ANSSI, avec un RTO (Recovery Time Objective) rapide pour les incidents du quotidien et un vrai PRA (Plan de Reprise d’Activité) en cas de sinistre total.

Ce n’est pas la configuration la plus simple, mais je vais vous expliquer chaque choix et chaque configuration, étape par étape.

1. Architecture de la stratégie de sauvegarde

Avant de rentrer dans le détail technique, voici une vue d’ensemble. La stratégie combine deux outils hébergés sur le même hôte Proxmox : une VM Proxmox Backup Server en local (pool ZFS) et un LXC Plakar hors site (S3). Indépendants et complémentaires, je les détaille juste après.

Deux outils, deux rôles

PBS gère le RTO rapide pour les VMs et LXC Proxmox. Il prend des snapshots cohérents toutes les nuits, avec déduplication locale, et permet de restaurer une VM en quelques minutes. Les sauvegardes restent en local sur le disque ZFS.

Plakar couvre le PRA, le scénario du sinistre total. Il archive les VMs et LXC au format vzdump vers S3 (Exoscale), avec chiffrement de bout en bout et déduplication. Une rétention dégressive y conserve jusqu’à 3 mois d’historique, ce qui me suffit pour tout reconstruire : en cas de perte totale du serveur, je peux restaurer l’infrastructure sur un Proxmox fraîchement installé, sans même passer par PBS (qui serait lui aussi hors service).

J’aurais pu utiliser Plakar pour les sauvegardes locales également, mais PBS s’impose pour deux raisons. Il est conçu spécifiquement pour Proxmox : son intégration est native, sans SSH ni plugin intermédiaire, et sa déduplication chunk-level est particulièrement efficace sur les disques de VMs. La restauration avec PBS se fait également en quelques clics depuis l’interface Proxmox, là où Plakar nécessite une manipulation en CLI. Pour le RTO quotidien, c’est PBS sans hésitation.

La sauvegarde des équipements réseau (pare-feu, switch, point d’accès sans fil) fera l’objet d’articles dédiés. Elle s’appuiera sur Plakar, qui permet d’automatiser des scripts de sauvegarde personnalisés pour les équipements qui ne prennent pas en charge la sauvegarde vers S3 nativement.

Règle 3-2-1

Note : l’ANSSI recommande idéalement que la copie isolée soit hors ligne (déconnectée, hors d’atteinte d’un ransomware). La mienne est hors site mais en ligne, un compromis que j’assume pour mon homelab.

Matériel

Tout repose sur un seul serveur : un mini-PC Minisforum NAB6 Lite équipé d’un i5-12600H et de 32 Go de RAM. J’ai choisi ce modèle pour sa compacité, son silence et sa faible consommation électrique. C’est, à mon sens, le meilleur choix pour un serveur de homelab qui doit rester allumé en 24/7. Ses deux cartes réseau 2.5 Gbps et son accélération matérielle AES-NI jouent aussi un rôle clé : elles rendent le chiffrement et les transferts de sauvegarde quasiment transparents (j’y reviens plus loin).

Côté stockage, deux disques aux rôles bien séparés :

Séparer le disque de production du disque de sauvegarde n’est pas un détail : si le NVMe lâche, les sauvegardes locales restent intactes sur le SSD. Je détaille la création du pool et des datasets juste après.

2. Préparer le disque de sauvegarde avec ZFS

Pourquoi ZFS ?

ZFS n’est pas un simple système de fichiers. C’est une combinaison d’un gestionnaire de volumes et d’un système de fichiers qui offre plusieurs avantages clés pour du stockage de sauvegardes :

• Intégrité des données : ZFS calcule des checksums sur chaque bloc écrit. Si une donnée est corrompue (bit rot), ZFS le détecte à la lecture.
• Compression transparente : la compression (zstd dans mon cas) est appliquée automatiquement à l’écriture, sans intervention manuelle.
• Snapshots natifs : on peut prendre un snapshot instantané d’un dataset et le restaurer en quelques secondes.
• Intégration native dans Proxmox : Proxmox gère ZFS nativement, ce qui simplifie la configuration.

Création du pool

Je crée le pool entièrement en ligne de commande pour avoir accès à toutes les options dès la création. L’interface graphique de Proxmox ne permet pas de configurer atime et xattr à la création.

Je commence par identifier le disque :

root@atlas:~# lsblk
NAME                           MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                              8:0    0   1.8T  0 disk
[...]

Puis, je crée le pool avec toutes les options :

zpool create -f \
  -o ashift=12 \
  -O compression=zstd \
  -O atime=off \
  -O xattr=sa \
  backup /dev/sda

Voici ce que fait chaque option :

• -f : force la création même si le disque contient des traces d’un ancien pool

Options du pool (-o), paramètres bas niveau :

• ashift=12 : aligne les blocs sur 4096 octets (2^12=4096), adapté aux disques modernes. Ce paramètre ne peut pas être modifié après la création

Options des datasets (-O), héritées par tous les datasets enfants :

• compression=zstd : compression automatique des données, zstd offre un très bon compromis performance/compression
• atime=off : désactive l’enregistrement de la date de dernier accès (lecture) de chaque fichier, évite des écritures inutiles
• xattr=sa : stocke les attributs étendus directement dans l’inode plutôt que dans des fichiers séparés, bien plus performant sous Linux

Création des datasets

Un seul pool backup avec deux datasets distincts, un pour PBS, un pour Plakar. L’espace est mutualisé : chaque dataset peut utiliser tout l’espace libre disponible. Pas de quota, car un quota bloquerait les écritures s’il était atteint en pleine sauvegarde de nuit.

zfs create backup/pbs
zfs create backup/plakar

Je vérifie que tout est en ordre :

root@atlas:~# zfs list
NAME            USED  AVAIL  REFER  MOUNTPOINT
backup          788K  1.76T   104K  /backup
backup/pbs       96K  1.76T    96K  /backup/pbs
backup/plakar    96K  1.76T    96K  /backup/plakar

Comme dit précédemment, les deux datasets héritent automatiquement des options définies à la création du pool (compression, atime, xattr). Pour le vérifier :

root@atlas:~# zfs get compression,atime,xattr backup/pbs
NAME        PROPERTY     VALUE           SOURCE
backup/pbs  compression  zstd            inherited from backup
backup/pbs  atime        off             inherited from backup
backup/pbs  xattr        sa              inherited from backup

3. Mettre en place Proxmox Backup Server (PBS)

Télécharger et importer l’image ISO

La première étape consiste à télécharger l’ISO de la dernière version de PBS sur le site officiel de Proxmox. Au moment où j’écris cet article, la dernière version est la v4.1.

Une fois téléchargée, je l’importe dans mon stockage Proxmox dédié aux images ISO (Datacenter → nœud → local (nœud) → ISO Images, puis je clique sur Upload). J’ajoute également le checksum SHA256 fourni sur le site pour vérifier l’intégrité de l’image et m’assurer qu’elle n’a pas été corrompue durant le téléchargement.

Créer la VM PBS depuis l’UI Proxmox

Je crée la VM depuis l’interface graphique de Proxmox. Voici les choix que j’ai faits à chaque étape.

General : je donne un nom explicite à la VM (pbs), ainsi qu’un ID (111). J’active le démarrage automatique et j’ajoute le tag backup.

OS : je sélectionne l’ISO de PBS que je viens d’importer.

System : je laisse la configuration par défaut et je coche uniquement Qemu Agent. Cette option active le canal côté Proxmox. L’agent qemu-guest-agent doit ensuite être installé dans la VM pour un dialogue plus fin : arrêt propre, récupération de l’adresse IP, snapshots cohérents, etc.

Disks : je sélectionne local-lvm comme stockage, qui correspond au NVMe où tournent mes VMs, et je fixe la taille à 16 GiB. PBS n’a pas besoin de plus pour son système, les sauvegardes iront sur le dataset ZFS backup/pbs monté en NFS, pas sur ce disque. Si jamais je vois que c’est trop juste, j’augmenterai de 8 ou 16 GiB.

CPU : je laisse 1 socket et je passe à 2 cœurs. PBS n’est pas gourmand en CPU, mais 2 cœurs lui laissent de la marge pour les jobs de sauvegarde. Je conserve aussi le type x86-64-v2-AES, sélectionné par défaut par Proxmox : ce modèle de CPU expose l’instruction AES-NI à la VM, ce qui permet à PBS de profiter de l’accélération matérielle du chiffrement plutôt que de le faire en logiciel.

Memory : je passe à 4096 MiB. PBS utilise la RAM pour la déduplication et le cache, 4 Go est un minimum raisonnable. Comme pour la partie Disks, je pourrai toujours augmenter la mémoire au besoin.

Network : je laisse la configuration par défaut et j’assigne le VLAN Tag 20, mon VLAN dédié à mes serveurs. Adaptez-le à votre réseau (ou laissez le champ vide si vous n’utilisez pas de VLAN).

Confirm : je vérifie que tout est correct avant de valider.

Après avoir vérifié que la configuration est bonne, je clique sur Finish pour créer la VM. Elle apparaît alors dans la liste des VMs sur le nœud Proxmox.

Installer PBS dans la VM

Une fois la VM démarrée, l’installeur de PBS se lance automatiquement depuis l’ISO. La procédure est détaillée dans la documentation officielle de Proxmox. Je déroule ci-dessous les étapes, en m’attardant sur les points clés.

Écran d’accueil : je choisis Install Proxmox Backup Server (Graphical).

Contrat de licence (EULA) : je l’accepte en cliquant sur I agree.

Disque cible : je sélectionne le disque virtuel de la VM créé à l’étape précédente. Tout son contenu sera effacé, mais il s’agit ici d’un disque neuf et dédié.

Localisation et fuseau horaire : je renseigne le pays, le fuseau horaire et la disposition du clavier.

Mot de passe et email : je définis un mot de passe root complexe et une adresse email. C’est à cette adresse que PBS envoie ses notifications (alertes, échecs de sauvegarde) via sa méthode par défaut, Sendmail, donc autant en utiliser une dédiée à mon homelab. À noter que Sendmail s’appuie sur le serveur mail local et ne délivre pas toujours de façon fiable vers une boîte externe sans relais. PBS gère aussi d’autres méthodes de notification (SMTP, Gotify, Webhook), configurables dans Configuration → Notifications.

Configuration réseau : je renseigne le nom d’hôte, une adresse IP statique sur mon VLAN 20, la passerelle et le DNS. C’est cette IP qui servira ensuite à joindre l’interface web et à monter le partage NFS.

Résumé : je vérifie l’ensemble des paramètres puis je lance l’installation en cliquant sur Install.

À la fin de l’installation, la VM redémarre et la console affiche l’adresse à laquelle se connecter à l’interface web :

Je peux alors me connecter à l’interface web de PBS (https://IP-PBS:8007) avec l’utilisateur root et le mot de passe défini lors de l’installation :

Une fois connecté, PBS affiche son tableau de bord : uptime, ressources (CPU, RAM, disque), version du noyau et état des dépôts. La section Datastore Usage est encore vide (No Data), puisqu’aucun datastore n’a, pour le moment, été configuré.

Exposer backup/pbs en NFS depuis l’hôte Proxmox

PBS étant dans une VM dédiée, j’expose le dataset ZFS backup/pbs de l’hôte via NFS pour que la VM puisse y écrire.

J’installe le package nfs-kernel-server qui me permettra de créer un serveur NFS sur mon hôte Proxmox pour que ma VM PBS puisse accéder à mon dataset que j’ai précédemment créé :

root@atlas:~# apt update
root@atlas:~# apt install nfs-kernel-server

Je m’assure que le service NFS se lance automatiquement au démarrage :

root@atlas:~# systemctl enable nfs-server

Je configure l’export dans /etc/exports. Remplacez IP-PBS par l’IP de votre VM PBS :

echo "/backup/pbs  IP-PBS(rw,sync,no_subtree_check,no_root_squash)" >> /etc/exports
exportfs -ra

Quelques explications sur les options :

• rw : accès en lecture et écriture
• sync : les écritures sont confirmées uniquement une fois physiquement écrites sur le disque, plus sûr pour des sauvegardes
• no_subtree_check : améliore les performances et évite des problèmes lors des renommages de fichiers
• no_root_squash : par défaut, NFS réduit les droits du root client à un utilisateur anonyme. PBS ayant besoin des droits root pour créer le datastore et en ajuster les permissions, on désactive ce comportement.

Note : no_root_squash est très permissif, il accorde un accès root complet sur l’export. Il est donc important de restreindre l’export à la seule IP de la VM PBS, comme ici, et de ne jamais l’ouvrir à un sous-réseau entier.

Monter le partage NFS dans la VM PBS et configurer le datastore

Montage du partage NFS

Dans la VM PBS (via la console depuis l’hôte Proxmox, en SSH, ou depuis le shell intégré à l’interface web de PBS), j’installe le client NFS et je monte le partage :

apt install nfs-common
mkdir -p /mnt/pbs

# Montage temporaire pour vérifier que ça fonctionne
mount IP-PROXMOX:/backup/pbs /mnt/pbs

# Montage permanent
echo "IP-PROXMOX:/backup/pbs  /mnt/pbs  nfs  defaults,_netdev  0  0" >> /etc/fstab

Remplacez IP-PROXMOX par l’IP de votre hôte Proxmox. L’option _netdev indique que ce montage dépend du réseau : au démarrage, le système attend que le réseau soit prêt avant de monter le partage, ce qui évite l’échec d’un montage tenté trop tôt dans le boot.

Note : si vous avez un pare-feu sur votre réseau ou si votre PBS et votre Proxmox ne sont pas dans le même VLAN, n’oubliez pas de vérifier que le PBS peut communiquer avec le serveur Proxmox sur le port 2049.

Configuration du datastore PBS

Une fois connecté à l’interface PBS, je commence par ajouter le datastore qui pointe vers le partage NFS monté précédemment.

Dans le menu de gauche, tout en bas, allez dans Datastore > Add Datastore :

• Name : pbs-datastore (ou le nom de votre choix)
• Backing Path : /mnt/pbs
• Prune schedule : 05:00
• GC schedule : 06:00

La séquence nocturne sera ainsi la suivante :

01h00 → Backup
05h00 → Prune (supprime les snapshots expirés selon la politique de rétention)
06h00 → GC (libère l'espace disque occupé par les données orphelines)

Une fois le datastore créé, il apparaît dans le menu de gauche. Son onglet Summary affiche l’espace utilisé, le nombre de sauvegardes par type (CT, Host, VM) ou encore le facteur de déduplication.

Création du namespace

Un namespace permet de cloisonner logiquement les sauvegardes à l’intérieur d’un même datastore. Comme je prévois de sauvegarder un second serveur Proxmox vers ce datastore unique, je crée dès maintenant un namespace par nœud : chaque serveur écrira ainsi ses sauvegardes dans son propre espace, sans risque de mélange, et je pourrai affiner les permissions namespace par namespace si besoin.

Dans le datastore, onglet Content, je clique sur Add Namespace et je crée un namespace que je nomme d’après le nom de mon nœud, ici atlas (le parent reste Root).

Configuration de la politique de rétention

La politique de rétention définit combien de sauvegardes PBS conserve avant de supprimer les plus anciennes. Sans politique, PBS garde tout indéfiniment et le disque finit par se remplir.

Dans le datastore, onglet Prune & GC Jobs, section Prune Jobs, je modifie le job de prune et je configure les valeurs suivantes :

Le job s’applique au namespace Root avec une profondeur Full, il couvre donc tous les namespaces du datastore, dont atlas.

Cette politique offre une granularité fine sur le court terme et une couverture raisonnable jusqu’à 3 mois. La copie hors site (Plakar/S3) couvre le même horizon : PBS et Plakar se complètent par leur emplacement (local et distant), pas par leur durée.

Un seul datastore suffit pour plusieurs nœuds Proxmox. Grâce aux namespaces (un par nœud), les sauvegardes de chaque serveur sont cloisonnées dans le datastore. Les namespaces cloisonnent la vue, pas le stockage : la déduplication continue de s’appliquer sur tout le datastore, y compris entre les nœuds.

Connecter PBS à Proxmox

La connexion entre Proxmox et PBS ne se fera pas avec le compte root, mais avec un utilisateur dédié, créé spécialement pour les sauvegardes. Il s’agit du principe du moindre privilège, ce qui signifie que le compte ne possèdera que les droits strictement nécessaires.

Créer un utilisateur dédié dans PBS

Dans l’interface PBS, je vais dans Configuration → Access Control → User Management → Add et je remplis les champs :

• User name : backup
• Password / Confirm password : un mot de passe solide

Le realm est automatiquement défini sur Proxmox Backup authentication server, le seul permettant de créer un utilisateur ici. L’utilisateur sera donc backup@pbs.

Assigner les permissions

Dans Configuration → Access Control → Permissions → Add → User Permission, je remplis les champs :

• Path : /datastore/pbs-datastore
• User : backup@pbs
• Role : DatastoreBackup (permet de créer et de restaurer ses propres sauvegardes, sans pouvoir purger ni gérer le datastore)
• Propagate : coché (la permission se propage aux namespaces du datastore, dont atlas, là où PBS stocke les sauvegardes de chaque nœud)

Ajouter PBS comme storage dans Proxmox

Dans l’interface Proxmox, je vais dans Datacenter → Storage → Add → Proxmox Backup Server et je remplis les champs dans l’onglet General :

• ID : pbs
• Server : IP de la VM PBS
• Username : backup@pbs
• Password : le mot de passe défini précédemment
• Nodes : je laisse à All (no restrictions)
• Datastore : pbs-datastore
• Namespace : atlas (le namespace créé précédemment dans PBS)
• Fingerprint : disponible dans PBS → Dashboard → Show Fingerprint

Il y a également deux autres onglets :

• Backup Retention : permet de configurer la durée de rétention des sauvegardes à la journée, semaine, mois, etc. Je ne configure pas cet onglet et je laisse la case Keep all backups cochée. Les configurations de rétention sont gérées directement dans mon PBS.
• Encryption : définit si les sauvegardes seront chiffrées ou non. Même si les sauvegardes PBS restent en local sur mon disque ZFS, je préfère les chiffrer : en cas de vol du serveur ou d’un disque, les données restent illisibles. J’active donc le chiffrement en sélectionnant l’option Auto-generate a client encryption key. Grâce à l’accélération matérielle AES-NI et au réseau 2.5 Gbps évoqués plus haut, le chiffrement est totalement transparent et ne bride pas les performances. Les données sont chiffrées par le client, c’est-à-dire l’hôte Proxmox, avant d’être transmises puis stockées sur le serveur PBS, qui ne voit jamais les données en clair.

Important : Si vous activez le chiffrement, sauvegardez immédiatement la clé générée. PBS recommande d’ailleurs trois stratégies de conservation, à combiner idéalement : l’enregistrer dans un gestionnaire de mots de passe (comme Proton Pass ou Bitwarden), la télécharger sur une clé USB rangée dans un coffre, et l’imprimer sous forme de “paperkey”, la plastifier et la placer dans un coffre. Si, un jour, votre nœud Proxmox crashe, vos sauvegardes seront inutilisables sans cette clé.

Une fois ajouté, le storage pbs apparaît dans la liste des storages disponibles sur le nœud Proxmox.

Pensez à vérifier que votre pare-feu autorise le nœud Proxmox à joindre le PBS sur le port 8007, celui par lequel transitent les sauvegardes.

Configurer les jobs de backup PBS

Une fois PBS ajouté comme storage dans Proxmox, je configure le job de backup depuis Datacenter → Backup → Add.

Onglet General

• Node : atlas (mon nœud), pour limiter le job à ce nœud
• Storage : pbs
• Schedule : 01:00
• Selection mode : Include selected VMs (je sélectionne manuellement les VMs à sauvegarder)
• Mode : Snapshot (sauvegarde sans arrêter ni suspendre les VMs)

Le champ Compression est grisé sur ZSTD (fast and good) : avec une cible PBS, la compression est imposée et gérée par PBS lui-même, il n’y a rien à régler ici.

Onglet Retention

Je laisse tous les champs vides, car la politique de rétention définie au niveau du datastore PBS (keep-last=3, keep-daily=14, keep-weekly=8, keep-monthly=3) s’applique de toute façon : c’est le job Prune du datastore, planifié à 05:00, qui la met en œuvre.

Note : si vous remplissez les valeurs de rétention ici, l’utilisateur backup@pbs aura besoin du rôle DatastorePowerUser au lieu de DatastoreBackup pour avoir le droit d’effectuer le nettoyage des sauvegardes (Prune). Par simplicité et principe du moindre privilège, je laisse le datastore gérer la rétention.

Je ne touche pas aux autres onglets et je laisse les valeurs par défaut, quitte à y revenir plus tard si besoin.

Je clique sur Create. Le job apparaît dans la liste avec la prochaine exécution planifiée à 01:00.

4. Mettre en place Plakar pour le PRA

Créer le LXC Debian

Pour créer le LXC Debian, j’utilise le script de community-scripts.org. Si vous n’êtes pas familier avec cet outil, j’ai écrit un article dédié qui explique toutes les étapes : Installer un LXC ou une VM sur Proxmox avec Community Scripts.

Voici les paramètres que j’ai choisis pour le LXC Plakar :

Pour les autres configurations possibles, j’ai laissé les valeurs par défaut.

Installer Plakar

L’intégration Proxmox nécessite Plakar v1.1.0 minimum. Je ne reviens pas en détail sur l’installation de Plakar, la procédure complète est documentée dans mon article Prise en main de Plakar.

Une fois installé, je vérifie la version :

plakar version

plakar/v1.1.0

Monter backup/plakar dans le LXC

Plutôt que de passer par NFS, j’utilise un bind mount. Proxmox monte ainsi directement le dataset ZFS de l’hôte dans le LXC. C’est plus simple et plus performant : pas de réseau, accès direct au système de fichiers.

Sur l’hôte Proxmox, j’arrête d’abord le LXC s’il est démarré :

pct stop ID_LXC

Note : si le mode protection est activé sur le LXC (comme dans mon cas), la commande suivante pour configurer le bind mount retournera l’erreur can't update CT ID_LXC drive 'mp0' - protection mode enabled. Je le désactive donc temporairement :

pct set ID_LXC -protection 0

Je configure ensuite le bind mount avec l’option backup=0 pour exclure ce point de montage des sauvegardes PBS, car il est inutile de sauvegarder l’endroit où sont stockées les sauvegardes :

pct set ID_LXC -mp0 /backup/plakar,mp=/mnt/plakar,backup=0

Une fois le bind mount configuré, je réactive la protection :

pct set ID_LXC -protection 1

Je redémarre le LXC :

pct start ID_LXC

Enfin, je vérifie depuis l’intérieur du LXC que le montage est bien en place :

df -h /mnt/plakar

Filesystem      Size  Used Avail Use% Mounted on
backup/plakar   1.8T  128K  1.8T   1% /mnt/plakar

Note : le bind mount dans un LXC non privilégié nécessite un ajustement des permissions, détaillé dans la section suivante.

Configurer le store local (backup/plakar)

Le dataset ZFS backup/plakar, monté dans le LXC via le bind mount configuré précédemment, joue en réalité plusieurs rôles. Avant de créer le store local, autant clarifier à quoi il sert vraiment :

• Le cache des sauvegardes S3 : les fichiers temporaires de Plakar y sont redirigés (/mnt/plakar/.cache) pour ne pas saturer le disque système du LXC. C’est son usage le plus important au quotidien.
• La zone de restauration : les archives restaurées y sont écrites (/mnt/plakar/restore) plutôt que dans /tmp, monté en tmpfs (RAM) sur mon LXC.
• Un store local Plakar : c’est ce que l’on configure ci-dessous. Il ne sert pas à sauvegarder les VMs et LXC (PBS s’en charge, ce serait redondant), mais à sauvegarder tout ce que PBS ne couvre pas (équipements réseau, configurations applicatives, sauvegarde de bases de données, etc.). Cet usage fera l’objet d’articles dédiés. Le store est donc créé ici, prêt à l’emploi, mais pas encore alimenté.

Autrement dit, même sans aucune sauvegarde locale de VM avec Plakar, le dataset backup/plakar reste indispensable : il porte le cache lors des sauvegardes et le staging des restaurations sans lesquels les sauvegardes S3 et les restaurations ne fonctionneraient pas correctement.

Si vous n’êtes pas familier avec les concepts de base de Plakar (Kloset store, passphrase, automatisation), je vous invite à lire mon article Prise en main de Plakar : la solution de backup open source française avant de continuer.

Avant toute chose, j’ajuste les permissions du dataset ZFS depuis le nœud Proxmox, pas depuis le LXC. Le LXC étant non privilégié, son root (UID 0) est mappé sur l’UID 100000 de l’hôte :

chown -R 100000:100000 /backup/plakar

Je vérifie que les permissions sont correctes :

ls -la /backup/

Depuis le LXC Plakar, j’initialise ensuite le store local :

plakar store add local-backup location=/mnt/plakar

Je crée le Kloset sur ce store :

plakar at @local-backup create

Plakar vous demandera de définir une passphrase. Choisissez-en une solide et conservez-la précieusement, sans elle vos sauvegardes seront irrécupérables.

Je vérifie que le store est bien configuré :

plakar store show local-backup

Configurer le store S3 (Exoscale)

Pour la configuration complète d’Exoscale (création du bucket, IAM, pricing), je vous renvoie vers mon article dédié : Sauvegarde hors site avec Plakar et Exoscale SOS. Voici les commandes essentielles pour configurer le store S3 dans Plakar.

Le plugin S3 n’est pas inclus par défaut dans Plakar, il faut l’installer séparément. Deux options selon que vous souhaitez vous connecter à Plakar ou non :

# En se connectant à Plakar
plakar login
plakar pkg add s3

# Sans connexion (compilation depuis les sources)
plakar pkg build s3
plakar pkg add ./s3_v1.0.7_linux_amd64.ptar

La version du plugin est la v1.0.7 au moment de l’écriture de cet article.

Je configure ensuite le store S3 :

plakar store add exoscale-backup \
  location=s3://sos-de-fra-1.exo.io/mon-bucket-plakar \
  access_key=S3_API_KEY \
  secret_access_key=S3_API_SECRET \
  passphrase=PASSPHRASE_PLAKAR_EXOSCALE \
  use_tls=true

J’initialise le Kloset sur le bucket :

plakar at @exoscale-backup create

Je vérifie que le store est bien configuré :

plakar store show exoscale-backup

exoscale-backup:
    access_key: '********'
    location: s3://sos-de-fra-1.exo.io/mon-bucket-plakar
    passphrase: '********'
    secret_access_key: '********'
    use_tls: "true"

Intégrer Proxmox à Plakar

Générer la clé SSH

Depuis le LXC Plakar, je génère une clé SSH ed25519 dédiée aux connexions vers les nœuds Proxmox. Je ne mets pas de passphrase sur la clé, car cron ne pourrait pas se connecter automatiquement sans intervention humaine pour la saisir. La sécurité repose sur les permissions du fichier (600) et l’isolation du serveur Plakar via des règles de pare-feu.

ssh-keygen -t ed25519 -C "plakar-backup" -f ~/.ssh/id_ed25519

Je dépose ensuite la clé publique sur le nœud Proxmox :

# Depuis le LXC Plakar
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@IP-PROXMOX

Pour la commande ci-dessus, il faut que le flux SSH entre le serveur Plakar et le nœud soit autorisé par votre pare-feu.

Je vérifie que la connexion SSH fonctionne sans mot de passe :

ssh -i /root/.ssh/id_ed25519 root@IP-PROXMOX

Restreindre la clé SSH aux backups

Par défaut, la clé SSH déposée sur le nœud donne un accès root complet. Il est possible de réduire la surface d’attaque en ajoutant l’option restrict dans le fichier authorized_keys du nœud Proxmox.

restrict désactive le forwarding X11, le forwarding d’agent SSH, le port forwarding et le pseudo-terminal, tout ce dont Plakar n’a pas besoin pour effectuer ses sauvegardes.

Sur le nœud Proxmox, je modifie le fichier /root/.ssh/authorized_keys et je préfixe la ligne de la clé plakar-backup avec restrict :

restrict ssh-ed25519 AAAA... plakar-backup

Note : il n’est pas possible de restreindre la clé à une seule commande (comme vzdump), car Plakar en mode remote exécute plusieurs commandes sur le nœud pour lister les VMs et récupérer les archives. L’option restrict est le meilleur compromis pour un homelab sur réseau interne.

Installer le plugin Proxmox

Comme pour S3, l’intégration Proxmox de Plakar est distribuée sous forme de plugin officiel, installable en une commande depuis le registre Plakar (avec ou sans authentification) :

plakar login
plakar pkg add proxmox

Si je me suis déjà connecté pour installer le plugin S3, je n’ai pas besoin de me reconnecter. Et comme pour S3, il est aussi possible d’installer le plugin Proxmox sans connexion, à partir du binaire fourni par Plakar.

Je vérifie que le plugin est bien installé :

plakar pkg list

proxmox@v1.1.0-rc.1

Configurer les sources Proxmox

J’enregistre le nœud Proxmox comme source dans Plakar :

plakar source add mon-proxmox proxmox+backup://IP-PROXMOX \
  mode=remote \
  conn_username=root \
  conn_identity_file=/root/.ssh/id_ed25519 \
  conn_method=identity

Je vérifie que la source est bien enregistrée :

plakar source show mon-proxmox

mon-proxmox:
    conn_identity_file: /root/.ssh/id_ed25519
    conn_method: identity
    conn_username: root
    location: proxmox+backup://IP-PROXMOX
    mode: remote

Configurer les jobs de sauvegarde

Préparer l’automatisation

Pour automatiser Plakar avec cron, il ne faut pas que la passphrase soit demandée interactivement. Elle doit être configurée dans ~/.config/plakar/stores.yml. La passphrase d’exoscale-backup a été ajoutée automatiquement lors de la configuration du store, mais il est bon de vérifier le fichier :

cat ~/.config/plakar/stores.yml

version: v1.0.0
stores:
    exoscale-backup:
        access_key: S3_API_KEY
        location: s3://sos-de-fra-1.exo.io/mon-bucket-plakar
        passphrase: PASSPHRASE_PLAKAR_EXOSCALE
        secret_access_key: S3_API_SECRET
        use_tls: "true"
    local-backup:
        location: /mnt/plakar
        passphrase: PASSPHRASE_PLAKAR_LOCAL

Note : les passphrases des stores exoscale-backup et local-backup peuvent techniquement être identiques, mais il est recommandé d’utiliser des passphrases différentes pour chaque store.

Je m’assure que le fichier est bien sécurisé, il contient des informations sensibles :

chmod 600 ~/.config/plakar/stores.yml
ls -l ~/.config/plakar/stores.yml

-rw------- 1 root root 426 May 24 20:05 /root/.config/plakar/stores.yml

Pour plus de détails sur la gestion de la passphrase et les alternatives (HashiCorp Vault, 1Password CLI), je vous renvoie vers la documentation officielle de Plakar.

Création du pool sur Proxmox

Pour dire à Plakar quoi sauvegarder, je m’appuie sur un pool Proxmox. Attention à ne pas le confondre avec le pool ZFS backup créé plus tôt : ce sont deux notions distinctes qui partagent malheureusement le même mot.

• Un pool ZFS est un agrégat de stockage : il regroupe un ou plusieurs disques physiques sur lesquels on crée des datasets.
• Un pool Proxmox est un simple groupe logique de VMs et de LXC, pratique pour les organiser et agir sur un ensemble d’un coup (permissions, sauvegardes, etc.).

Je crée donc un pool Proxmox dédié aux sauvegardes Plakar. Dans Datacenter → Pools → Create, je le nomme backup-plakar, puis j’y assigne les VMs et LXC que je veux sauvegarder sur S3. Plakar pourra ensuite cibler ce pool via une seule option, sans avoir à énumérer chaque machine.

Première sauvegarde manuelle

Avant d’automatiser, je lance une première sauvegarde manuelle pour valider que tout fonctionne correctement.

Note : n’incluez pas le LXC faisant tourner Plakar dans le pool de sauvegarde. Plakar essaierait de se sauvegarder lui-même pendant qu’il écrit sur son point de montage (/mnt/plakar), ce qui cause un deadlock. Le piège : le vzdump du LXC apparaît quand même comme OK dans l’historique des tâches Proxmox, ce qui masque le problème.

L’option -cache est indispensable pour rediriger les fichiers temporaires vers /mnt/plakar/.cache, sans elle Plakar utilise ~/.cache/plakar sur le disque système du LXC (16 GiB) qui se remplit rapidement avec des VMs volumineuses.

L’option -o pool=backup-plakar filtre les sauvegardes en ciblant uniquement les VMs et LXC du pool Proxmox backup-plakar créé précédemment. Adaptez le nom du pool à votre configuration. Pour plus de détails sur les options disponibles, consultez la documentation officielle de Plakar.

L’option -tag atlas marque chaque snapshot avec le nom du nœud sauvegardé. Je prévois de sauvegarder un second serveur Proxmox dans ce même store exoscale-backup, et ce tag permettra de distinguer la provenance de chaque snapshot pour cibler la rétention nœud par nœud (voir plus bas), afin que chaque serveur conserve ses propres sauvegardes. La déduplication, elle, continue de s’appliquer sur tout le store, y compris entre les nœuds.

plakar at @exoscale-backup backup \
  -cache /mnt/plakar/.cache \
  -tag atlas \
  -o pool=backup-plakar @mon-proxmox

Je vérifie que les snapshots sont bien présents :

plakar at @exoscale-backup ls

Configurer la rétention sur S3

Contrairement à PBS, où la rétention se règle dans l’interface, Plakar la gère avec des politiques (plakar policy) appliquées par la commande plakar prune. Sans rétention, chaque sauvegarde quotidienne s’accumule indéfiniment sur S3, et la facture Exoscale avec.

Je veux une rétention dégressive couvrant jusqu’à 3 mois, alignée sur celle de PBS : fine sur les jours récents, plus espacée en remontant. Concrètement, je garde une sauvegarde par jour sur les 7 derniers jours, une par semaine sur les 4 dernières semaines, et une par mois sur les 3 derniers mois. Chaque fenêtre se définit par une durée (days, weeks, months) et un plafond par période (per-day, per-week, per-month). Je crée donc la politique s3-retention :

plakar policy add s3-retention
plakar policy set s3-retention days=7
plakar policy set s3-retention per-day=1
plakar policy set s3-retention weeks=4
plakar policy set s3-retention per-week=1
plakar policy set s3-retention months=3
plakar policy set s3-retention per-month=1

Je vérifie la politique :

plakar policy show s3-retention

s3-retention:
    periods:
        day:
            keep: 7
            cap: 1
        week:
            keep: 4
            cap: 1
        month:
            keep: 3
            cap: 1

La politique n’est qu’une règle : elle ne supprime rien par elle-même, c’est prune qui l’applique. Je restreins le prune au tag atlas avec -tag atlas, pour que la politique ne s’applique qu’aux snapshots de ce nœud. Les plafonds de la politique sont ainsi évalués nœud par nœud, et chaque serveur conserve son propre historique indépendamment. Sans ce filtre, le cap porterait sur l’ensemble du store : comme chaque nœud produit un snapshot par nuit, le prune n’en garderait qu’un seul par jour et supprimerait celui des autres nœuds.

Je teste d’abord en mode simulation. Sans le flag -apply, prune affiche seulement ce qu’il ferait, sans rien supprimer : les snapshots conservés (chacun avec le motif match=day, match=week ou match=month selon la fenêtre qui le retient) et ceux qui sortent des fenêtres.

plakar at @exoscale-backup prune -policy s3-retention -tag atlas

Une fois le résultat vérifié, j’ajoute -apply pour réellement supprimer les snapshots expirés :

plakar at @exoscale-backup prune -policy s3-retention -tag atlas -apply

Note : les fenêtres (days, weeks, months) sont glissantes, recalculées à chaque exécution par rapport à la date du jour, ce qui les rend adaptées à un cron quotidien. Attention à ne pas utiliser le filtre since à la place : il est résolu en date absolue au moment de la création de la politique et ne « roule » donc pas dans le temps.

Planifier avec cron

J’édite la crontab du LXC Plakar :

crontab -e

J’ajoute ensuite les lignes suivantes pour automatiser la séquence nocturne complète. Les logs sont redirigés vers /var/log/plakar-exoscale.log pour pouvoir vérifier que tout s’est bien déroulé.

# Backup Proxmox → Exoscale S3
0 3 * * * /usr/local/bin/plakar at @exoscale-backup backup -cache /mnt/plakar/.cache -tag atlas -o pool=backup-plakar @mon-proxmox >> /var/log/plakar-exoscale.log 2>&1
# Rétention S3 : applique la politique s3-retention (~3 mois d'historique dégressif, nœud atlas)
0 4 * * * /usr/local/bin/plakar at @exoscale-backup prune -policy s3-retention -tag atlas -apply >> /var/log/plakar-exoscale.log 2>&1

La séquence nocturne complète est donc :

01h00 → PBS sauvegarde les VMs et LXC (local ZFS)
03h00 → Plakar sauvegarde le nœud Proxmox vers Exoscale S3
04h00 → Plakar applique la rétention S3 (prune)
05h00 → PBS Prune
06h00 → PBS GC

5. Tests de restauration

Mettre en place des sauvegardes, c’est bien, mais tester qu’elles fonctionnent réellement, c’est indispensable. Voici comment tester une restauration avec PBS et avec Plakar.

Restauration PBS

La restauration PBS peut se faire entièrement depuis l’interface graphique de Proxmox.

Depuis le nœud Proxmox, je sélectionne la VM ou le LXC à restaurer → Backup → je sélectionne le storage pbs → je choisis le snapshot souhaité → je clique sur Restore.

La fenêtre de restauration propose plusieurs options :

• Storage : le stockage de destination (local-lvm dans mon cas)
• CT pour un conteneur, VM pour une machine virtuelle : l’ID de destination (par défaut le même ID, ce qui écrasera l’existant)
• Unique : génère de nouvelles adresses MAC et UUID (utile pour restaurer en parallèle sans conflit réseau)
• Start after restore : démarre automatiquement après la restauration
• Privilege Level : From Backup (conserve le niveau de privilège d’origine)

Note : il n’est pas possible d’écraser un LXC ou une VM en cours d’exécution. Il faut d’abord l’arrêter :

pct stop ID_LXC
# ou
qm stop ID_VM

Une fois la restauration lancée, le résultat apparaît dans le Task Viewer en cliquant sur la tâche en bas de l’écran :

TASK OK

Restauration Plakar

La restauration Plakar se fait en CLI depuis le LXC Plakar. Elle produit une archive vzdump qui peut ensuite être réimportée dans Proxmox.

Lister les snapshots disponibles

plakar at @exoscale-backup ls

2026-05-26T16:53:10Z   9f604141    59 GiB    32m15s /

Explorer le contenu d’un snapshot

Un snapshot contient l’arborescence du nœud Proxmox sauvegardé. Pour retrouver la VM ou le LXC à restaurer, j’explore le snapshot par son identifiant. Les archives vzdump des LXC se trouvent dans /backup/lxc :

plakar at @exoscale-backup ls 9f604141:/backup/lxc

1970-01-01T00:00:00Z drwxr-x---     root     root      0 B 100_app-a
1970-01-01T00:00:00Z drwxr-x---     root     root      0 B 103_app-b
1970-01-01T00:00:00Z drwxr-x---     root     root      0 B 104_app-c
...

Chaque entrée correspond à une VM ou un LXC, sous la forme <ID>_<nom>. Je repère celui que je veux restaurer, ici 103_app-b.

Restaurer une archive vzdump

Je restaure l’archive vers /mnt/plakar, et non vers /tmp qui est monté en tmpfs (RAM) sur mon LXC et provoquerait un swap à 100% (ça m’est arrivé durant mes tests) :

mkdir -p /mnt/plakar/restore
plakar at @exoscale-backup restore \
  -to /mnt/plakar/restore \
  9f604141:/backup/lxc/103_app-b

9f604141: OK ✓ /vzdump-lxc-103-2026_05_26-18_53_29.tar_pool.conf

Je vérifie que les fichiers sont bien présents :

ls -lh /mnt/plakar/restore

-rw------- 1 root root 4.9G May 26 18:53 vzdump-lxc-103-2026_05_26-18_53_29.tar
-rw------- 1 root root 1.8K May 26 18:53 vzdump-lxc-103-2026_05_26-18_53_29.tar_lxc.conf
-rw------- 1 root root   13 May 26 18:53 vzdump-lxc-103-2026_05_26-18_53_29.tar_pool.conf

Réimporter dans Proxmox

Je copie l’archive sur le nœud Proxmox puis je la restaure avec pct restore :

# Copier l'archive sur le nœud Proxmox
scp /mnt/plakar/restore/vzdump-lxc-103-*.tar root@IP-PROXMOX:/var/lib/vz/dump/

# Restaurer depuis le nœud Proxmox
pct restore 200 /var/lib/vz/dump/vzdump-lxc-103-2026_05_26-18_53_29.tar \
  --storage local-lvm

J’utilise un ID différent (200) pour ne pas écraser le LXC existant en production.

Une fois validé, je nettoie le dossier de restauration :

rm -rf /mnt/plakar/restore

Conclusion

Mettre en place une vraie stratégie de sauvegarde, c’est le genre de chantier qu’on repousse indéfiniment : trop long, trop cher, « pas vraiment utile pour un homelab ». Jusqu’au jour où on perd des données, ou qu’on réalise qu’un seul disque défaillant nous sépare du sinistre total.

Ce que j’ai mis en place ici n’est pas la configuration la plus simple, mais elle respecte la règle 3-2-1 : 3 copies, sur 2 supports, dont 1 hors site. PBS assure le quotidien avec un RTO rapide (une VM corrompue, une fausse manipulation, et je restaure en quelques minutes), pendant que Plakar archive des sauvegardes chiffrées hors site sur Exoscale, restaurables sur un Proxmox vierge même en cas de perte physique du serveur. Personne d’autre que moi ne peut lire ces données, pas même Exoscale.

Le choix de ZFS pour le stockage local n’est pas qu’une question de performances : ses checksums détectent le bit rot, cette corruption silencieuse que la plupart des systèmes de fichiers laissent passer. Pour un disque dédié aux sauvegardes, c’est un atout que je ne voulais pas négliger.

Ce qui m’a le plus surpris, c’est que les difficultés ne sont pas venues d’où je les attendais. ZFS, NFS, PBS : tout cela est bien documenté et se met en place proprement. Les vrais pièges étaient dans les interactions entre les outils : le LXC Plakar dans son propre pool de sauvegarde qui provoque un deadlock, et les grosses VMs plus gourmandes en RAM que prévu à cause du cache. L’intégration Proxmox de Plakar était encore en RC (v1.1.0-rc.1) au moment de mes tests, et ça se ressentait, la v1.1.0 stable est sortie pendant la rédaction. Ce sont ces détails qu’on ne trouve pas dans la documentation officielle et que j’espère vous avoir épargnés ici.

Ma stratégie est en place et opérationnelle. Un disque qui lâche ou une fausse manipulation ne seront plus une catastrophe, juste une restauration à lancer.