Proxmox Best Practice Partie 3 – Stratégies de sauvegarde: Conserver les données en toute sécurité

Bienvenue dans les meilleures pratiques pour votre serveur Proxmox ou votre cluster Proxmox, aujourd'hui, nous examinons le sujet de la sauvegarde en détail. Pour ce faire, nous avons besoin, comme vous le savez déjà, de nos collègues ici:

Proxmox Backup Server (PBS)

PBS est la solution de sauvegarde professionnelle de Proxmox et devrait certainement être sur votre radar. Les principaux avantages ne sont pas seulement les discours de marketing, mais font vraiment une différence dans la pratique:

déduplication: Les blocs de données identiques ne sont stockés qu’une seule fois, ce qui vous permet souvent d’économiser jusqu’à 90% Espace de stockage
Sauvegardes incrémentales: Seules les modifications sont sauvegardées, ce qui réduit considérablement vos temps de sauvegarde
chiffrement: Cryptage AES-256-GCM côté client - même si quelqu'un compromet votre serveur de sauvegarde
Limitation de bande passante: Vos sauvegardes s'exécutent en arrière-plan sans que les systèmes de production ne souffrent
Emplois chez Verify: Vérification automatique de l’intégrité – vous savez toujours si vos sauvegardes sont réellement utilisables
Politiques de rétention: Des règles de suppression intelligentes vous permettent de ne pas sombrer dans le chaos de la sauvegarde
GUI web: Une interface utilisateur moderne qui est vraiment amusant à utiliser

Configuration PBS (configuration de base)

Exigences matérielles et planification

Avant de commencer, réfléchissez au hardware. Un serveur PBS est aussi bon que le matériel sur lequel il fonctionne. Voici des exigences minimales réalistes qui ont fait leurs preuves dans la pratique:

Recommandations matérielles minimales pour PBS:

CPU: 4 cœurs (plus si vous voulez sauvegarder plusieurs machines virtuelles en parallèle)
RAM : 8GB minimum absolu, 16GB+ si vous voulez faire « sérieux »
Stockage: Un SSD rapide pour les métadonnées, de grands disques durs pour les données de sauvegarde réelles
Réseau: Gigabit Ethernet comme minimum le plus bas, mieux 2,5 ou 5 GBE et 10GbE si vous déplacez constamment de grandes quantités de données

L'installation elle-même est agréablement simple. Vous devriez certainement installer PBS sur un serveur physique distinct – un PBS virtualisé sur le même cluster Proxmox qu’il est censé sécuriser est comme avoir un extincteur vide dans la maison en feu. ⁇

# Proxmox Backup Server Repository ajouter echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" > /etc/apt/sources.list.d/pbs.list wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg apt update && apt install proxmox-up-server # Première configuration - créer un utilisateur admin proxmox-backup-manager user create backup@pbs --email admin@example.com proxmox-backup-manager acl update / Backup@pbs --role Admin

Optimiser la configuration du stockage

La configuration du stockage est au cœur de votre système de sauvegarde. Ici, il vaut la peine d'investir un peu de temps. ZFS est souvent le meilleur choix ici, car il vous permet d'obtenir des instantanés, de la compression et du checksumming out-of-the-box. Nous en avons déjà parlé en détail dans la deuxième partie (stockage).

# Créer un pool ZFS pour des performances optimales # Reflète deux disques et utilise NVMe pour le cache et le log zpool create backup-pool \ mirror /dev/sdb /dev/sdc \ cache /dev/nvme0n1p1 \ log /dev/nvme0n1p2 # Datastore avec des paramètres de rétention bien pensés proxmox-backup-manager datastore create backup-storage /backup-pool/data \ --gc-schedule 'daily' \ --prune-schedule 'daily' \ --keep-daily 7 \ --keep-weekly 4 \ --keep-monthly 12 \ --keep-yearly 2 \ --notify-user backup@pbs

Configurer les tâches de sauvegarde

Configuration de base

Maintenant, c’est intéressant – les véritables emplois de sauvegarde. C'est ici que vous décidez si votre système de sauvegarde deviendra un compagnon fiable ou une source de frustration constante!

La variante CLI vous donne beaucoup plus de contrôle sur les paramètres. La limitation de la bande passante est particulièrement importante! Parce que personne ne veut que les sauvegardes paralysent le reste du réseau.

# Emploi de sauvegarde avec tous les paramètres importants pvesh create /cluster/backup \ --schedule "02:00" \ --storage backup-pbs \ --mode snapshot \ --all 1 \ --compress zstd \ --protected 1 \ --notes-template "{{cluster}}: {{guestname}} - {{job-id}}" \ --mailnotification always \ --mailto admin@example.com \ --bwlimit 50000 # Limite de bande passante de 50 Mo/s

