Analyse Stratégique : Optimisation Infrastructure Backup¶

Date : 2026-01-XX
Contexte : Suite harmonisation backup LXC 103, analyse opportunités amélioration stratégie globale

Question 1 : Faut-il sauvegarder le LXC 102 via PBS ?¶

État Actuel¶

PBS sauvegarde :

• ✅ LXC 100 (docker-media) - 03:00 quotidien, 7/4/3 jours/semaines/mois
• ✅ LXC 101 (docker-management) - 03:00 quotidien, 7/4/3
• ✅ LXC 103 (network-gateway) - 03:00 quotidien, 7/4/3
• ❌ LXC 102 (pbs) - PAS SAUVEGARDÉ

Rôle LXC 102 :

• Serveur PBS (Proxmox Backup Server)
• Orchestrateur backup centralisé (rclone, scripts)
• Gère uploads Google Drive
• Point unique défaillance infrastructure backup

Risques Identifiés¶

Impact cumulé : ÉLEVÉ - La perte de LXC 102 nécessite reconstruction manuelle complète infrastructure backup.

Analyse Avantages/Inconvénients¶

✅ AVANTAGES d'ajouter LXC 102 au PBS :

1. Cohérence architecture : Tous LXC Docker sauvegardés (100/101/103) → logique étendre à 102
2. Disaster Recovery complet : PBS peut restaurer sa propre config depuis snapshot
3. Protection configuration : Scripts, rclone config, PBS datastores sauvegardés
4. Restauration rapide : pct restore au lieu reconfiguration manuelle
5. Versioning : Historique modifications config PBS (7 jours)

❌ INCONVÉNIENTS :

1. Circularité conceptuelle : PBS se sauvegarde lui-même (philosophiquement étrange mais fonctionnel)
2. Espace disque : +quelques GB sur datastore PBS (négligeable vs 103 avec NPM/Authelia/WireGuard)
3. Charge CPU : Backup supplémentaire à 03:00 (faible impact, LXC 102 léger)
4. Limitation : Si datastore PBS corrompu, snapshot LXC 102 affecté (mais configs externalisées Google Drive)

Évaluation Technique¶

Taille estimée LXC 102 : ~2-3 GB (OS + PBS + scripts)
Datastore disponible : À vérifier (pvesm status)
Impact performance : Négligeable (backup 1 LXC additionnel ~5-10 min)

Circularité gérée par :

• Snapshot LXC 102 → datastore PBS local
• Configs scripts backupés aussi → Google Drive (via backup-proxmox-host.sh pour /usr/local/bin/)
• Double protection : PBS snapshot + rclone external

🎯 RECOMMANDATION¶

✅ OUI - Ajouter LXC 102 au schedule PBS

Justification :

1. Infrastructure complète : Aucun LXC Docker non sauvegardé
2. Principe redondance : PBS snapshot + Google Drive = double protection
3. Simplicité restauration : pct restore 102 vs reconfiguration manuelle complexe
4. Coût négligeable : Espace/performance minimes vs bénéfice sécurité

Configuration recommandée :

# Ajouter job PBS pour LXC 102
Schedule: Daily @ 03:00 (comme autres LXC)
Retention: 7/4/3 (keep-daily/weekly/monthly)
Mode: Snapshot

Ordre backup :

1. 03:00 - PBS backup LXC 100/101/102/103 (tous)
2. 05:00 - LXC 102 backup configs Docker (100/101/103) + upload Google Drive

Mitigation circularité : Backup PBS configuration séparé host-side via /usr/local/bin/backup-proxmox-host.sh (déjà en place).

Question 2 : Stratégie Backup Sélectif vs Complet¶

État Actuel¶

Backup SÉLECTIF (stratégie actuelle) :

LXC 100 :
  ├─ docker-compose.yml
  ├─ prowlarr/config.xml
  ├─ radarr/config.xml
  ├─ sonarr/config.xml
  └─ sabnzbd/sabnzbd.ini

