20.5 Backup und Restore von Netzwerkkonfigurationen automatisieren

Backup und Restore von Netzwerkkonfigurationen zu automatisieren gehört zu den wichtigsten und zugleich praktischsten Aufgaben in der Netzwerkautomatisierung. Kaum ein anderer Bereich verbindet Betriebssicherheit, Standardisierung, Fehlersuche und Wiederherstellbarkeit so direkt miteinander. Solange ein Netzwerk klein ist, werden Konfigurationssicherungen oft noch manuell erstellt: Ein Engineer verbindet sich per SSH auf ein Gerät, kopiert die Running-Config und speichert sie irgendwo lokal ab. Dieser Ansatz funktioniert kurzfristig, skaliert aber schlecht und ist im Ernstfall oft unzuverlässig. Spätestens wenn mehrere Standorte, viele Geräte oder regelmäßige Änderungen ins Spiel kommen, wird klar, dass Backups nicht nur vorhanden, sondern aktuell, nachvollziehbar und im Bedarfsfall auch wiederherstellbar sein müssen. Genau an diesem Punkt wird Automatisierung entscheidend. Für Network Engineers bedeutet das nicht nur, Konfigurationen regelmäßig einzusammeln, sondern den gesamten Prozess von Sicherung, Versionierung, Validierung und Wiederherstellung systematisch zu denken. Automatisiertes Backup und Restore ist damit keine Komfortfunktion, sondern ein zentraler Bestandteil eines belastbaren Netzwerkbetriebs.

Warum Backup und Restore im Netzwerk so wichtig sind

Konfiguration ist Betriebsrealität

Ein Netzwerkgerät ist nicht nur Hardware und Betriebssystem, sondern vor allem seine wirksame Konfiguration. Routing, VLANs, Interfaces, ACLs, Managementzugänge, Syslog-Ziele, NTP-Server oder Policy-Blöcke existieren für den Betrieb erst durch diese Konfigurationsdaten. Wenn sie verloren gehen oder beschädigt werden, ist das nicht nur ein Dokumentationsproblem, sondern ein unmittelbares Betriebsrisiko.

• Ein Gerät wird ersetzt und muss schnell wiederhergestellt werden.
• Ein fehlerhafter Change muss zurückgerollt werden.
• Eine manuelle Änderung erzeugt unerwartete Nebenwirkungen.
• Nach einem Ausfall wird der letzte bekannte gute Stand benötigt.

Genau deshalb ist eine aktuelle, saubere und nachvollziehbare Sicherung der Konfiguration für jedes produktive Netzwerk essenziell.

Ein Backup allein reicht nicht, wenn Restore nicht funktioniert

Viele Teams konzentrieren sich stark auf das Sammeln von Konfigurationsdateien, denken aber zu wenig über die tatsächliche Wiederherstellung nach. Ein Backup ist jedoch erst dann wirklich wertvoll, wenn daraus ein sinnvoller Restore-Prozess abgeleitet werden kann. Eine Datei irgendwo auf einem Server ist keine belastbare Wiederherstellungsstrategie, wenn unklar bleibt, wie sie im Ernstfall verwendet wird.

• Ist die Datei vollständig und lesbar?
• Gehört sie zum richtigen Gerät?
• Ist ihr Alter bekannt?
• Wurde sie jemals für einen Restore-Test verwendet?
• Passt sie zur aktuellen Hardware oder Plattform?

Automatisierung sollte daher immer beide Seiten mitdenken: Sicherung und Wiederherstellung.

Was unter Backup und Restore im Netzwerk konkret verstanden wird

Backup bedeutet mehr als nur Running-Config kopieren

Im einfachsten Fall besteht ein Backup aus der laufenden Konfiguration eines Geräts. In vielen Umgebungen ist das bereits sehr wertvoll. Je nach Reifegrad und Bedarf kann ein Backup aber deutlich mehr umfassen.

• Running-Config
• Startup-Config
• Software- und Versionsinformationen
• Inventar- und Seriennummern
• Interface- und Plattformdetails
• Begleitinformationen wie Zeitstempel und Gerätegruppe

Typische CLI-Befehle, die in Backup-Prozessen eine Rolle spielen, sind:

show running-config
show startup-config
show version
show inventory

Gerade in frühen Automatisierungsprojekten reicht es oft, mit der Running-Config zu beginnen und später zusätzliche Informationen zu ergänzen.

Restore bedeutet kontrollierte Wiederherstellung eines Zielzustands

Restore heißt im Netzwerk nicht automatisch, eine komplette Datei blind auf ein Gerät zu laden. In vielen Fällen ist Wiederherstellung differenzierter zu betrachten. Je nach Vorfall und Plattform kann ein Restore vollständig, teilweise oder selektiv erfolgen.