Alternativement, vous pouvez également le faire facilement via l'interface Web: Datacenter → Backup → Add. C'est souvent plus clair, surtout pour les débutants.

Les paramètres importants expliqués

Ces paramètres sont essentiels au bon fonctionnement d'un système de sauvegarde, c'est pourquoi voici les plus importants en détail:

Schedule: Ici, vous utilisez le format cron standard. 0 2 * * * signifie tous les jours à 2h00. Planifiez vos temps de sauvegarde de manière à ce qu'ils n'entrent pas en conflit avec d'autres tâches nécessitant beaucoup de maintenance.

mode: Voici trois options qui ont toutes leurs avantages et leurs inconvénients:

snapshot: La machine virtuelle continue de fonctionner, vous obtenez un instantané cohérent. Idéal pour les systèmes de production.
Suspension: La VM est brièvement mise en pause. Cohérence maximale, mais brève interruption.
stop: VM s'arrête. Recommandé uniquement pour les systèmes non critiques.

Compress: Ici, vous devez équilibrer la vitesse et l'efficacité:

lz4 est rapide et nécessite peu de CPU, mais compresse moins
zstd compresse beaucoup mieux, mais a besoin de plus de puissance de calcul

Protected: Protège la sauvegarde contre la suppression accidentelle. Vous devez toujours l'activer pour les sauvegardes importantes.

BWLimit: Limite de bande passante en Ko/s. 50000 correspond à environ 50 Mo/s – adaptez-le à votre infrastructure réseau.

Activer la vérification de sauvegarde

Une sauvegarde sans vérification est comme un parachute sans certificat de test: vous ne réalisez pas que cela ne fonctionne pas lorsque vous en avez vraiment besoin, ce qui peut être trop tard dans le pire des cas. PBS vous aide car il peut vérifier automatiquement l'intégrité de vos sauvegardes.

# Emploi Verify pour l'intégrité de sauvegarde automatique pvesh create /admin/verify \ --store backup-storage \ --schedule 'weekly' \ --outdated-after 7 \ --ignore-verified

Le travail Verify fonctionne une fois par semaine et vérifie toutes les sauvegardes de plus de 7 jours. Les sauvegardes déjà vérifiées sont ignorées pour gagner du temps.

Mettre en œuvre la règle de sauvegarde 3-2-1

Comprendre la règle 3-2-1

La règle 3-2-1 n'est pas seulement un gag marketing, mais une pratique éprouvée de décennies d'expérience en matière de perte de données. Elle est libellée comme suit:

3 Copies de vos données (1 original + 2 sauvegardes)
2 différents supports/types de stockage (pas tous sur la même technologie)
1 Sauvegarde hors site (séparée géographiquement – incendie, inondation, vol)

Mise en œuvre pratique

Dans un environnement Proxmox typique, cela pourrait ressembler à ceci:

Données primaires: Sur votre serveur Proxmox avec ZFS et redondance
Sauvegarde locale: Sur le serveur PBS dans le même centre de données/bureau
Sauvegarde hors site: Synchronisation PBS vers un site externe ou un fournisseur de cloud

La configuration à distance est relativement straightforward, mais vous devez faire attention à la connexion réseau. Une connexion instable peut faire de vos tâches de synchronisation un cauchemar.

# Configuration de la sauvegarde à distance - L'empreinte digitale provient du serveur cible pvesh create /admin/remote \ --name offsite-backup \ --host backup.external.com \ --userid backup@pbs \ --password "secure_password" \ --fingerprint AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD # Emploi de synchronisation avec limite de bande passante - fonctionne la nuit quand il se passe peu de choses pvesh create /admin/sync \ --remote offsite-backup \ --remote-store production \ --store local-backup \ --schedule "04:00" \ --rate-in 10000 \ --burst-in 15000 \ --comment "Synchronisation hors site nocturne"

Stratégies de sauvegarde avancées

Configuration de la rétention de sauvegarde

Les politiques de rétention sont souvent sous-estimées, mais extrêmement importantes. Sans règles judicieuses, vous accumulez des gigaoctets d'anciennes sauvegardes dont personne n'a plus besoin au fil des ans. En même temps, vous ne voulez pas supprimer accidentellement la seule sauvegarde viable du mois dernier.

Une stratégie éprouvée est la méthode «grand-père-père-fils»: beaucoup de nouvelles sauvegardes, moins anciennes, très peu anciennes. PBS le fait automatiquement pour vous.

