HL-PRC-017 — Proxmox VE — sauvegarde vers Google Drive (NFS/Rclone)

PROCÉDURE TECHNIQUE

Sauvegarde Proxmox VE vers Google Drive

Centralisation NFS sur stockage partagé de grappe, script hook VZDump et transfert automatisé rclone vers Google Drive.

Sommaire

Sauvegarde Proxmox VE vers Google Drive — HL-PRC-017

1 Objet

Cette procédure met en œuvre l’externalisation automatisée des sauvegardes des machines virtuelles et conteneurs d’un cluster Proxmox VE (composé des trois nœuds pve1, pve2 et pve3) vers un stockage cloud Google Drive personnel. Le dispositif repose sur la mise en place d’un partage NFS centralisé sur le disque dur dédié de 1 To hébergé par le nœud physique pve3, la déclaration d’un stockage de grappe nfs-backups, le déploiement d’un script hook VZDump intelligent sur chaque membre du cluster, ainsi que la synchronisation unitaire des archives compressées au moyen de l’utilitaire rclone. À l’issue de l’intervention, chaque sauvegarde planifiée ou manuelle génère une archive locale sur l’espace partagé, puis est immédiatement transmise et classée sur Google Drive dans une arborescence dédiée (Backup Proxmox/<nœud>/<vmid>-<nom>/).

La difficulté principale traitée réside dans l’hétérogénéité des stockages locaux et les contraintes techniques du protocole Google Drive. Une configuration initiale reposant sur un montage direct de système de fichiers FUSE (rclone mount) partagé à l’ensemble du cluster échouait systématiquement lors de l’exécution sur les nœuds distants non montés, bloquant l’activation du stockage. De surcroît, le stockage objet PBS ne peut être directement relayé en S3 vers Google Drive en raison de l’incompatibilité de son API propriétaire et du blocage lié au découpage en millions de micro-blocs (chunks). L’architecture validée dissocie la rétention locale en NFS et l’externalisation asynchrone par fichier d’archive complet, réduisant le risque de saturation d’API et résolvant les incidents de verrous résiduels sur les invités.

2 Périmètre et prérequis

Périmètre

Couvert : décommissionnement et suppression propre de l’ancien stockage FUSE gdrive-backup ; installation et configuration du serveur NFS sur pve3 avec export réseau du répertoire /mnt/pve/hdd1to/dump-cluster vers le sous-réseau du cluster ; déclaration du stockage de grappe nfs-backups dans /etc/pve/storage.cfg ; déploiement de la configuration et des binaires rclone sur l’ensemble des trois nœuds ; création et déploiement du script hook /root/backup-to-gdrive.sh avec détection dynamique du nom de l’invité et transfert vers Google Drive ; activation globale dans /etc/vzdump.conf ; résolution des incidents réels rencontrés (déverrouillage de conteneur, interruption de tâches bloquées et purge de verrous).

Hors périmètre : génération initiale du jeton OAuth Google et du Client ID (déjà présents dans le fichier rclone.conf) ; refonte des sauvegardes incrémentales Proxmox Backup Server (PBS) gérées en parallèle ; mécanisme de purge automatique (prune) sur le cloud distant Google Drive.

Prérequis

• Cluster Proxmox VE 9.2 : grappe opérationnelle composée des nœuds pve1, pve2 et pve3 sur Debian 13 (Trixie), avec quorum actif.

• Accès privilégié : session root directe sur chaque nœud par clé SSH, sans utilisation de sudo.

• Stockage volumique : disque dédié de 1 To (hdd1to) monté sur pve3 à l’emplacement /mnt/pve/hdd1to avec espace suffisant pour les sauvegardes de grappe.

• Connectivité réseau : sous-réseau de gestion 10.10.10.0/24 routé et sans filtrage interne sur les ports NFS (TCP 2049, TCP/UDP 111).

• Accès Internet sortant : résolution DNS et flux HTTPS (TCP 443) autorisés depuis tous les nœuds vers les serveurs Google Drive API.

• Configuration rclone existante : fichier /root/.config/rclone/rclone.conf valide contenant la télécommande fonctionnelle gdrive:.

