19.8 Mini-Projekt: Netzwerk-Backup automatisieren

Ein Mini-Projekt zur Automatisierung von Netzwerk-Backups ist einer der sinnvollsten und praxisnächsten Einstiege in die Netzwerkautomatisierung. Gerade im CCNA- und frühen Automation-Umfeld verbindet dieses Thema mehrere zentrale Fähigkeiten in einer überschaubaren Aufgabe: Geräte per SSH erreichen, Informationen strukturiert sammeln, Dateien sauber speichern, mit Inventardaten arbeiten und erste Fehler systematisch behandeln. Gleichzeitig ist der fachliche Nutzen sofort nachvollziehbar. Netzwerkkonfigurationen ändern sich mit jedem Standard-Change, jedem neuen Interface, jeder Routing-Anpassung und jeder kleinen Managementänderung. Ohne aktuelle Sicherungen wird Fehlersuche schwieriger, Rollback unsicherer und Dokumentation schnell unvollständig. Genau deshalb ist ein automatisiertes Backup kein theoretisches Übungsbeispiel, sondern ein echter Grundbaustein professioneller Netzwerkarbeit. Im Lab eignet sich dieses Mini-Projekt besonders gut, weil es mit überschaubarem Aufwand umgesetzt werden kann, einen klaren praktischen Mehrwert liefert und den Übergang von einzelnen Python-Skripten zu kleinen, nützlichen Automatisierungsprozessen sehr gut sichtbar macht.

Warum Netzwerk-Backups automatisiert werden sollten

Manuelle Sicherungen sind fehleranfällig und unregelmäßig

In kleinen Lab-Umgebungen oder auch in realen Netzen werden Konfigurationssicherungen anfangs oft manuell durchgeführt. Ein Engineer verbindet sich auf das Gerät, gibt einen Show-Befehl ein und kopiert die Ausgabe in eine Datei. Das funktioniert für einzelne Geräte, wird aber schnell unzuverlässig, sobald mehrere Systeme oder regelmäßige Sicherungen erforderlich sind.

• Backups werden vergessen.
• Geräte werden nicht vollständig erfasst.
• Dateinamen sind uneinheitlich.
• Stände werden nicht sauber historisiert.
• Manuelle Kopierfehler verfälschen Ergebnisse.

Automatisierung löst diese Probleme nicht nur durch Geschwindigkeit, sondern vor allem durch Wiederholbarkeit und Konsistenz.

Backups sind Grundlage für viele weitere Aufgaben

Ein automatisiertes Backup ist nicht nur eine Sicherheitsmaßnahme. Es schafft auch die Grundlage für viele weitere betriebliche Prozesse.

• Vergleich alter und neuer Konfigurationsstände
• Drift-Erkennung zwischen Soll und Ist
• Dokumentation des aktuellen Gerätezustands
• Vorbereitung von Rollback-Szenarien
• Prüfung von Compliance oder Standardkonfigurationen

Gerade deshalb ist ein Backup-Skript im Lab ein idealer erster Schritt in Richtung echter Network Automation.

Ziel des Mini-Projekts klar definieren

Was das Projekt leisten soll

Für ein sinnvolles Mini-Projekt sollte der Umfang bewusst begrenzt, aber praktisch relevant sein. Ziel ist nicht, sofort ein hochverfügbares Enterprise-Backup-System zu bauen, sondern einen funktionierenden, nachvollziehbaren und sauberen Prozess im Lab umzusetzen.

• Mehrere Geräte aus einer kleinen Inventardatei einlesen
• Per SSH auf jedes Gerät verbinden
• Eine oder mehrere relevante Show-Ausgaben abrufen
• Die Ergebnisse pro Gerät in Dateien speichern
• Klare Dateinamen und Verzeichnisstruktur verwenden
• Einfache Fehlerbehandlung für nicht erreichbare Geräte einbauen

Mit diesem Umfang bleibt das Projekt überschaubar, deckt aber bereits viele wichtige Automation-Grundlagen ab.

Welche Daten gesichert werden sollen

Für das erste Mini-Projekt ist es sinnvoll, mit wenigen, aber wertvollen Konfigurationsdaten zu beginnen. Der Klassiker ist die laufende Konfiguration, also die Running-Config. Ergänzend können systemnahe Informationen sinnvoll sein.

• show running-config als primäre Konfigurationssicherung
• show startup-config optional zum Vergleich
• show version für Geräte- und Softwarestand
• show inventory für Modell- und Serieninformationen

Für einen ersten Backup-Prozess reicht show running-config meist völlig aus. Erweiterungen können später ergänzt werden.

Die Lab-Umgebung vorbereiten

Geräte mit SSH-Zugriff bereitstellen