# Configurer une politique de rétention réfléchie proxmox-backup-manager datastore update backup-storage \ --keep-last 3 \ # Toujours garder les 3 dernières sauvegardes (urgences) --keep-hourly 24 \ # 24 sauvegardes toutes les heures (dernier jour) --keep-daily 7 \ # 7 sauvegardes quotidiennes (la semaine dernière) --keep-weekly 4 \ # 4 sauvegardes hebdomadaires (le mois dernier) --keep-monthly 12 \ # 12 sauvegardes mensuelles (l'année dernière) --keep-yearly 5 # 5 sauvegardes annuelles (archivage à long terme)

Gestion de bande passante

Dans les environnements de production, vous devez souvent gérer une bande passante limitée. Les sauvegardes ne doivent pas ralentir les systèmes de production, mais elles ne doivent pas durer éternellement. Le Traffic Shaping vous aide à trouver le bon équilibre.

# Configurer le trafic sur le serveur PBS tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 800mbit ceil 1000mbit tc class add dev eth0 parent 1:1 classid 1:20 htb rate 200mbit ceil 400mbit # Classer le trafic de sauvegarde dans la classe la plus lente iptables -A OUTPUT -p tcp --dport 8007 -j CLASSIFY --set-class 1:20

Cette configuration est réservée 80% la bande passante pour le trafic normal et limite les sauvegardes à un maximum de 40% – avec la possibilité d’utiliser le trafic inutilisé.

Intégration de sauvegarde avec le stockage

Optimisations spécifiques au stockage

Différents types de stockage ont des forces différentes. Utilisez-le à votre avantage en stockant des métadonnées et de gros blocs de données sur différents supports.

# Magasins de données séparés pour différentes exigences # NVMe rapide pour les métadonnées et les petits fichiers proxmox-backup-manager datastore create vm-backups-meta \ /nvme/backup-meta \ --gc-schedule 'daily' \ --prune-schedule 'daily' # Grand RAID pour les données de sauvegarde réelles proxmox-backup-manager datastore create vm-backups-data \ /raid/backup-data \ --gc-schedule 'weekly' \ --keep-daily 14 \ --keep-weekly 8 \ --keep-monthly 24 # Le travail de sauvegarde des fichiers inutiles exclut pvesh create /cluster/backup \ --schedule "02:00" \ --storage backup-pbs \ --mode snapshot \ --compress zstd \ --notes-template "{cluster}}: {{guestname}} ({{mode}})" \ --protected 1 \ --exclude-path "/tmp/*,/var/log/*,/var/cache/*" # Économise de l'espace et du temps

Stratégies de sauvegarde par type de stockage

LVM-Thin snapshots

Les volumes légers LVM sont largement utilisés et offrent une fonctionnalité d'instantané simple. L’astuce consiste à conserver les snapshots aussi longtemps que vous en avez vraiment besoin, ce qui peut nuire aux performances.

# Sauvegarde instantanée LVM automatisée avec gestion des erreurs create_lvm_backup() { local vmid=$1 local disk_path="/dev/pve/vm-${vmid}-disk-0" local snap_name="vm-${vmid}-snap-$(date +%Y%m%d-%H%M%S)" echo "Créer une sauvegarde pour VM $vmid... » # Vérifier s'il y a suffisamment d'espace pour le snapshot if ! lvcreate --test --snapshot --name $snap_name --size 10G $disk_path; then echo "Erreur: Pas assez d'espace pour les snapshots!" return 1 fi # Créer un instantané - est quasi instantané lvcreate --snapshot --name $snap_name --size 10G $disk_path # Sauvegarde du snapshot avec indicateur de progression dd if=/dev/pve/$snap_name bs=64k status=progress | \ gzip -c > /backup/vm-${vmid}-$(date +%Y%m%d).img.gz # Supprimer immédiatement le snapshot pour obtenir des performances lvremove -f /dev/pve/$snap_name echo "Sauvegarde pour VM $vmid terminé." } # Utilisation pour VM 100: # create_lvm_backup 100

Snapshots ZFS

ZFS est beaucoup plus élégant ici: les snapshots ne coûtent pratiquement rien et vous pouvez faire des sauvegardes incrémentales. Cela permet d'économiser énormément de temps et de bande passante, en particulier sur les grandes machines virtuelles.