• Komplette Rücksicherung auf ein Ersatzgerät
• Teilweiser Rollback nach fehlerhaftem Change
• Wiederherstellung einzelner Konfigurationsblöcke
• Vergleich und manuelle Übernahme aus einem Sicherungsstand

Ein guter Restore-Prozess berücksichtigt also nicht nur die Daten, sondern auch den Kontext der Wiederherstellung.

Warum manuelle Backup- und Restore-Prozesse an Grenzen stoßen

Manuelle Sicherungen sind unregelmäßig und fehleranfällig

In vielen Netzwerken werden Konfigurationen nur bei Bedarf oder vor größeren Änderungen manuell gesichert. Das ist besser als gar keine Sicherung, führt aber oft zu Lücken und Inkonsistenzen.

• Backups werden unregelmäßig erstellt.
• Einige Geräte werden vergessen.
• Dateien erhalten uneinheitliche Namen.
• Zeitstempel fehlen oder sind unklar.
• Der Speicherort ist nicht zentral oder nicht dokumentiert.

Automatisierung schafft hier Struktur und Wiederholbarkeit. Genau das ist ihr größter Vorteil.

Restore unter Zeitdruck ist ohne Vorbereitung riskant

Wiederherstellung findet selten in ruhigen Situationen statt. Häufig geschieht sie nach einem Change-Fehler, bei einem Geräteausfall oder in einer Störungslage. Dann fehlt oft die Zeit, erst lange nach der richtigen Datei oder dem passenden Konfigurationsstand zu suchen.

• Welcher Backup-Stand ist der richtige?
• Ist die Datei vollständig?
• Wurde sie vor oder nach dem problematischen Change erstellt?
• Ist die Plattform identisch oder kompatibel?

Ein automatisierter, sauber strukturierter Backup-Prozess reduziert genau dieses Risiko.

Was ein gutes automatisiertes Backup auszeichnet

Regelmäßigkeit und Vollständigkeit

Ein guter Backup-Prozess läuft nicht nur einmal, sondern regelmäßig. Das Ziel ist, jederzeit einen möglichst aktuellen und nachvollziehbaren Konfigurationsstand verfügbar zu haben. Dabei ist Vollständigkeit ebenso wichtig wie Aktualität.

• Alle relevanten Geräte werden erfasst.
• Die Sicherungen werden in definierten Intervallen erstellt.
• Fehlgeschlagene Backups werden sichtbar gemacht.
• Jedes Gerät erhält eine eigene, eindeutig zuordenbare Datei.

Nur wenn diese Grundprinzipien erfüllt sind, wird aus Datensammlung ein belastbarer Backup-Prozess.

Strukturierte Ablage und klare Dateinamen

Ebenso wichtig wie die eigentliche Sicherung ist die Art der Ablage. Backups müssen schnell auffindbar, eindeutig zuordenbar und möglichst gut vergleichbar sein. Deshalb sollten Dateinamen und Verzeichnisstruktur klar definiert sein.

• Hostname im Dateinamen
• Datum oder Zeitstempel
• Optional Gerätegruppe oder Rolle
• Trennung nach Gerätetyp oder Standort

Ein sinnvolles Dateimuster könnte etwa so aussehen:

• R1_running_config_2026-03-29.txt
• SW1_startup_config_2026-03-29.txt

Diese kleine Disziplin verbessert den praktischen Nutzen der Backups erheblich.

Wie automatisierte Backups technisch umgesetzt werden können

SSH und CLI als pragmatischer Einstieg

Für viele Netzwerke und Lab-Umgebungen ist SSH der einfachste und realistischste Einstieg. Ein Skript verbindet sich mit dem Gerät, ruft relevante Show-Befehle ab und speichert die Ausgabe in Dateien. Gerade für kleine bis mittlere Umgebungen ist das oft völlig ausreichend.

Ein konzeptionell einfacher Ablauf lautet:

• Geräteinventar laden
• SSH-Verbindung aufbauen
• show running-config absetzen
• Ausgabe empfangen
• Datei schreiben

Ein typisches Python-Skript mit Netmiko kann so aussehen:

from netmiko import ConnectHandler

device = {
    "device_type": "cisco_ios",
    "host": "192.0.2.101",
    "username": "admin",
    "password": "MeinPasswort123"
}

with ConnectHandler(**device) as conn:
    output = conn.send_command("show running-config")

with open("backups/R1_running_config_2026-03-29.txt", "w") as f:
    f.write(output)

Dieses einfache Muster bildet bereits den Kern vieler Backup-Automatisierungen.

Mit Inventardateien und Schleifen skalieren

Der eigentliche Mehrwert entsteht, wenn derselbe Ablauf auf viele Geräte angewendet wird. Dafür sollten Gerätedaten nicht im Skript selbst versteckt sein, sondern aus einer Inventardatei kommen.