Bevor ein Backup automatisiert werden kann, müssen die Zielgeräte sauber vorbereitet sein. Im Lab heißt das vor allem: Management-IP, SSH-Zugang und erreichbarer Pfad vom Automation-Host zu allen Geräten.

Eine typische Grundkonfiguration auf Cisco-Geräten kann so aussehen:

conf t
hostname R1
ip domain-name lab.local
username admin privilege 15 secret MeinPasswort123
crypto key generate rsa modulus 2048
ip ssh version 2
line vty 0 4
 login local
 transport input ssh
end
write memory

Diese Konfiguration stellt sicher, dass der Backup-Host per SSH auf das Gerät zugreifen kann.

Erreichbarkeit manuell prüfen

Ein häufiges Problem bei frühen Automatisierungsübungen ist, dass der Basiszugriff nicht sauber geprüft wurde. Deshalb sollte vor dem ersten Skriptlauf immer manuell verifiziert werden, dass die Geräte erreichbar sind und SSH funktioniert.

Typische Prüfungen vom Automation-Host:

ping 192.0.2.101
ssh admin@192.0.2.101

Auf dem Gerät selbst helfen zusätzlich:

show ip interface brief
show ip ssh
show running-config | section line vty

Diese Basistests sparen später viel Zeit bei der Fehlersuche.

Eine saubere Projektstruktur anlegen

Ordnung von Anfang an mitdenken

Auch ein kleines Lab-Projekt profitiert stark von einer klaren Struktur. Wer Skripte, Inventare und Ausgabedateien sauber trennt, arbeitet nicht nur übersichtlicher, sondern trainiert auch direkt eine professionellere Vorgehensweise.

• scripts/ für Python-Code
• inventory/ für Gerätedaten
• backups/ für gesicherte Konfigurationen
• logs/ für Lauf- oder Fehlerprotokolle

Eine solche Struktur macht das Mini-Projekt deutlich nachvollziehbarer und erleichtert spätere Erweiterungen.

Inventardaten aus dem Skript auslagern

Gerätedaten sollten möglichst früh aus dem Python-Code ausgelagert werden. Auch im Lab ist das sinnvoll, weil so die Trennung von Daten und Logik geübt wird. Eine kleine YAML-Datei reicht dafür völlig aus.

Ein einfaches Inventar könnte so aussehen:

devices:
  - hostname: R1
    host: 192.0.2.101
    role: router
  - hostname: SW1
    host: 192.0.2.102
    role: switch

Damit wird das Skript flexibler und leichter wiederverwendbar.

Den Backup-Prozess zunächst manuell denken

Welche Schritte ein manuelles Backup enthält

Bevor der Prozess automatisiert wird, ist es hilfreich, ihn gedanklich als manuelle Abfolge zu formulieren. Genau daraus entsteht später die Logik des Skripts.

• Gerät auswählen
• Per SSH verbinden
• show running-config ausführen
• Ausgabe lesen
• In Datei schreiben
• Datei sinnvoll benennen

Diese manuelle Kette ist wichtig, weil gute Automatisierung fast immer mit einem klar verstandenen manuellen Prozess beginnt.

Dateibenennung bewusst festlegen

Ein häufiger Schwachpunkt bei Backups ist nicht das Sammeln der Daten, sondern ihre unklare Ablage. Schon im Lab sollte deshalb eine sinnvolle Namenskonvention verwendet werden. Sehr praktisch sind Hostname und Datum oder Zeitstempel.

Ein gutes Schema könnte zum Beispiel so aussehen:

• R1_running_config_2026-03-29.txt
• SW1_running_config_2026-03-29.txt

Damit bleiben Sicherungen später leichter nachvollziehbar und vergleichbar.

Das erste einfache Backup-Skript erstellen

Ein Gerät sichern

Wie bei vielen Automatisierungsaufgaben sollte das Projekt zunächst mit genau einem Gerät beginnen. So lässt sich der Ablauf vollständig verstehen, bevor er auf mehrere Systeme skaliert wird.

Ein einfaches Python-Beispiel mit Netmiko:

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.txt", "w") as f:
    f.write(output)

Dieses kleine Skript liefert bereits den Kern des gesamten Mini-Projekts:

• Verbindung aufbauen
• Befehl ausführen
• Antwort empfangen
• Datei schreiben

Gerade im Lab sollte dieser Ablauf bewusst getestet und verstanden werden, bevor zusätzliche Komplexität hinzukommt.

Die Sicherung manuell verifizieren

Nach dem ersten Lauf ist es wichtig, nicht nur auf die Existenz der Datei zu schauen, sondern auch ihren Inhalt bewusst zu prüfen. So wird schnell sichtbar, ob die Sicherung wirklich vollständig und plausibel ist.