# Stratégie de sauvegarde incrémentale ZFS intelligente zfs_incremental_backup() { local dataset=$1 local remote_host=$2 local current_snap="${dataset}@backup-$(date +%Y%m%d-%H%M%S)" local last_snap=$(zfs list -t snapshot -o name -s creation | grep ${dataset}@ | tail -1) echo "Créer ZFS Backup pour $dataset... » # Créer un nouvel instantané - prend des millisecondes zfs snapshot $current_snap if [ -n "$last_snap" ]; then echo "Send incremental backup depuis $last_snap » # Transférer uniquement les modifications - beaucoup plus rapide zfs send -i $last_snap $current_snap | \ ssh $remote_host "zfs receive -F backup/${dataset##*/}" else echo "Send initial full backup" # La première sauvegarde est toujours entièrement zfs send $current_snap | \ ssh $remote_host "zfs receive backup/${dataset##*/}" fi # Nettoyer les snapshots - gardez seulement les 7 derniers local old_snaps=$(zfs list -t snapshot -o name -s creation | grep ${dataset}@ | head -n -7) if [ -n "$old_snaps" ]; then echo "Effacer les vieux snapshots..." echo "$old_snaps" | while read snap; do zfs destroy $snap done fi echo "Sauvegarde ZFS pour $dataset terminé. » } # Automatisation pour tous les jeux de données de machine virtuelle zfs_replicate_all() { echo "Démarrer la réplication ZFS pour toutes les machines virtuelles..." for dataset in $(zfs list -H -o name | grep "tank/vm-"); do zfs_incremental_backup $dataset backup-server.local done echo "Réplication ZFS terminée." }

Surveillance et Alerting

Surveiller l'état de sauvegarde

Un système de secours sans surveillance est comme un détecteur de fumée sans piles – vous ne réalisez pas qu’il ne fonctionne pas tant qu’il n’est pas trop tard. Il est donc important de mettre en place des contrôles automatiques.

# Script pour la surveillance de l'état de sauvegarde #!/bin/bash check_backup_status() { echo "Vérifier l'état de la sauvegarde..." # Rechercher des emplois ayant échoué dans les dernières 24h local failed_jobs=$(pvesh get /cluster/backup --output-format json | \ jq -r '.[] | select(.state == "error") | .id') if [ -n "$failed_jobs" ]; then echo "ALARM: Les tâches de sauvegarde ont échoué: $failed_jobs » # Envoyer un e-mail echo "Jobs de sauvegarde $failed_jobs a échoué. S'il vous plaît vérifier!" | \ mail -s "BACKUP FAILURE ALERT" admin@example.com # En option: Alerte au système de surveillance curl -X POST "https://monitoring.example.com/alert" \ -H "Type de contenu: application/json" \ -d "{\"message\":\"Backup failures: $failed_jobs\", \"severity\":\"critical\"}" return 1 else echo "Tous les travaux de sauvegarde fonctionnent normalement." return 0 fi } # Exécuter un travail cron toutes les 2 heures # 0 */2 * * * * /usr/local/bin/check_backup_status.sh

Proxmox Backup Server Health Check

Des bilans de santé réguliers vous aident à identifier les problèmes avant qu'ils ne deviennent critiques. Gardez un œil sur l'espace de stockage, les performances et l'état du service. Cela pourrait ressembler à ceci:

# Examen de santé complet PBS pbs_health_check() { echo "=== PBS Health Check $(date) ===" # État du magasin de données et espace de stockage echo "--- État du magasin de données ---" proxmox-backup-manager datastore list echo "--- Espace de stockage ---" df -h | grep -E "(backup|pbs)" | while read line; do usage=$(Echo $ligne | awk '{print $5}' | tr -d '%') if [ $usage -gt 85 ]; then echo "Attention: $ligne - magasin presque plein!" else echo "OK: $line" fi done # Processus en cours echo "--- Processus de sauvegarde active ---" local active_jobs=$(ps aux | grep -E "(proxmox-backup|pbs)" | grep -v grep | wc -l) echo "Emplois actifs: $active_jobs » # Verify Jobs Status echo "--- Verify Jobs Status ---" pvesh get /admin/verify --output-format json | \ jq -r '.[] | "Job \(.id): \(.state) (dernière version: \(.last_run_endtime // "jamais")""" # Tester les performances réseau vers des cibles distantes echo "---- Tests réseau ---" if command -v iperf3 > /dev/null; then echo "Tester la bande passante vers les cibles de sauvegarde..." # iperf3 -c backup-remote.com -t 10 -f M fi echo "=== Health Check Fin ===" }

Planification de la reprise après sinistre

Restauration complète du système

Le jour viendra où vous devrez restaurer votre système complet. Ça n’arrive jamais, c’est toujours la première fois. La préparation est essentielle: testez régulièrement vos plans de reprise après sinistre dans un environnement isolé.