Ein einfaches YAML-Inventar könnte so aussehen:

devices:
  - hostname: R1
    host: 192.0.2.101
    device_type: cisco_ios
  - hostname: SW1
    host: 192.0.2.102
    device_type: cisco_ios

Darauf aufbauend kann das Skript für jedes Gerät ein Backup erzeugen. So wird aus einer Einzelaktion ein echter Prozess.

Backup-Prozesse sinnvoll erweitern

Nicht nur die Running-Config sichern

Wenn der Grundprozess stabil läuft, kann er fachlich erweitert werden. Häufig ist es sinnvoll, neben der Running-Config weitere Informationen mitzusichern, um den Kontext eines Backups besser zu dokumentieren.

• show startup-config
• show version
• show inventory

Ein Backup-Satz besteht dann nicht mehr nur aus einer Datei, sondern aus mehreren, zusammengehörigen Artefakten. Das erhöht den Wert bei späterem Restore oder bei Analyse und Dokumentation.

Backups versionieren und vergleichen

Ein weiteres wichtiges Element ist die Nachvollziehbarkeit von Änderungen. Wenn Konfigurationsstände regelmäßig gesichert werden, können Unterschiede zwischen zwei Zeitpunkten sichtbar gemacht werden. Genau das ist besonders nützlich bei Fehlersuche und Change-Analyse.

• Was wurde seit dem letzten Backup geändert?
• Welche Konfigurationszeilen kamen hinzu?
• Welche Standards wurden entfernt oder überschrieben?

Gerade in Verbindung mit Git oder vergleichbarer Versionsverwaltung wird aus dem Backup-Prozess ein sehr starkes Werkzeug für Transparenz und Qualitätssicherung.

Restore im Netzwerk richtig verstehen

Nicht jede Wiederherstellung ist ein Voll-Overwrite

Ein häufiger Denkfehler ist, Restore nur als vollständiges Zurückspielen einer Konfigurationsdatei zu sehen. In der Praxis ist das nur eine von mehreren Formen der Wiederherstellung. Häufig sind gezieltere Ansätze sinnvoller.

• Ein einzelner Konfigurationsblock wird wiederhergestellt.
• Ein neueres Gerät erhält eine angepasste Version des alten Stands.
• Nur bestimmte Standardabschnitte werden zurückgesetzt.
• Ein Backup dient als Referenz für manuelle Korrektur.

Restore sollte daher immer kontextbezogen geplant werden und nicht nur technisch, sondern auch betrieblich sinnvoll sein.

Restore braucht Prüfungen, nicht nur Mut

Gerade unter Zeitdruck kann die Versuchung groß sein, eine alte Konfiguration einfach komplett zurückzuspielen. Das kann funktionieren, birgt aber Risiken, wenn Plattform, Umgebung oder Abhängigkeiten sich verändert haben.

• Passt die Konfiguration noch zur aktuellen Hardware?
• Sind alle Interfaces und Module identisch?
• Wurde die Datei nach einem Change oder davor gesichert?
• Gibt es inzwischen bewusst eingeführte neue Standards?

Ein guter Restore-Prozess enthält deshalb immer eine Prüfung des Sicherungsstands, bevor dieser angewendet wird.

Wie Restore-Automatisierung sinnvoll aufgebaut werden kann

Mit kontrollierten Teil-Restores beginnen

Für Lab- und frühe Praxisprojekte ist es sinnvoll, Restore nicht sofort als Vollwiederherstellung ganzer Geräte zu automatisieren. Ein deutlich sichererer Einstieg ist die Wiederherstellung definierter, kleinerer Konfigurationsbereiche.

• Banner-Block wiederherstellen
• NTP- oder Syslog-Konfiguration zurücksetzen
• Bestimmte Interface-Profile erneut anwenden

Diese Form des Restore ist fachlich klar, risikoärmer und im Lab sehr gut nachvollziehbar.

Vorher-Nachher-Vergleich in den Restore integrieren

Ein kontrollierter Restore sollte nie ohne Verifikation erfolgen. Vor der Wiederherstellung sollte geprüft werden, was aktuell auf dem Gerät steht. Danach muss kontrolliert werden, ob der gewünschte Zustand tatsächlich wieder erreicht wurde.

Typische Prüfbefehle können sein:

show running-config | include ntp
show running-config | include logging
show running-config | include banner

Diese einfache Disziplin macht den Unterschied zwischen blindem Überschreiben und kontrollierter Wiederherstellung.

Typische Fehler bei automatisierten Backup- und Restore-Prozessen

Backups sammeln, aber nie testen

Eine der häufigsten Schwächen besteht darin, dass Backups zwar regelmäßig erzeugt werden, aber nie praktisch getestet wird, ob sie für einen Restore wirklich taugen. Damit bleibt unklar, ob die Sicherungen im Ernstfall tatsächlich brauchbar sind.