• Ist die Datei nicht leer?
• Beginnt sie mit der erwarteten Running-Config?
• Sind Zeilenumbrüche korrekt?
• Fehlen auffällige Teile?

Diese Kontrolle trainiert eine wichtige Grundhaltung: Auch automatisierte Ergebnisse müssen verifiziert werden.

Das Skript auf mehrere Geräte erweitern

Eine Schleife über das Inventar bauen

Der nächste logische Schritt besteht darin, das Backup für mehrere Geräte zu automatisieren. Genau hier zeigt sich einer der größten Vorteile von Automatisierung: dieselbe Logik wird auf mehrere Ziele angewendet.

Ein einfaches Beispiel:

from netmiko import ConnectHandler

devices = [
    {
        "hostname": "R1",
        "device_type": "cisco_ios",
        "host": "192.0.2.101",
        "username": "admin",
        "password": "MeinPasswort123"
    },
    {
        "hostname": "SW1",
        "device_type": "cisco_ios",
        "host": "192.0.2.102",
        "username": "admin",
        "password": "MeinPasswort123"
    }
]

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

    filename = f"backups/{device['hostname']}_running_config.txt"
    with open(filename, "w") as f:
        f.write(output)

Damit wird aus einer Einzelübung ein echter kleiner Backup-Prozess.

Dateinamen dynamisch erzeugen

Gerade bei mehreren Geräten ist es wichtig, dass Dateinamen automatisch aus den Gerätedaten entstehen. Dadurch werden Backups nachvollziehbar und es kommt nicht zu Überschreibungen durch manuell falsche Namen.

• Hostname als Basis
• Optional Datum ergänzen
• Optional Rolle oder Gerätetyp integrieren

Diese scheinbar kleine Entscheidung ist in der Praxis sehr wichtig.

Mit YAML-Inventar arbeiten

Daten und Code sauber trennen

Für ein sinnvoll aufgebautes Mini-Projekt sollten Gerätedaten nicht dauerhaft im Skript selbst stehen. Stattdessen ist es besser, sie in einer YAML-Datei zu pflegen und im Skript einzulesen.

Ein Beispiel-Inventar:

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

Das passende Python-Skript kann diese Daten dann verwenden. So wird direkt eine zentrale Grundidee der Network Automation geübt: Datenmodell und Programmlogik werden voneinander getrennt.

Vorteile dieser Trennung

• Neue Geräte können ergänzt werden, ohne den Code zu ändern.
• Inventardaten bleiben übersichtlicher.
• Das Skript wird wiederverwendbarer.
• Fehler in Logik und Daten lassen sich besser voneinander unterscheiden.

Gerade im Lab ist das ein wertvoller Lernschritt, weil er direkt in Richtung professionellerer Arbeitsweise führt.

Das Mini-Projekt robuster machen

Einfache Fehlerbehandlung ergänzen

Ein realistisches Backup-Skript sollte nicht beim ersten Problem einfach komplett abbrechen. Gerade in Lab-Umgebungen ist es hilfreich, erste Fehlerbehandlung bewusst einzubauen. So wird schnell sichtbar, welche Geräte erfolgreich gesichert wurden und wo Probleme auftraten.

Ein einfaches Grundprinzip:

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']}")

Damit wird das Mini-Projekt deutlich belastbarer und gleichzeitig realistischer.

Erfolg und Fehler sichtbar protokollieren

Auch in einem kleinen Lab-Projekt lohnt es sich, erfolgreiche und fehlgeschlagene Backups sichtbar zu protokollieren. Das muss noch kein komplexes Logging-System sein. Schon einfache Ausgaben helfen sehr.

• Welches Gerät wird gerade gesichert?
• Welche Sicherung war erfolgreich?
• Bei welchem Gerät trat ein Fehler auf?

Diese Transparenz ist wichtig, damit aus einem Skript ein verlässlicher Prozess wird und nicht nur ein stiller Versuch.

Das Backup fachlich sinnvoll erweitern

Nicht nur Running-Config sichern

Wenn der Grundprozess stabil läuft, kann das Mini-Projekt sinnvoll erweitert werden. Eine gute erste Ergänzung sind zusätzliche Befehle, die den Backup-Satz fachlich wertvoller machen.

• show version
• show inventory
• show startup-config

Ein einfacher Multi-Command-Ansatz kann so aussehen:

show running-config
show version
show inventory

Diese zusätzlichen Daten helfen später dabei, Backup-Dateien besser einzuordnen und Geräteinformationen mit Konfigurationsständen zu verknüpfen.

Mit Zeitstempeln arbeiten

Ein sehr sinnvoller nächster Schritt ist es, Sicherungen mit Datum oder Zeitstempel abzulegen. Das erhöht den praktischen Wert erheblich, weil mehrere Stände desselben Geräts nachvollziehbar werden.