Note Version validée. Procédure rédigée et validée sur le lab le 24/10/2026 sous Proxmox Virtual Environment 9.2.21 (Debian 13.7, noyau 7.0.14-12-pve) et rclone 1.60.1+dfsg-4. Toutes les commandes, sorties et cas d’erreur sont strictement issus des sessions réelles.

3 Rôles et responsabilités

Note Homelab individuel. Dans le cadre du lab, l’ensemble de ces responsabilités est porté par un opérateur unique. La distinction des rôles est maintenue à des fins méthodologiques et de traçabilité d’exploitation.

4 Procédure de configuration et de déploiement

Paramètres de la procédure

Attention Substitution des paramètres. Les blocs de commandes ci-après utilisent directement les valeurs de référence réelles du lab. En cas d’adaptation sur un autre environnement, substituer scrupuleusement les adresses IP et chemins avant toute exécution.

Architecture et cinématique des sauvegardes

Le mécanisme d’externalisation s’articule autour d’un flux séquentiel découplé : le job VZDump de cluster (planifié chaque jour à 23h00) déclenche la création d’une archive standard (.tar.zst pour les conteneurs LXC, .vma.zst pour les machines virtuelles) directement sur le partage centralisé nfs-backups hébergé sur le disque de 1 To de pve3. Dès qu’une sauvegarde individuelle s’achève avec succès, Proxmox VE transmet le chemin de l’archive générée via la variable $TARFILE au script hook /root/backup-to-gdrive.sh. Ce dernier interroge la configuration de l’invité pour extraire son identifiant et son nom d’hôte, puis effectue une copie unitaire par rclone copy vers le répertoire cible sur Google Drive. Ce modèle garantit l’autonomie complète de chaque archive, évite la saturation des disques locaux de pve1 et pve2 et élimine les blocages d’API constatés avec les montages FUSE directs.

Étapes

1. Décommissionnement de l’ancien stockage FUSE gdrive-backup

L’ancien stockage de type Directory gdrive-backup était partagé sur les trois nœuds (pve1, pve2, pve3) avec l’option is_mountpoint activée. Le montage FUSE rclone direct n’étant présent que sur pve3 (et instable), tout job de sauvegarde exécuté sur pve1 ou pve2 échouait immédiatement. Il convient de démonter l’ancien système de fichiers et de supprimer ce stockage dans Proxmox.

1. Démonter le système de fichiers rclone résiduel sur pve3
umount /mnt/gdrive

2. Vérifier qu’aucun processus de montage FUSE ne persiste
findmnt /mnt/gdrive
ps aux | grep -i "[r]clone mount"

Dans l’interface graphique Proxmox VE (Datacenter > Storage), sélectionner gdrive-backup puis cliquer sur Remove (ou en CLI via pvesm remove gdrive-backup).

2. Installation et configuration du serveur NFS sur pve3

Afin d’offrir un espace tampon centralisé commun à pve1, pve2 et pve3, le service NFS est installé sur pve3 pour partager un sous-dossier de son disque dur dédié de 1 To (hdd1to).

1. Vérifier le chemin physique du disque hdd1to sur pve3
grep -A4 "hdd1to" /etc/pve/storage.cfg

2. Installer le paquet nfs-kernel-server
apt update && apt install -y nfs-kernel-server

3. Créer le répertoire dédié aux sauvegardes de grappe
mkdir -p /mnt/pve/hdd1to/dump-cluster

4. Configurer l’export NFS restreint au sous-réseau du cluster
echo "/mnt/pve/hdd1to/dump-cluster 10.10.10.0/24(rw,sync,no_subtree_check,no_root_squash)" >> /etc/exports

5. Recharger la table d’exportation et démarrer le service
exportfs -ra
systemctl restart nfs-kernel-server
systemctl enable nfs-kernel-server

Attention — export sans root_squash. L’option no_root_squash permet à un compte root côté client d’exercer les droits root sur le partage exporté. Maintenir l’export restreint au sous-réseau 10.10.10.0/24 et ne pas élargir le CIDR d’exportation sans analyse de risque.

Vérifier que l’export est actif et correctement diffusé :

exportfs -v

3. Déclaration du stockage de grappe nfs-backups dans Proxmox VE

Le partage NFS est déclaré au niveau du Datacenter Proxmox VE afin d’être automatiquement monté et utilisable par l’ensemble des membres de la grappe.