# Restauration complète du cluster après une panne totale restore_cluster() { local backup_location=$1 echo "Démarrer la récupération de cluster à partir de $backup_location » # 1. Préparer une nouvelle installation Proxmox echo "Étape 1: Système de base installé (étape manuelle)" # 2. Restaurer la configuration du cluster echo "Étape 2: Restaurer la configuration du cluster..." if [ -f "$backup_location/cluster-config.tar.gz" ]; then tar -xzf "$backup_location/cluster-config.tar.gz" -C /etc/pve/ systemctl reload pve-cluster fi # 3. Restaurer la configuration du stockage echo "Étape 3: Restaurer les pools de stockage..." # Ici, vous devez ajuster votre configuration de stockage spécifique # 4. Récupérer les machines virtuelles individuellement echo "Étape 4: Récupération de VM..." if [ -f "$backup_location/vm-list.txt" ]; then while read vmid; do echo "Récupérer VM $vmid..." local backup_file="$backup_location/vm-${vmid}-latest.vma.gz" if [ -f "$backup_file" ]; then qmrestore "$backup_file » $vmid --storage local-lvm echo "VM $vmid récupéré" else echo "AVERTISSEMENT: Sauvegarde pour VM $vmid introuvable!" fi done < "$backup_location/vm-list.txt" fi echo "Récupération de cluster terminée. S'il vous plaît vérifier les services!" }

Automatiser la validation de sauvegarde

Est-ce que j'en avais parlé aujourd'hui? Peu importe, on ne peut pas dire assez souvent: Des tests réguliers de vos sauvegardes sont indispensables. Rien n'est plus frustrant que de ne détecter une sauvegarde corrompue qu'en cas d'urgence.

Le PBS valide automatiquement pour vous, mais s'appuie sur 100% Je pense aussi qu'il est difficile de partir. Au moins, vous devriez envisager d'effectuer des restaurations réelles de temps en temps, par exemple via votre environnement de test/staging, seulement alors vous pouvez vraiment dormir tranquillement.

# Test de sauvegarde automatisé avec test-VM backup_validation() { local test_vmid=9999 # Réserver l'ID de machine virtuelle pour les tests local datastore="backup-storage" echo "Démarrer la validation de sauvegarde..." # Trouver la dernière sauvegarde local latest_backup=$(proxmox-backup-client list --repository $datastore | \ grep "vm/$test_vmid" | sort -r | head -1 | awk '{print $1}') if [ -z "$latest_backup" ]; then echo "Aucune sauvegarde trouvée pour la VM de test, utilisez n'importe quelle sauvegarde de VM" latest_backup=$(proxmox-backup-client list --repository $datastore | \ grep "vm/" | head -1 | awk '{print $1}') fi if [ -z "$latest_backup" ]; then echo "ERREURS: Aucune sauvegarde trouvée!" return 1 fi echo "Tester la sauvegarde: $latest_backup » # Récupération de test (sans démarrage) if qmrestore --archive "$datastore:backup/$latest_backup » $test_vmid --storage local-lvm; then echo "Récupération réussie, testez le démarrage de la machine virtuelle..." # VM test pour démarrer qm start $test_vmid sleep 30 if m2 statut $test_vmid | grep -q "running"; then echo "SUCCESS: Validation de sauvegarde réussie - VM démarre correctement" qm stop $test_vmid qm destroy $test_vmid --purge return 0 else echo "ERREUR: VM ne démarre pas après la récupération" qm destroy $test_vmid --purge return 1 fi else echo "ERREUR: Échec de la récupération" return 1 fi }

Optimisation des performances

Réglage des performances de sauvegarde

Le réglage des performances des sauvegardes est souvent un équilibre entre la vitesse, la charge du système et l'impact du réseau. Voici les paramètres éprouvés pour différents scénarios.

# Optimiser les paramètres de sauvegarde à l'échelle du centre de données (Homelab) # /etc/pve/datacenter.cfg max_workers: 3 # Pas plus de 3 tâches de sauvegarde parallèles bandwidth_limit: 200 # Bande passante totale de 200 Mo/s pour tous les travaux ionice: 7 # Priorité d'E/S la plus basse (0-7) lockwait: 180 # Attendre 3 minutes pour les serrures

Ces paramètres empêchent vos sauvegardes de surcharger les systèmes de production. Avec un matériel plus puissant, vous pouvez ajuster les valeurs en conséquence, les données de l'exemple ci-dessus sont une configuration Homelab plutôt simple sans matériel serveur performant. Sur un serveur relativement récent, par exemple, cela pourrait ressembler à ceci:

# Optimiser les paramètres de sauvegarde à l'échelle du centre de données (serveur) # /etc/pve/datacenter.cfg max_workers: 6 # Pas plus de 6 tâches de sauvegarde parallèles bandwidth_limit: 1500 # 1500 Mo/s de bande passante totale pour tous les travaux (NvME Storage) ionice: 4 # Priorité d'E/S moyenne (0-7) lockwait: 60 # Attendre 1 minute pour les serrures

Optimisations spécifiques au stockage

Différentes technologies de stockage nécessitent différentes optimisations. Ce qui est bon pour les SSD NVMe peut être contre-productif avec les disques durs rotatifs. Voici quelques exemples:

# Optimiser les planificateurs d'E/S pour différents types de stockage # Pour les SSD NVMe: mq-deadline est généralement optimal echo mq-deadline > /sys/block/nvme0n1/queue/scheduler # Pour les SSD SATA: none ou mq-deadline echo none > /sys/block/sda/queue/scheduler # Pour les disques durs rotatifs: bfq ou cfq echo bfq > /sys/block/sdb/queue/scheduler # Readahead pour optimiser les accès séquentiels à grande échelle blockdev --setra 4096 /dev/sda # 2MB readahead # Souvent utile pour les charges de travail de sauvegarde echo 32 > /sys/block/sda/queue/nr_requests

Dépannage des problèmes courants

Suspendre les jobs de sauvegarde

Les tâches de sauvegarde suspendues sont un problème classique. La plupart du temps, cela est dû à des verrouillages, à des problèmes de réseau ou à des systèmes de stockage surchargés.

# Identifier et gérer les jobs suspendus find_hanging_jobs() { echo "Rechercher des jobs de sauvegarde suspendus..." # Trouver des processus vzdump de longue durée ps aux | grep vzdump | grep -v grep | while read line; do pid=$(Echo $ligne | awk '{print $2}') runtime=$(ps -o etime= -p $pid | tr -d ' ') echo "Job PID $pid est en cours d'exécution depuis: $runtime » # Les emplois qui durent plus de 6 heures sont suspects if [[ $runtime =~ ^[0-9][0-9]:[0-9][0-9]:[0-9][0-9]$ ]]; then echo "Attention: Emploi $pid fonctionne très longtemps!" fi done # Vérifier les fichiers de verrouillage if [ -f /var/lock/vzdump.lock ]; then echo "Vzdump-Lock trouvé, vérifier le processus..." local lock_pid=$(cat /var/lock/vzdump.lock) if ! kill -0 $lock_pid 2>/dev/null; then echo "Lock-File est orphelin, supprimez-le..." rm /var/lock/vzdump.lock fi fi } # Nettoyage d'urgence pour les systèmes complètement suspendus emergency_backup_cleanup() { echo "NOTFALL: Terminez tous les processus de sauvegarde!" killall -9 vzdump killall -9 proxmox-backup-client rm -f /var/lock/vzdump.lock rm -f /tmp/vzdumptmp* echo "Cleanup terminé - vérifie les journaux!" }

Gestion de l'espace de stockage

Les magasins de données de sauvegarde complets sont également un problème courant. Garbage Collection et Pruning devraient fonctionner automatiquement, mais parfois vous devrez toujours intervenir manuellement.

# Diagnostiquer et résoudre les problèmes d'espace disque storage_cleanup() { local datastore=$1 echo "Analyse de l'espace de stockage pour $datastore... » # Consommation de mémoire actuelle df -h $(proxmox-backup-manager datastore list | grep $datastore | awk '{print $3}') # Trouver les plus grands groupes de sauvegarde echo "Les plus grands groupes de sauvegarde:" du -sh /backup/$datastore/* | sort -hr | head -10 # Garbage Collection manuellement exécuter echo "Démarrer Garbage Collection..." proxmox-backup-manager garbage-collect $datastore # Chunks orphelins trouver echo "Recherche Chunks orphelins..." proxmox-backup-manager datastore verify $datastore # Espace disque après nettoyage echo "Espace disque après nettoyage:" df -h $(proxmox-backup-manager datastore list | grep $datastore | awk '{print $3}') # Exécuter les tâches Prune manuellement si elle ne s'exécute pas automatiquement echo "Exécuter les tâches Prune..." proxmox-backup-client prune --repository $datastore \ --keep-daily 7 --keep-weekly 4 --keep-monthly 12 } # Surveillance de la mémoire avec Alerts monitor_storage_space() { for datastore in $(proxmox-backup-manager datastore list | awk 'NR>1 {print $1}'); do local path=$(proxmox-backup-manager datastore list | grep $datastore | awk '{print $3}') usage local=$(df "$path" | awk 'NR==2 {print $5}' | tr -d '%') echo "Datastore $datastore: ${usage}% occupé" if [ $usage -gt 90 ]; then echo "CRITIQUE: $Datastore plus de 90% plein ! » # Ici, vous pouvez supprimer automatiquement les anciennes sauvegardes elif [ $usage -gt 80 ]; then echo "Attention: $Datastore plus de 80% plein" fi done }

