Ein zuverlässiges Cisco Backup erstellen ist eine der wichtigsten Routineaufgaben im Netzwerkbetrieb. Denn selbst die beste Konfiguration schützt nicht vor Hardwaredefekten, versehentlichen Änderungen, fehlerhaften Updates oder einem ungeplanten Stromausfall. Wer die Konfiguration eines Routers oder Switches regelmäßig sichert, kann im Ernstfall innerhalb weniger Minuten wieder arbeitsfähig sein – statt stundenlang Einstellungen zu rekonstruieren. In der Praxis reicht es nicht aus, nur „einmal gespeichert“ zu haben: Sie benötigen ein Konzept, wie Sie Konfigurationsdateien versionieren, sicher übertragen, wiederherstellen und nach einem Restore verifizieren. Dieser Artikel zeigt Ihnen Schritt für Schritt, wie Sie Backups auf Cisco IOS bzw. IOS XE erstellen – manuell per CLI und mit praxistauglichen Best Practices. Sie lernen, welche Backup-Arten es gibt (lokal, extern, automatisiert), welche Übertragungswege sich eignen (SCP/SFTP statt unsicherer Protokolle), wie Sie typische Stolperfallen vermeiden und wie Sie eine Wiederherstellung so durchführen, dass Sie sich nicht aussperren. Ziel ist ein Backup-Workflow, der auch für Einsteiger verständlich ist, aber gleichzeitig professionellen Ansprüchen an Sicherheit und Nachvollziehbarkeit gerecht wird.
Warum ein Cisco-Backup mehr ist als „copy run start“
Viele Administratoren speichern Änderungen korrekt in die Startup-Config und fühlen sich damit abgesichert. Das ist ein wichtiger Schritt, aber kein vollständiges Backup. Ein externer Backup-Stand schützt zusätzlich vor Szenarien wie defektem Flash/NVRAM, Geräteverlust, fehlerhaften Images oder versehentlichem Löschen. Außerdem ermöglicht ein externes Backup eine saubere Versionierung und einen schnellen Vergleich zwischen Ständen.
- Startup-Config schützt vor Verlust nach Neustart, aber nicht vor Hardwareausfall.
- Externe Backups ermöglichen Wiederherstellung auf Ersatzhardware.
- Versionierung macht Änderungen nachvollziehbar (Audit/Compliance).
- Standardisierung reduziert Ausfallzeiten, weil der Restore planbar ist.
Grundlagen: running-config, startup-config und typische Speicherorte
Auf Cisco-Geräten ist die laufende Konfiguration (running-config) aktiv im RAM. Die Startkonfiguration (startup-config) liegt in einem nichtflüchtigen Speicher (oft NVRAM oder ein vergleichbarer persistenter Bereich, je nach Plattform). Beim Booten wird die startup-config geladen und zur running-config. Für Backups ist wichtig: In der Regel sichern Sie entweder die running-config (aktueller Zustand) oder die startup-config (persistierter Zustand). In vielen Umgebungen wird beides gesichert, um Unterschiede schnell nachvollziehen zu können.
show running-config(aktiver Zustand)show startup-config(gespeicherter Zustand)copy running-config startup-config(persistieren)
Backup-Strategie: Welche Konfig sichern Sie wann?
Für ein praxistaugliches Konzept lohnt es sich, vorab festzulegen, welche Backup-Typen Sie pflegen. Eine einfache, aber sehr effektive Strategie besteht aus drei Ebenen:
- Vor-Änderung-Backup: Direkt vor Wartungsarbeiten (Rollback-Option).
- Nach-Änderung-Backup: Nach erfolgreichem Test und Speichern (neuer Soll-Stand).
- Regelmäßiges Routine-Backup: Täglich oder wöchentlich, unabhängig von Änderungen.
Zusätzlich empfiehlt sich eine klare Dateibenennung, zum Beispiel mit Hostname, Datum und Uhrzeit: SW-ACCESS-01_2026-02-22_2100.cfg. Das erleichtert Wiederherstellung und Auditierung.
Schritt 1: Konfiguration lokal korrekt speichern
Bevor Sie ein externes Backup erstellen, sollten Sie sicherstellen, dass der gewünschte Stand auch lokal sauber persistiert ist. Andernfalls sichern Sie zwar die running-config, riskieren aber Inkonsistenzen, falls später ein ungeplanter Neustart erfolgt.
copy running-config startup-config
Prüfen Sie danach stichprobenartig:
show startup-config | include hostname
Schritt 2: Manuelles Backup per CLI auf einen Server übertragen
Für ein einfaches Setup reicht es oft, die Konfig per CLI auf einen Server zu kopieren. Welche Protokolle verfügbar sind, hängt von Plattform, Image und Umgebung ab. Aus Sicherheitsgründen sollten Sie nach Möglichkeit sichere Protokolle bevorzugen.
Option A: Backup per SCP (empfohlen)
SCP nutzt SSH als Transport und ist in vielen Umgebungen die pragmatische Standardwahl. Sie benötigen dafür SSH-Konnektivität zum Zielsystem sowie passende Zugangsdaten.
copy running-config scp:
Das Gerät fragt typischerweise nach Zieladresse, Benutzername, Pfad und Dateiname. Alternativ wird je nach IOS-Version eine URL-ähnliche Eingabe unterstützt. Für herstellerseitige Details eignet sich der Anchor-Text Cisco Secure Copy (SCP) und SFTP.
Option B: Backup per SFTP (empfohlen, wenn verfügbar)
SFTP ist ebenfalls SSH-basiert und wird in vielen Sicherheitsrichtlinien SCP gleichgestellt oder bevorzugt, weil es zusätzliche Funktionen bietet. Die konkrete Unterstützung hängt vom Gerät ab.
copy running-config sftp:
Option C: Backup per TFTP (nur für Lab oder streng isolierte Netze)
TFTP ist einfach, aber unsicher: keine Verschlüsselung, keine starke Authentifizierung. In produktiven Umgebungen ist TFTP daher meist nur in stark isolierten Management-Segmenten akzeptabel oder wird komplett vermieden.
copy running-config tftp:
Wenn TFTP genutzt wird, sollte das ausschließlich in kontrollierten Umgebungen erfolgen und durch Segmentierung sowie restriktive ACLs abgesichert sein.
Schritt 3: Backup der startup-config und Vergleichbarkeit
In vielen Betriebsmodellen ist es sinnvoll, zusätzlich die startup-config zu sichern – insbesondere, wenn Sie nachweisen möchten, welcher Stand dauerhaft gespeichert ist. Das ist hilfreich, wenn Änderungen getestet, aber absichtlich nicht gespeichert wurden.
copy startup-config scp:
Alternativ (je nach Protokoll):
copy startup-config sftp:
copy startup-config tftp:
Wenn Sie Unterschiede schnell erkennen möchten, prüfen Sie gezielt Abschnitte in beiden Konfigurationen:
show running-config | section line vty
show startup-config | section line vty
Best Practices für sichere Backups: Zugriff, Segmentierung und Datenhygiene
Backups enthalten sensible Informationen: IP-Adresspläne, VLAN-Strukturen, teilweise Passwörter, SNMP-Communitys oder Schlüsselmaterial (abhängig von Plattform und Features). Deshalb sollten Backup-Prozesse immer auch Sicherheitsaspekte berücksichtigen.
- Management-Netz trennen: Backup-Transfers nur aus einem dedizierten Management-VLAN/VRF.
- Protokolle absichern: SCP/SFTP statt TFTP/FTP, Telnet vermeiden.
- Zugriff einschränken: Backup-Server nur für Admin-Quellen erreichbar machen.
- Aufbewahrung: Retention-Regeln definieren (z. B. 30/90/365 Tage).
- Verschlüsselung at rest: Backups auf dem Server verschlüsselt ablegen.
- Integrität: Hashes oder signierte Artefakte bei hohen Anforderungen.
Als herstellerneutrale Orientierung für Sicherheitsmaßnahmen eignen sich die Empfehlungen über den Anchor-Text CIS Controls.
Wiederherstellung: Konfiguration sicher zurückspielen
Ein Backup ist nur dann wertvoll, wenn die Wiederherstellung verlässlich funktioniert. Die Restore-Strategie hängt davon ab, ob Sie auf demselben Gerät wiederherstellen, auf Ersatzhardware migrieren oder nur einzelne Konfigurationsblöcke übernehmen möchten.
Restore in die running-config (sofort aktiv)
Wenn Sie eine Konfiguration in die running-config kopieren, wird sie sofort wirksam. Das ist praktisch, kann aber auch riskant sein, wenn der Restore Netzwerkzugang oder SSH-Einstellungen verändert. Nutzen Sie diese Methode bevorzugt, wenn Sie lokal über Konsole verbunden sind oder einen Out-of-Band-Zugang haben.
copy scp: running-config
Je nach Umgebung können auch SFTP oder TFTP als Quelle genutzt werden:
copy sftp: running-config
copy tftp: running-config
Restore in die startup-config (wirksam nach Neustart)
Wenn Sie eine Konfiguration zunächst in die startup-config schreiben, wird sie erst beim nächsten Reload aktiv. Das kann in Wartungsfenstern sinnvoll sein, wenn Sie den Zeitpunkt der Aktivierung kontrollieren möchten.
copy scp: startup-config
Danach prüfen und erst dann neu starten:
show startup-config
reload
Teilweiser Restore: Nur relevante Abschnitte übernehmen
In vielen Fällen möchten Sie nicht „alles“ zurückspielen, sondern nur einzelne Bausteine, beispielsweise VTY/SSH-Härtung, VLAN-Definitionen oder Interface-Beschreibungen. Dafür ist es oft sinnvoll, die Backup-Datei extern zu öffnen, die relevanten Blöcke zu prüfen und manuell einzupflegen. Das reduziert das Risiko, ungewollt Routing, NAT oder Management-IP zu überschreiben.
Restore-Checkliste: So vermeiden Sie Selbst-Aussperrung
Gerade bei Remote-Restores ist das Risiko hoch, sich durch einen Restore die eigene Verbindung abzuschneiden. Die folgenden Punkte reduzieren dieses Risiko deutlich:
- Konsole/Out-of-Band bevorzugen: Restore idealerweise über Konsole durchführen.
- Management-IP und Gateway prüfen: Vor und nach dem Restore Erreichbarkeit testen.
- VTY/SSH-Regeln beachten: ACLs,
transport inputundloginkönnen den Zugang sperren. - Änderungen in kleinen Schritten: Wenn möglich, Konfig in Blöcken anwenden.
- Nach jedem Schritt verifizieren: Show-Befehle und Ping/SSH-Test.
Verifikation nach Backup und Restore: Was Sie unbedingt prüfen sollten
Nach dem Sichern und insbesondere nach einer Wiederherstellung sollten Sie den Zustand des Geräts systematisch überprüfen. Ziel ist nicht nur, dass „es wieder läuft“, sondern dass die Kernfunktionen erwartungsgemäß arbeiten.
show running-config | include hostname(richtiges Gerät/Stand?)show ip interface brief(Interface-Status, IPs plausibel?)show ip route(Routingtabellen plausibel?)show logging(Fehlerhinweise nach Apply/Reload?)
Für Switches ergänzend:
show vlan brief(VLANs und Portzuordnung)show interfaces trunk(Trunks, Allowed VLANs)show spanning-tree(STP-Status)
Für SSH/Remotezugang:
show ip sshshow running-config | section line vty
Versionierung und Ordnung: So werden Backups wirklich nutzbar
Ein „Ordner voller CFG-Dateien“ ist noch kein sinnvolles Backup-System. Entscheidend ist, dass Sie Stände schnell finden, Änderungen nachvollziehen und im Notfall die richtige Datei auswählen. Eine praxiserprobte Struktur besteht aus:
- Ordner pro Gerät oder pro Standort/Rolle (z. B.
BER/ACCESS,BER/EDGE). - Dateinamen mit Hostname und Zeitstempel.
- Metadaten in einem Begleittext (Change-Ticket, kurzer Grund, verantwortliche Person).
- Retention: alte Backups automatisch löschen oder archivieren.
Wenn Sie bereits mit Git oder einem Konfigurationsmanagement arbeiten, können Sie Konfigurationen als Textdateien versionieren. Das erleichtert Diff-Vergleiche und macht Änderungen auditierbar.
Automatisierung: Regelmäßige Backups ohne manuellen Aufwand
In produktiven Umgebungen werden Backups oft automatisiert, um menschliche Fehler (vergessenes Backup) zu vermeiden. Typische Ansätze sind:
- Network Configuration Manager: Tools, die Konfigs regelmäßig abrufen, versionieren und Changes melden.
- Skripting/Automation: z. B. per SSH und standardisierten Kommandos, inklusive Zeitplan.
- Event-getriebene Sicherung: Backup nach jeder bestätigten Änderung (Change Window).
Wichtig ist dabei, dass Automatisierung nicht nur „sammelt“, sondern auch Zugriff und Speicherung sicher gestaltet: Secrets geschützt, Server gehärtet, Backups verschlüsselt abgelegt.
Praxisbeispiel: Minimal-Workflow für Einsteiger
Wenn Sie gerade starten, ist ein schlanker Workflow besser als gar keiner. Das folgende Vorgehen ist einfach, aber praxistauglich:
- Nach Änderungen speichern:
copy running-config startup-config - Konfig exportieren (bevorzugt SCP):
copy running-config scp: - Dateiname mit Zeitstempel wählen.
- Kurzer Check der Erreichbarkeit und SSH-Zugriffe.
Ein kurzer Prüfblock danach:
show ip interface brief
show ip ssh
show running-config | include hostname
Weiterführende Quellen: Offizielle Referenzen zu Backup und sicheren Transfers
Je nach Plattform und IOS/IOS XE-Version kann die genaue Syntax oder Protokollunterstützung variieren. Für sichere Dateiübertragung und Backup-Mechanismen sind offizielle Cisco-Quellen besonders hilfreich, insbesondere wenn Sie SCP/SFTP oder fortgeschrittene Sicherheitsoptionen einführen möchten. Nutzen Sie dafür den Anchor-Text Cisco Secure Copy (SCP) und SFTP sowie den Anchor-Text Cisco Support für plattformspezifische Guides und Command References.
Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte
Cisco Networking • CCNA • Packet Tracer • Network Configuration
Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.
Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.
Leistungsumfang:
-
Netzwerkdesign & Topologie-Planung
-
Router- & Switch-Konfiguration (Cisco IOS)
-
VLAN, Inter-VLAN Routing
-
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
-
NAT, ACL, DHCP, DNS-Konfiguration
-
Troubleshooting & Netzwerkoptimierung
-
Packet Tracer Projektentwicklung & Dokumentation
-
CCNA Lern- & Praxisunterstützung
Lieferumfang:
-
Konfigurationsdateien
-
Packet-Tracer-Dateien (.pkt)
-
Netzwerkdokumentation
-
Schritt-für-Schritt-Erklärungen (auf Wunsch)
Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert
CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.