Dans l’interface Web : Datacenter > Storage > Add > NFS :

• ID : nfs-backups

• Server : 10.10.10.12

• Export : /mnt/pve/hdd1to/dump-cluster (sélectionné dans la liste déroulante)

• Content : VZDump backup file (Backup)

• Nodes : All (No restrictions)

• Enable : Coché

Valider avec le bouton Add. Vérifier l’état opérationnel du stockage sur le cluster :

pvesm status | grep nfs-backups

4. Création du script hook VZDump intelligent (/root/backup-to-gdrive.sh)

Le script hook est appelé par le moteur VZDump lors des différentes phases de sauvegarde. Il filtre les phases finales (backup-end et log-end), extrait l’identité de l’invité (ID et nom d’hôte), compose l’arborescence cible sur Google Drive et exécute la copie unitaire par rclone avec journalisation.

cat << 'EOF' > /root/backup-to-gdrive.sh
#!/bin/bash

PHASE="$1"
MODE="$2"
VMID="$3"

Enregistrer les appels dans un log pour traçabilité d’exploitation
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Hook appelé : PHASE=$PHASE, MODE=$MODE, VMID=$VMID, TARFILE=$TARFILE" >> /var/log/vzdump-hook.log

Déclenchement lors de l’achèvement de la sauvegarde d’un invité
if [ "$PHASE" == "backup-end" ] || [ "$PHASE" == "log-end" ]; then
    if [ -n "$TARFILE" ] && [ -f "$TARFILE" ]; then
        NODE_NAME=$(hostname)
        
        # Récupération du nom de la machine virtuelle ou du conteneur
        GUEST_NAME=""
        if pct status "$VMID" &>/dev/null; then
            GUEST_NAME=$(pct config "$VMID" | awk '/^hostname:/ {print $2}')
        elif qm status "$VMID" &>/dev/null; then
            GUEST_NAME=$(qm config "$VMID" | awk '/^name:/ {print $2}')
        fi

        [ -n "$GUEST_NAME" ] && FOLDER_NAME="${VMID}-${GUEST_NAME}" || FOLDER_NAME="${VMID}"
        TARGET_DEST="gdrive:Backup Proxmox/${NODE_NAME}/${FOLDER_NAME}"

        echo "[$(date '+%Y-%m-%d %H:%M:%S')] Envoi de $TARFILE vers $TARGET_DEST" >> /var/log/vzdump-hook.log
        /usr/bin/rclone copy "$TARFILE" "$TARGET_DEST" --log-file=/var/log/rclone-backup.log --log-level=INFO
    fi
fi
EOF

chmod +x /root/backup-to-gdrive.sh

Activer le script globalement dans la configuration VZDump de pve3 :

grep -q "^script:" /etc/vzdump.conf && sed -i 's|^script:.*|script: /root/backup-to-gdrive.sh|' /etc/vzdump.conf || echo "script: /root/backup-to-gdrive.sh" >> /etc/vzdump.conf

5. Déploiement automatisé du dispositif sur l’ensemble du cluster

Pour que chaque nœud de la grappe (pve1 et pve2) puisse transférer ses archives vers Google Drive sans dépendre d’un montage distant, le binaire rclone, sa configuration authentifiée et le script hook sont déployés depuis pve3 via une boucle SSH.

for NODE in pve1 pve2; do
    echo "=== Configuration de $NODE ==="
    # 1. Vérification et installation de rclone
    ssh $NODE "which rclone >/dev/null 2>&1 || (apt update && apt install -y rclone)"
    
    # 2. Copie de la configuration rclone authentifiée
    ssh $NODE "mkdir -p /root/.config/rclone"
    scp /root/.config/rclone/rclone.conf $NODE:/root/.config/rclone/rclone.conf
    
    # 3. Déploiement et permission du script hook
    scp /root/backup-to-gdrive.sh $NODE:/root/backup-to-gdrive.sh
    ssh $NODE "chmod +x /root/backup-to-gdrive.sh"
    
    # 4. Déclaration dans vzdump.conf
    ssh $NODE "grep -q '^script:' /etc/vzdump.conf && sed -i 's|^script:.*|script: /root/backup-to-gdrive.sh|' /etc/vzdump.conf || echo 'script: /root/backup-to-gdrive.sh' >> /etc/vzdump.conf"
    
    # 5. Test fonctionnel de la liaison Google Drive
    echo "Test rclone sur $NODE :" 
    ssh $NODE "rclone lsd gdrive: | head -n 3"
    echo "=== $NODE terminé avec succès ! ==="