• Vergleich von Änderungen über die Zeit
• Einfachere Rückverfolgung bei Fehlern
• Bessere Dokumentation von Zustandsverläufen

Schon im Lab lässt sich so der Übergang von einfacher Datenspeicherung hin zu echter Versionshistorie üben.

Typische Fehler in diesem Mini-Projekt

Verbindungsfehler mit Codefehlern verwechseln

Ein häufiger Fehler besteht darin, jedes Problem sofort als Python- oder Bibliotheksproblem zu interpretieren. In Wirklichkeit liegen viele Störungen auf Netzwerk- oder SSH-Ebene.

• Management-IP nicht erreichbar
• SSH nicht aktiv
• Benutzername oder Passwort falsch
• Falscher device_type im Skript

Die richtige Reihenfolge lautet deshalb immer: erst Erreichbarkeit, dann Login, dann Skriptlogik.

Dateien ungeordnet oder überschreibend ablegen

Ein weiterer häufiger Fehler liegt in unklarer Dateibenennung. Wenn mehrere Backups dieselbe Datei überschreiben oder die Namen keinen Bezug zum Gerät erkennen lassen, sinkt der praktische Nutzen stark.

Backups nicht inhaltlich prüfen

Nur weil eine Datei existiert, ist das Backup noch nicht automatisch brauchbar. Gerade im Lab sollte man bewusst prüfen, ob die gesicherten Inhalte vollständig und plausibel sind.

Alles in ein einziges Skript pressen

Für ein Mini-Projekt sollte die Logik zwar überschaubar bleiben, aber nicht chaotisch werden. Gerätedaten, Dateinamen, Fehlerbehandlung und Befehlslisten sollten klar erkennbar strukturiert sein.

Das Projekt mit Git sauber begleiten

Schon kleine Lab-Projekte versionieren

Auch ein einfaches Backup-Skript profitiert von Versionsverwaltung. Gerade im Lernprozess ändern sich Inventare, Dateistrukturen und Code schnell. Git macht diese Entwicklung nachvollziehbar.

Ein einfacher Einstieg:

git init
git add .
git commit -m "Initiales Mini-Projekt fuer automatisierte Netzwerk-Backups"

So können spätere Änderungen am Skript, an der Inventardatei oder an der Dateibenennung sauber zurückverfolgt werden.

Kleine, nachvollziehbare Entwicklungsschritte bevorzugen

Statt das Projekt in einem großen Sprung aufzubauen, ist es sinnvoll, schrittweise vorzugehen.

• Erst ein Gerät sichern
• Dann mehrere Geräte ergänzen
• Dann Inventar auslagern
• Dann Fehlerbehandlung einbauen
• Dann Zeitstempel oder Zusatzbefehle hinzufügen

Genau diese schrittweise Entwicklung ist didaktisch und technisch deutlich sinnvoller.

Best Practices für das Mini-Projekt „Netzwerk-Backup automatisieren“

• Mit einem kleinen, klaren Ziel beginnen: Running-Config von wenigen Lab-Geräten sichern.
• Vor jedem Skriptlauf Erreichbarkeit und SSH-Zugriff manuell prüfen.
• Gerätedaten früh aus dem Code in ein kleines Inventar auslagern.
• Backups in einer klaren Verzeichnisstruktur und mit nachvollziehbaren Dateinamen speichern.
• Read-Only-Befehle wie show running-config als sichere Grundlage verwenden.
• Einfache Fehlerbehandlung für Timeout und Authentifizierungsprobleme einbauen.
• Backup-Dateien nicht nur erzeugen, sondern auch inhaltlich verifizieren.
• Das Projekt schrittweise um Zeitstempel und Zusatzinformationen wie show version erweitern.
• Skripte, Inventare und Änderungen mit Git versionieren.
• Das Mini-Projekt nicht als Einmalübung sehen, sondern als Grundlage für spätere Inventar-, Compliance- und Dokumentationsprozesse.

Dieses Mini-Projekt zeigt sehr anschaulich, wie aus einer einfachen Idee ein echter Automatisierungsprozess entsteht. Automatisierte Netzwerk-Backups verbinden SSH-Zugriff, Python-Logik, Inventardaten, Dateiverarbeitung und Fehlersuche zu einer Aufgabe, die im Lab gut beherrschbar und gleichzeitig fachlich äußerst relevant ist. Wer diesen Ablauf sauber umsetzt, lernt nicht nur ein nützliches Skript zu schreiben, sondern entwickelt ein belastbares Verständnis dafür, wie kleine, praktische Automatisierungsschritte im Netzwerkalltag aufgebaut werden sollten.

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.