LXC 101 :
  ├─ docker-compose.yaml
  └─ homepage/*.yaml

LXC 103 :
  ├─ docker-compose.yml
  ├─ authelia/{configuration,users_database}.yml
  ├─ npm/data/
  └─ wireguard/

EXCLUSIONS actuelles :

• Médias Jellyfin (/jellyfin/media/ - TBs)
• Caches applicatifs (*/cache/*)
• Logs (*/logs/*)
• Downloads temporaires (*/downloads/*, */Downloads/*)
• MediaCover (*arr)
• Base configs générées (ASP, Definitions, Sentry)

Option A : Backup Complet /mnt/lxc-data/docker-XXX/¶

✅ AVANTAGES :

1. Exhaustivité garantie : Aucun fichier oublié (nouveaux configs automatiquement inclus)
2. Simplicité script : tar -czf /mnt/lxc-data/docker-100/ /mnt/lxc-data/docker-101/ (2 lignes vs 10+)
3. Restauration complète : Environnement 100% identique (bases données applicatives incluses)
4. Pas de maintenance : Ajout nouvelle app = backup automatique (pas mise à jour script)

❌ INCONVÉNIENTS :

1. Taille explosive :
   • docker-100 actuel : ~50 GB (avec bases données *arr, transcode cache Jellyfin, covers)
   • docker-101 actuel : ~2 GB
   • Total : ~52 GB par backup quotidien
2. Temps backup : Compression 52 GB = 15-30 min (vs actuel ~2 min)
3. Coût Google Drive :
   • 30 jours rétention = 52 GB × 30 = 1.56 TB stockage
   • Plan Google Workspace actuel : 2 TB (limite proche)
4. Bande passante upload : 52 GB/jour = ~6 heures upload (connexion moyenne)
5. Redondance inutile : Bases metadata *arr reconstruisibles depuis fichiers configs

Option B : Backup Complet /mnt/lxc-data/¶

❌ ENCORE PIRE :

• Inclut /mnt/lxc-data/backups/ (récursion absurde)
• Inclut médias Jellyfin (plusieurs TB)
• Inclut documentation (déjà backupée séparément)
• IMPRATICABLE : Taille prohibitive, temps upload ingérable

Option C : Stratégie Sélective Améliorée (recommandée)¶

Principe : Sauvegarder uniquement configs critiques non-régénérables

Configuration actuelle OPTIMALE :

Fichiers manquants possibles :

# Vérifier configs non-backupés
find /mnt/lxc-data/docker-100/ -name "*.xml" -o -name "*.yml" -o -name "*.yaml" -o -name "*.json" | grep -v "cache\|logs\|MediaCover\|downloads"

Amélioration suggérée :

# Ajouter au script backup-docker-configs.sh (sur host)
/mnt/lxc-data/docker-100/bazarr/config/config.yaml
/mnt/lxc-data/docker-100/bazarr/config/db/bazarr.db  # Base données subtitles

🎯 RECOMMANDATION¶

✅ Conserver stratégie SÉLECTIVE actuelle + ajustements mineurs

Justification :

1. Rapport coût/bénéfice optimal :
   • Taille actuelle : ~500 MB → upload 5 min
   • Stratégie complète : ~52 GB → upload 6h + 1.5 TB stockage
2. Configs critiques couverts : docker-compose + app configs XML/YAML/INI
3. Redondance intelligente :
   • PBS snapshot → filesystem complet (ZFS)
   • rclone Google Drive → configs essentiels
   • Double protection différenciée
4. Maintenabilité : Script simple, logs clairs, exécution rapide

Actions recommandées :

1. ✅ Audit annuel : Vérifier nouveaux configs apps non-backupés
2. ✅ Documenter critères : Quels fichiers inclurent (yaml/xml/ini/db vs cache/logs)
3. ⚠️ Évaluer bazarr.db : Base données subtitles (taille vs criticité)
4. ✅ Tester restore : Valider configs suffisent reconstruction environnement

Stratégie Hybride (optionnelle)¶

Backup différencié par fréquence :

Avantage : Granularité récupération vs coût stockage optimisé
Inconvénient : Complexité scripts + gestion 3 destinations

Synthèse Recommandations¶

🎯 Priorité HAUTE¶

1. ✅ Ajouter LXC 102 au schedule PBS backup
   • Schedule : 03:00 daily
   • Retention : 7/4/3
   • Impact : +2-3 GB datastore, +5 min backup

🎯 Priorité MOYENNE¶

1. ✅ Conserver stratégie backup sélective actuelle

   • Rapport coût/bénéfice optimal
   • Ajuster si nouveaux configs critiques détectés

2. ⚠️ Audit configurations backupées

   # Exécuter dans 102
   find /mnt/lxc-data/docker-{100,101}/ -type f \( -name "*.xml" -o -name "*.yml" -o -name "*.yaml" -o -name "*.ini" -o -name "*.db" \) ! -path "*/cache/*" ! -path "*/logs/*" ! -path "*/downloads/*"
   

3. 📋 Documenter critères inclusion backup

   • Créer section dans scripts.md : "Critères fichiers backupés"
   • Expliciter : configs essentiels vs données régénérables

🎯 Priorité BASSE (optionnel)¶

1. 🔄 Tester restore complet environnement

   • VM test : restore configs uniquement
   • Valider : docker-compose up reconstruit environnements
   • Documenter : procédure restoration.md

2. 💾 Évaluer backup hebdomadaire complet local

   • Si espace disque disponible /mnt/backup-pool/
   • Alternative : backup complet moins fréquent, rétention courte

Conclusion¶

Architecture backup actuelle = SOLIDE

Seule lacune identifiée : LXC 102 non-backupé (facilement corrigeable)

Stratégie sélective = OPTIMALE pour rapport coût/performance/praticité

Recommandation finale :

1. ✅ Ajouter LXC 102 au PBS (CRITIQUE) - FAIT
2. ✅ Harmoniser LXC 103 avec architecture centralisée - FAIT
3. Audit annuel configs (MAINTENANCE)
4. Conserver approche sélective (OPTIMAL)