Sauvegarde et documente l’exploitation réseau

L’idée reçue

« Une archive de /etc est une sauvegarde réseau suffisante. »

Une sauvegarde exploitable doit identifier son périmètre, protéger les secrets, conserver des preuves, vérifier son intégrité et être restaurable selon une procédure testée.

Configurationétat désiré

fichiers, règles, interfaces et protocoles.

Secretidentité sensible

clé privée, token, password et communauté.

Preuveétat observé

routes, voisins, sockets, versions et services.

01Définir le périmètre

Le script collecte des copies sanitizées de configurations réseau et des sorties read-only. Il n’automatise jamais une restauration dans /etc.

chmod +x module5c-config-backup.sh
sudo ./module5c-config-backup.sh snapshot /var/backups/soria-network

Le snapshot peut inclure :

interfaces, netplan et nftables ;
FRR et Keepalived ;
WireGuard avec lignes sensibles masquées ;
SSH et Prometheus ;
routes, règles, sockets, voisins OSPF et versions.

La sanitisation est une protection best-effort. Elle ne dispense pas d’une revue avant transfert. Les clés privées et secrets réels doivent être gérés dans un coffre ou un mécanisme de sauvegarde chiffré séparé.

02Lire le manifest

sudo find /var/backups/soria-network -name MANIFEST.txt -print -exec cat {} ;

Le manifest fixe l’identité du snapshot, l’heure, le nœud, le périmètre inclus, les exclusions et la politique de restauration.

03Vérifier l’intégrité

sudo ./module5c-config-backup.sh verify /var/backups/soria-network/NOM-DU-SNAPSHOT

SHA256SUMS détecte une modification ou une corruption. Il ne prouve pas que la configuration est correcte, complète ou applicable.

04Préparer un restore drill

Travaille dans un répertoire isolé :

mkdir -p /tmp/soria-restore-review
tar -xzf snapshot.tar.gz -C /tmp/soria-restore-review
cd /tmp/soria-restore-review/NOM-DU-SNAPSHOT
sha256sum -c SHA256SUMS

Valide ensuite chaque format sans charger la configuration :

sudo nft -c -f configs/etc/nftables.conf
sudo sshd -t -f configs/etc/ssh/sshd_config
promtool check rules configs/etc/prometheus/rules/network.yml

Pour FRR, compare le snapshot avec la configuration courante et planifie un reload contrôlé. FRR conserve une configuration intégrée dans /etc/frr/frr.conf ; une sauvegarde de fichier ne remplace pas la sauvegarde explicite des changements en cours.

05Détecter le drift

diff -ru ancien-snapshot/configs nouveau-snapshot/configs

Classe chaque différence :

Différence

Décision

Preuve

Changement approuvé

Mettre à jour la référence

Ticket et test

Secret masqué différent

Vérifier dans le coffre

Version ou date

Changement non documenté

Traiter comme drift

Diff et propriétaire

État dynamique différent

Comparer au contexte

Route ou voisin

06Écrire le runbook

Le modèle fourni impose :

déclencheur et impact ;
commandes et résultats attendus ;
décision, risque et propriétaire ;
retour arrière ;
test utilisateur ;
cause, prévention et action de suivi.

Exercice de restauration

Récupère une règle nftables supprimée

crée un snapshot sain ;
supprime une règle uniquement dans un namespace de laboratoire ;
identifie le drift avec un diff ;
extrais la règle attendue dans un fichier temporaire ;
valide avec nft -c ;
applique dans le namespace, teste le service et documente le rollback.

✓Ce que tu retiens

Une sauvegarde réseau est un ensemble vérifiable : configuration, secrets gérés séparément, preuves, checksums, procédure de restauration et validation du service. Sans restore drill, l’archive reste une hypothèse.