Diagnostiquer les problèmes de réseau

Les problèmes de réseau peuvent également être à l'origine de sauvegardes lentes ou infructueuses. Voici des outils et des techniques pour vous aider à diagnostiquer.

# Diagnostic réseau complet pour les connexions de sauvegarde network_backup_diagnosis() { local target_host=$1 echo "=== Diagnostic de réseau pour $target_host ===" # Accessibilité de base echo "--- Test de ping ---" if ping -c 5 $target_host > /dev/null; then echo "Hôte $target_host est accessible" ping -c 5 $target_host | tail -1 else echo "ERREUR: hôte $target_host inaccessible!" return 1 fi # Test de bande passante avec iperf3 echo "---- Test de bande passante ---" if command -v iperf3 > /dev/null; then echo "Tester la bande passante $target_host..." timeout 30s iperf3 -c $target_host -t 20 -f M 2>/dev/null | \ grep "sender" | awk '{print "Upload: " $7 " $8}' timeout 30s iperf3 -c $target_host -t 20 -f M -R 2>/dev/null | \ grep "receiver" | awk '{print "Télécharger: " $7 " $8}' else echo "iperf3 non installé - installer avec: apt install iperf3" fi # Test de latence echo "--- Analyse de latence ---" local avg_latency=$(ping -c 100 $target_host | tail -1 | awk -F'/' '{print $5}') echo "Latence moyenne: ${avg_latency}ms" if (( $(Echo "$avg_latency > 100" | bc -l) )); then echo "Attention: Une latence élevée pourrait affecter les performances de sauvegarde" fi # Disponibilité du port pour PBS echo "---- Essais de port ---" for port in 8007 8008; do if timeout 5s bash -c "</dev/tcp/$target_host/$port"; then echo "Port $port: OUVERTE" else echo "Port $port: Fermé ou filtré" fi done # MTU-Discovery echo "--- Test MTU ---" pour la taille en 1472 1500 9000; do if ping -c 1 -M do -s $size $target_host > /dev/null 2>&1; then echo "MTU $Taille : OK" else echo "MTU $Taille : Fragmentation nécessaire" fi done }

Problèmes de certificat SSL/TLS

PBS utilise HTTPS pour toutes les connexions. Les problèmes de certificat sont une pierre d'achoppement courante, en particulier pour les certificats auto-signés.

# Diagnostic et réparation du certificat SSL check_pbs_certificates() { local pbs_host=$1 echo "=== Vérification du certificat SSL pour $pbs_host ===" # Obtenir les détails du certificat echo "--- Informations sur le certificat ---" local cert_info=$(echo | openssl s_client nom du serveur $pbs_host -connect $pbs_host:8007 2>/dev/null | \ openssl x509 -noout -dates -subject -issuer) echo "$cert_info » # Vérifier la validité du certificat local expiry_date=$(Echo "$cert_info" | grep "notAfter" | cut -d'=' -f2) local expiry_seconds=$(date -d "$expiry_date" +%s) local now_seconds=$(date +%s) local days_until_expiry=$(( (expiry_seconds - now_seconds) / 86400 ))) echo "Le certificat expire dans: $days_until_expiry jours" if [ $days_until_expiry -lt 30 ]; then echo "Attention: Le certificat expire bientôt!" fi # Empreinte digitale pour la configuration à distance echo "--- Empreinte digitale pour la configuration à distance ---" local fingerprint=$(echo | openssl s_client nom du serveur $pbs_host -connect $pbs_host:8007 2>/dev/null | \ openssl x509 -noout -fingerprint -sha256 | cut -d'=' -f2) echo "Fingerprint: $empreinte digitale » } # Générer un nouveau certificat auto-signé regenerate_pbs_certificate() { local pbs_host=$1 echo "Générer un nouveau certificat auto-signé pour $pbs_host..." # Sauvegarde de l'ancien certificat cp /etc/proxmox-backup/proxy.pem /etc/proxmox-backup/proxy.pem.backup.$(date +%Y%m%d) # Créer un nouveau certificat openssl req -x509 -newkey rsa:4096 -keyout /tmp/proxy.key -out /tmp/proxy.crt \ -days 3650 -nodes -subj "/CN=$pbs_host" # Combiner le certificat et la clé cat /tmp/proxy.crt /tmp/proxy.key > /etc/proxmox-backup/proxy.pem # Supprimer les fichiers temporaires rm /tmp/proxy.key /tmp/proxy.crt # Service redémarrer systemctl restart proxmox-backup-proxy echo "Nouveau certificat installé. Nouvelle empreinte digitale:" check_pbs_certificates $pbs_host | grep "Fingerprint:" }

