Regelmäßige Konfigurations-Backups sind eine der wichtigsten „Low Effort, High Impact“-Maßnahmen im Netzwerkbetrieb. Wenn ein Switch ausfällt, falsch konfiguriert wurde oder ein Update schiefgeht, ist eine aktuelle Startup-/Running-Config oft der schnellste Weg zurück in einen stabilen Zustand. In Cisco-Umgebungen lassen sich Backups klassisch per TFTP oder deutlich sicherer per SCP automatisieren. Dieser Leitfaden zeigt praxistaugliche Verfahren, typische Befehle und Best Practices, damit Backups zuverlässig laufen – ohne Klartext-Passwörter und ohne Chaos im Dateinamen.
SCP vs. TFTP: Welche Methode ist wann sinnvoll?
TFTP ist einfach, aber unsicher: keine Verschlüsselung, keine echte Authentifizierung. SCP ist verschlüsselt (SSH) und daher im Enterprise-Betrieb die bessere Wahl. TFTP kann in isolierten Management-Netzen als „Notfall/Legacy“ noch vorkommen, sollte aber nicht der Standard sein.
- SCP: verschlüsselt, authentifiziert, empfehlenswert
- TFTP: unverschlüsselt, riskant, nur in streng isolierten Netzen
- Best Practice: SCP für Standard-Backups, TFTP nur für Sonderfälle
Vorbereitung: Management-Pfad und Namensstandard festlegen
Automatisierte Backups funktionieren nur, wenn der Switch den Backup-Server zuverlässig erreicht. Definiere außerdem ein konsistentes Naming (Hostname + Datum), damit Versionierung und Restore einfach bleiben.
- Backup-Server im Management-VLAN/VRF erreichbar
- DNS/Hostname sauber (für Dateinamen und Audit)
- Source-Interface setzen (damit die richtige IP als Absender genutzt wird)
- Dateiname:
<hostname>_YYYYMMDD_HHMM.cfg(praxisnah)
Basis-Checks
show ip interface brief
show running-config | include hostname
ping 10.1.99.80
SCP-Backup: Sicherer Standard über SSH
Für SCP muss der Switch SSH nutzen und „scp server enable“ (plattformabhängig) gesetzt sein, wenn der Switch selbst als SCP-Server dienen soll. Für Backups vom Switch zu einem SCP-Server reicht in der Regel die Client-Funktion plus Reachability.
SCP als Transport aktivieren (IOS/IOS XE, plattformabhängig)
enable
configure terminal
ip domain-name corp.local
crypto key generate rsa modulus 2048
ip ssh version 2
ip scp server enable
end
Source-Interface für Management-Transfers setzen
configure terminal
ip ssh source-interface vlan 99
ip tftp source-interface vlan 99
end
Backup per SCP: Running-Config und Startup-Config kopieren
Im Alltag sicherst du meist die Running-Config (aktueller Zustand). Zusätzlich kann es sinnvoll sein, auch die Startup-Config zu sichern (nach copy run start identisch, aber im Incident hilfreich).
Running-Config per SCP sichern (Beispiel)
copy running-config scp://backupuser@10.1.99.80//backups/SW-ACCESS-01_running.cfg
Startup-Config per SCP sichern (Beispiel)
copy startup-config scp://backupuser@10.1.99.80//backups/SW-ACCESS-01_startup.cfg
Praxis-Tipp: Interaktive Passwortabfrage
Bei manueller Ausführung fragt der Switch typischerweise das Passwort interaktiv ab. Für echte Automation nutzt du entweder AAA/SSH-Keys (wo unterstützt) oder steuerst den Prozess über ein Management-System (z. B. Ansible, RANCID/Oxidized), statt Passwörter in Skripten zu hinterlegen.
TFTP-Backup: Legacy-Variante (nur in isolierten Netzen)
TFTP ist schnell und simpel, aber unsicher. Wenn du es nutzen musst, dann nur in einem strikt isolierten Management-Netz und idealerweise nur intern. Achte auf Source-Interface und saubere Dateinamen.
TFTP Copy (Running-Config)
copy running-config tftp:
Address or name of remote host []? 10.1.99.80
Destination filename [running-config]? SW-ACCESS-01_20260303_1200.cfg
TFTP Copy (Startup-Config)
copy startup-config tftp:
Address or name of remote host []? 10.1.99.80
Destination filename [startup-config]? SW-ACCESS-01_startup_20260303_1200.cfg
Automatisierung ohne externe Tools: Kron/Archive als „On-Box“ Optionen
Wenn du Backups direkt vom Switch zeitgesteuert auslösen willst, gibt es je nach IOS/IOS XE Mechanismen wie kron oder archive. Diese Optionen sind praktisch, aber weniger flexibel als zentrale Tools und müssen sicher betrieben werden.
Archive: Konfigänderungen lokal versionieren (ergänzend)
configure terminal
archive
path flash:archive_cfg
maximum 10
write-memory
end
Vorteil
Auch ohne Server hast du mehrere lokale Versionen. Das ersetzt kein zentrales Backup, ist aber ein hilfreiches Sicherheitsnetz.
Best Practices für echte Backup-Automation (PRTG/Zabbix/Ansible/RANCID)
In professionellen Umgebungen wird der Backup-Job meist zentral orchestriert: Das System loggt sich ein, zieht Konfigurationen regelmäßig und versioniert sie (Git/Repo). So vermeidest du Passwörter im Klartext und bekommst Diffs „for free“.
- Zentrales Tool nutzt SSH/SCP und verwaltet Credentials sicher
- Versionierung pro Gerät (Hostname, Datum, Diff)
- Automatische Benachrichtigung bei Änderungen oder Fehlschlägen
- Backup-Server redundant und geschützt (ACLs, Zugriffskontrolle)
Troubleshooting: Wenn SCP/TFTP Backups fehlschlagen
Die häufigsten Ursachen sind Erreichbarkeit, falsches Source-Interface, ACLs/Firewall-Regeln oder Auth-Probleme. Prüfe zuerst Connectivity, dann Services, dann Credentials.
Connectivity und Source prüfen
ping 10.1.99.80
show ip route
show running-config | include source-interface
SSH/SCP Status prüfen
show ip ssh
show running-config | include ip scp|ip ssh
TFTP typische Fehler
- UDP/69 blockiert oder TFTP-Root falsch
- Falscher Dateiname/Path
- Backup-Server nicht im gleichen Routing-Kontext
Standardprozess: Backup vor und nach Changes
Backups sind besonders wertvoll im Change-Kontext. Ein bewährter Prozess: vor dem Change Running-Config sichern, nach dem Change Running-Config sichern und Diffs prüfen. So ist Rollback jederzeit möglich.
- Pre-Change Backup (Running-Config)
- Change durchführen
- Post-Change Backup + Diff
- Konfiguration speichern (
copy run start)
Konfig speichern (Basis)
copy running-config startup-config
Best Practices zusammengefasst
Ein gutes Backup-Setup ist sicher, zuverlässig und auditierbar. SCP ist der Standard, TFTP ist Legacy. Zentral orchestrierte Backups sind im Betrieb meist besser als „On-Box“ Jobs.
- SCP statt TFTP (verschlüsselt, authentifiziert)
- Source-Interface auf MGMT setzen
- Backups zentral versionieren (Host + Datum + Diff)
- Backups vor/nach Changes verpflichtend
- Backup-Server per ACLs absichern, Zugriffe minimal halten
copy running-config startup-config
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)
Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.
Was ich (je nach Paket) umsetze
-
Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)
-
Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)
-
Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation
-
Optional Security: Basic ACLs und SSH-Hardening
-
Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)
Sie erhalten
-
✅ Packet Tracer .pkt Datei
-
✅ Saubere Konfigurations-Notizen pro Gerät
-
✅ Verifikations-Checkliste + erwartete Outputs
-
✅ Kurze Dokumentation (wie die Topologie funktioniert)
Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.
Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.