done

6. Configuration et validation du job de sauvegarde global

Dans l’interface Web Proxmox VE (Datacenter > Backup), configurer la tâche de sauvegarde dédiée à l’externalisation Google Drive :

• Node : — All — (exécution parallèle sur pve1, pve2 et pve3)

• Storage : nfs-backups (stockage centralisé de 1 To)

• Schedule : 23:00 (après la sauvegarde PBS quotidienne de 22:00)

• Selection mode : All (toutes les machines virtuelles et conteneurs)

• Mode : Snapshot

• Compression : ZSTD (fast and good)

• Retention : Fallback from storage config (ou keep-all=1)

7. Procédure de traitement des verrous et reprise d’incident

En cas d’interruption inopinée d’un job (coupure réseau, arrêt manuel forcé par kill/pkill), Proxmox conserve des verrous d’état sur les invités ou dans la file d’attente vzdump, provoquant des erreurs bloquantes lors des exécutions ultérieures. Appliquer les commandes de reprise suivantes sur le nœud concerné :

1. Tuer les processus vzdump suspendus ou orphelins
pkill -9 -f vzdump

2. Purger les fichiers de verrouillage résiduels
rm -f /var/run/vzdump*.lock

3. Déverrouiller un conteneur bloqué en état snapshot-delete (ex. CT 8010)
pct unlock 8010

4. Déverrouiller une machine virtuelle bloquée (ex. VM 2010)
qm unlock 2010

Retour arrière

Pièges connus

5 Intégration réseau

Identité des équipements et adressage

Matrice des flux réseau

Dépendances et points de défaillance

Point de défaillance NFS (pve3) : Le nœud pve3 centralise le stockage NFS hdd1to. Une indisponibilité de pve3 bloque les sauvegardes des trois nœuds vers le stockage nfs-backups. En contrepartie, les sauvegardes directes PBS (sur disque local pve3) et les machines virtuelles en fonctionnement sur pve1 et pve2 ne subissent aucun impact opérationnel.

Dépendance au transit WAN : La synchronisation vers Google Drive nécessite une connexion Internet opérationnelle. En cas de coupure de liaison WAN, les archives demeurent conservées localement sur le partage NFS sans bloquer la fin de tâche Proxmox.

6 Durcissement et sécurité

• Permissions strictes sur le script hook (0755 root:root) : garantit qu’aucun utilisateur non privilégié ne peut altérer le code exécuté avec les privilèges root par le moteur VZDump.

• Protection du fichier rclone.conf (0600 root:root) : interdit formellement la lecture des jetons d’accès OAuth2 et secrets d’API Google Drive par un processus tiers.

• Restriction CIDR de l’export NFS (10.10.10.0/24) : interdit toute tentative de montage du volume de sauvegarde depuis un sous-réseau extérieur ou non autorisé.

• Absence d’exposition réseau externe : le service nfs-kernel-server écoute uniquement sur le réseau local interne et n’est pas publié sur l’accès Internet.

• Aucun secret statique dans le code : le script hook ne contient aucun mot de passe en clair et s’appuie sur le mécanisme de rafraîchissement automatique de rclone.

Dettes techniques

7 Vérifications finales

8 Références et historique des révisions

Documentation éditeur

• Proxmox Server Solutions : Proxmox VE Administration Guide 9.2, Chapitre VZDump et gestion des scripts de hook (vzdump.conf).

• Proxmox Server Solutions : Storage Types – NFS Storage, configuration des points de montage et options partagées de grappe.

• Rclone Developers : Rclone Documentation – Google Drive backend, gestion des quotas d’appels API, transferts et variables d’environnement.

• Linux Network Administrators : NFS exports manual (man 5 exports), options sync, no_subtree_check et no_root_squash.

Documents associés

• HL-PRC-003 : Mise en service de la grappe Proxmox à trois nœuds.

• HL-PRC-009 : Proxmox Backup Server sur hôte Proxmox VE.

Historique des révisions