Meilleures pratiques TL:DR

C'est quelque chose que vous devez absolument garder à l'esprit

Voici les points clés qui déterminent le succès ou l'échec de votre système de sauvegarde:

Matériel & Infrastructure:

PBS toujours sur du matériel séparé – jamais sur le système que vous sécurisez
RAM suffisante pour la déduplication (minimum 16 Go pour les environnements de production)
SSD rapides pour les métadonnées, disques durs volumineux pour les données de sauvegarde
Connexions réseau redondantes si possible

Configuration :

Configurer correctement les politiques de rétention dès le départ – c’est fastidieux après coup
Activer la limitation de bande passante pour ne pas interférer avec les systèmes de production
Configurer des jobs Verify – une sauvegarde non testée n’est pas une sauvegarde
Activer les notifications par e-mail pour tous les événements critiques

Suivi:

Contrôles de santé automatiques au moins tous les jours
Surveillance du stockage avec alertes >80% occupation
Récupérations d'essais régulières dans un environnement isolé
Vérifier régulièrement les fichiers journaux – prendre au sérieux les alertes

Sécurité:

Activer le chiffrement côté client pour les données sensibles
Identifiants distincts pour les utilisateurs de sauvegarde – pas de droits d’administrateur
Règles de pare-feu uniquement pour les ports nécessaires (8007, 8008)
Sauvegardes hors site avec transfert sécurisé (clés SSH au lieu de mots de passe)

Éviter les erreurs courantes des débutants

L’erreur «PBS virtualisé»: Ne jamais exécuter PBS sur le même cluster Proxmox qu'il doit sauvegarder. C'est comme une ceinture de sécurité en chewing-gum.

La mentalité «Set and Forget»: Les sauvegardes nécessitent des soins réguliers. Vérifiez au moins une fois par mois si tout se passe bien.

Absence de limite de bande passante: Les tâches de sauvegarde sans limites peuvent paralyser votre réseau de production.

Aucune récupération d'essai: Vous ne saurez pas si vos sauvegardes fonctionneront tant que vous ne les testerez pas. La loi de Murphy s’applique particulièrement aux sauvegardes. ⁇

Politiques de rétention peu claires: Définissez dès le début combien de temps vous voulez garder quelque chose. Les archives de sauvegarde qui ne cessent de croître sont un cauchemar.

Avec ces bases, vous avez une base solide pour votre système de sauvegarde Proxmox. Investissez votre temps dans une bonne configuration – je dis que votre avenir vous en sera reconnaissant, soit par un sommeil calme et détendu, soit au plus tard lors de la première urgence.

Achèvement et ressources supplémentaires

Proxmox est un outil puissant, mais avec une grande puissance vient aussi une grande responsabilité. (clin d'œil) Les meilleures pratiques présentées ici sont le résultat d'une expérience pratique. Commencez par les bases et avancez progressivement vers les fonctionnalités avancées.

Vos prochaines étapes:

Construire un environnement de test/staging: Teste toutes les configurations dans un environnement séparé
Mettre en œuvre le monitoring: Surveillez votre système dès le début
Tester la stratégie de sauvegarde: Effectue des tests de restauration réguliers
Rejoindre la communauté: Le forum Proxmox est très utile

Alors rappelez-vous ceci: Prenez le temps, les bases Comprendre avant de Des configurations plus complexes passe. Le Guide d'administration Proxmox En tant que site Web que j'ai lié à plusieurs reprises dans l'article pour référence, il vaut également la peine d'or. Regardez-vous tranquillement sur le forum, Si vous avez une question. Sinon, il y a aussi un point d'entrée Chaîne Youtube.

Les autres parties de cette série d'articles, je vous les ai reliées ici: Partie 1: réseau | Deuxième partie: Stockage | Troisième partie: Sauvegarde | Partie 4 : sécurité | Cinquième partie: performance