Sauvegarde et restauration des configurations réseau
Une configuration réseau perdue peut immobiliser un site pendant des heures. Sauvegarde automatisée, versionnement, protection des secrets et tests de restauration : la démarche complète.
Un commutateur qui tombe en panne se remplace en quelques heures si l'on dispose de sa configuration ; sans elle, il faut la reconstruire de mémoire, à partir de documents incomplets, pendant que les utilisateurs attendent. La sauvegarde des configurations est l'une des mesures les plus rentables de l'exploitation réseau, et pourtant l'une des plus souvent négligées.
Objectif : mettre en place une sauvegarde fiable et automatisée des configurations, la versionner, protéger les secrets qu'elle contient et vérifier régulièrement la capacité de restauration.
Que sauvegarder ?
- La configuration active (running-config) et la configuration de démarrage (startup-config) de chaque équipement.
- Les versions logicielles en service (pour reconstruire à l'identique).
- Les licences et fichiers spécifiques (certificats, clés si exportables, fichiers de base de données VLAN selon les plateformes).
- Les éléments hors équipement : configuration des contrôleurs Wi-Fi, des pare-feu, des répartiteurs de charge, de la supervision et des serveurs d'infrastructure (DHCP, DNS).
Configuration active ou de démarrage ? Sur Cisco IOS, les modifications s'appliquent immédiatement à la running-config mais sont perdues au redémarrage si elles ne sont pas enregistrées (copy running-config startup-config, ou write memory). Une différence entre les deux est un signal d'alerte : soit un changement non enregistré, soit une modification non documentée.
Méthodes manuelles
Utiles pour une intervention ponctuelle ou un petit parc.
! Copier la configuration vers un serveur SCP (Cisco IOS — exemple de laboratoire)
copy running-config scp://sauvegarde@10.10.99.50/configs/sw-acces-02.cfg
! Ou vers la mémoire flash locale avant une intervention
copy running-config flash:avant-intervention-20261029.cfg
Privilégiez SCP ou SFTP plutôt que TFTP ou FTP, qui transmettent en clair et sans authentification forte.
Avant toute intervention planifiée, prenez l'habitude d'une sauvegarde « avant » et d'une sauvegarde « après », puis comparez-les.
L'archivage intégré de Cisco IOS
IOS peut archiver automatiquement sa configuration et permettre un retour arrière :
archive
path scp://sauvegarde@10.10.99.50/archives/$h-
write-memory
time-period 1440
write-memorydéclenche une archive à chaque enregistrement ;time-period 1440archive aussi toutes les 24 heures ;$hest remplacé par le nom d'hôte.
La fonction configure replace permet de remplacer la configuration active par une version archivée, en n'appliquant que les différences :
configure replace flash:avant-intervention-20261029.cfg list
Combiné à configure terminal revert timer <minutes> (sur les versions qui le prennent en charge), ce mécanisme offre un retour automatique si l'administrateur ne confirme pas la modification, ce qui protège contre la perte d'accès à distance.
Automatiser avec un outil dédié
Pour un parc de plus de quelques équipements, un outil centralisé est indispensable. Oxidized et RANCID sont deux outils libres répandus : ils se connectent périodiquement aux équipements (SSH), récupèrent la configuration et la versionnent dans un dépôt Git.
Extrait de configuration Oxidized (exemple) :
username: sauvegarde
interval: 3600
input:
default: ssh
output:
default: git
git:
repo: "/var/lib/oxidized/configs.git"
source:
default: csv
csv:
file: "/etc/oxidized/router.db"
delimiter: !ruby/regexp /:/
map:
name: 0
model: 1
# /etc/oxidized/router.db
sw-acces-02.exemple.local:ios
rt-site-paris.exemple.local:iosxe
fw-dmz-01.exemple.local:fortios
Avantages du versionnement Git :
- historique complet : qui a changé quoi, et quand (à croiser avec vos tickets de changement) ;
- comparaison simple entre deux versions (
git diff) ; - détection des modifications non planifiées, notifiables automatiquement.
Le compte de sauvegarde
L'outil de sauvegarde doit disposer d'un compte dédié, avec les droits minimaux : lecture de la configuration, sans possibilité de la modifier lorsque la plateforme le permet (niveaux de privilège ou rôles en lecture). Ce compte est authentifié de préférence par clé SSH ou via un serveur AAA (TACACS+, RADIUS), et ses accès sont journalisés.
Protéger les sauvegardes
Une configuration réseau contient des informations sensibles : topologie, adresses, règles de filtrage, et souvent des secrets (mots de passe hachés, clés pré-partagées VPN, communautés SNMP, secrets RADIUS).
- Stockage chiffré et accès restreint au dépôt de sauvegarde.
- Masquage des secrets : Oxidized peut retirer les lignes sensibles (option
remove_secret), au prix d'une restauration qui exige de ressaisir ces secrets. - Copie hors site : une sauvegarde stockée uniquement sur le réseau qu'elle décrit est inaccessible quand ce réseau est en panne. Conservez une copie dans un autre site et une copie hors ligne.
- Rétention : conservez suffisamment de versions pour revenir avant un changement fautif découvert tardivement.
Sur Cisco IOS, utilisez des secrets hachés avec un algorithme robuste (enable algorithm-type scrypt secret … sur les versions qui le prennent en charge) plutôt que l'ancien chiffrement réversible de type 7.
Restaurer
Remplacement d'un équipement identique
- Installer la même version logicielle que l'équipement d'origine (ou une version compatible validée).
- Appliquer une configuration minimale de gestion pour joindre le serveur de sauvegarde.
- Copier la configuration sauvegardée vers la
startup-config, puis redémarrer — ou l'appliquer parconfigure replace. - Ressaisir les secrets masqués le cas échéant.
- Vérifier : interfaces, VLAN, voisins de routage, trunks, services.
copy scp://sauvegarde@10.10.99.50/configs/sw-acces-02.cfg startup-config
reload
Copier une configuration directement dans la running-config fusionne les lignes avec l'existant au lieu de la remplacer : le résultat peut différer de l'original.
Retour arrière après un changement fautif
Utilisez la version précédente du dépôt et configure replace, après avoir identifié précisément la différence.
Tester la restauration
Une sauvegarde non testée n'est qu'une hypothèse. Planifiez des tests réguliers :
- restaurer une configuration sur un équipement de laboratoire ou un équipement virtuel équivalent ;
- vérifier qu'aucun élément n'est manquant (certificats, licences, secrets) ;
- mesurer le temps nécessaire, pour l'intégrer à vos plans de continuité.
Erreurs courantes
- Sauvegarder uniquement la startup-config, ou uniquement manuellement.
- Utiliser TFTP sur un réseau non maîtrisé.
- Stocker les sauvegardes au même endroit que les équipements.
- Ne jamais tester la restauration.
- Oublier les équipements « hors réseau » : contrôleurs Wi-Fi, pare-feu, consoles de gestion.
Conclusion
Automatiser la collecte, versionner dans Git, protéger les secrets, conserver une copie hors site et tester la restauration : ces cinq actions transforment une panne matérielle en simple opération de maintenance. Elles s'intègrent naturellement dans une démarche plus large de documentation et d'automatisation.