• Dateien könnten unvollständig sein.
• Namenskonventionen könnten unklar sein.
• Bestimmte Plattformdetails könnten fehlen.
• Der Restore-Prozess selbst ist nicht eingeübt.

Backup ohne Restore-Test ist deshalb nur eine halbe Lösung.

Keine saubere Struktur in den Sicherungsdaten

Wenn Backups unsystematisch abgelegt werden, sinkt ihr Wert dramatisch. Ohne klare Zuordnung und Chronologie wird die Wiederherstellung unnötig mühsam.

• Unklare Dateinamen
• Keine Trennung nach Gerät oder Datum
• Mehrere unterschiedliche Speicherorte
• Fehlende Protokollierung fehlgeschlagener Sicherungen

Ein technisch funktionierender Backup-Job reicht also nicht, wenn die Ergebnisse organisatorisch unbrauchbar bleiben.

Restore zu grob und ohne Kontext anwenden

Ein unreflektierter Voll-Restore kann neue Probleme schaffen, wenn er nicht an die aktuelle Realität angepasst wird. Gerade deshalb sollte Wiederherstellung nicht als rein technische Notmaßnahme, sondern als kontrollierter Prozess verstanden werden.

Fehlerbehandlung und Betriebssicherheit mitdenken

Fehlgeschlagene Backups sichtbar machen

Ein Backup-Prozess ist nur dann belastbar, wenn auch Ausfälle oder Teilfehler sichtbar werden. Es reicht nicht, nur erfolgreiche Dateien zu erzeugen. Ebenso wichtig ist zu erkennen, welche Geräte nicht gesichert werden konnten.

• Gerät nicht erreichbar
• SSH-Authentifizierung schlägt fehl
• Timeout beim Abruf
• Unerwartete oder leere Ausgabe

Ein einfaches Python-Muster für Fehlerbehandlung könnte so aussehen:

from netmiko.exceptions import NetMikoTimeoutException, NetMikoAuthenticationException

try:
    with ConnectHandler(**device) as conn:
        output = conn.send_command("show running-config")
except NetMikoAuthenticationException:
    print(f"Authentifizierung fehlgeschlagen bei {device['hostname']}")
except NetMikoTimeoutException:
    print(f"Timeout bei {device['hostname']}")

Dadurch werden Lücken im Backup-Prozess erkennbar, statt still bestehen zu bleiben.

Restore nicht ohne Managementzugang und Validierung planen

Gerade bei Wiederherstellungen sollte klar sein, dass der bestehende Zugang nicht unkontrolliert gefährdet wird. Restore-Prozesse müssen so gestaltet sein, dass Managementpfad, Authentifizierung und Plattformkompatibilität berücksichtigt werden.

• Ist das Zielgerät erreichbar?
• Ist die Wiederherstellung auf der Plattform sinnvoll?
• Wurde das Backup vorab fachlich geprüft?
• Gibt es eine Verifikation nach dem Restore?

So wird aus einer Notmaßnahme ein kontrollierter technischer Vorgang.

Best Practices für automatisiertes Backup und Restore von Netzwerkkonfigurationen

• Mit einem einfachen, stabilen Backup der Running-Config beginnen und den Prozess erst danach erweitern.
• Geräteinventar sauber pflegen und Backups nicht auf Zuruf, sondern systematisch pro Zielgerät erstellen.
• Klare Dateinamen mit Hostname und Zeitbezug verwenden.
• Backups regelmäßig statt nur anlassbezogen erzeugen.
• Neben der Konfiguration auch Version und Inventardaten sinnvoll mit erfassen.
• Fehlgeschlagene Sicherungen sichtbar protokollieren und nicht übersehen.
• Backups versionieren oder vergleichbar speichern, um Änderungen nachvollziehen zu können.
• Restore nicht nur als Voll-Restore denken, sondern auch kontrollierte Teilwiederherstellungen nutzen.
• Jeden Restore mit Vorher-Nachher-Prüfungen absichern.
• Backup und Restore im Lab praktisch testen, statt sich nur auf theoretische Verfügbarkeit von Dateien zu verlassen.

Backup und Restore von Netzwerkkonfigurationen zu automatisieren bedeutet damit weit mehr, als regelmäßig Textdateien von Geräten abzuziehen. Es geht um einen kontrollierten Sicherheits- und Wiederherstellungsprozess, der Konfigurationsstände nachvollziehbar sichert, Änderungen transparent macht und im Ernstfall eine belastbare Grundlage für Rollback oder Wiederaufbau liefert. Gerade weil Konfiguration im Netzwerk die eigentliche Betriebslogik darstellt, zählt dieser Bereich zu den wichtigsten und wertvollsten Automatisierungsfeldern überhaupt.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.