Cisco Network Backup & Disaster Recovery Automation: Restore และ RPO/RTO

Networking / Cisco / Network Operations

การสำรองและกู้คืน Configuration ของ Cisco Switch/Router อย่างเป็นระบบ พร้อมตัวอย่าง Automation, RPO/RTO และ Restore Testing

1. ทำไม Cisco Network Backup และ Disaster Recovery จึงสำคัญ

เมื่อ Switch หรือ Router เสียหาย ถูกตั้งค่าผิดพลาด หรือเกิดเหตุด้านความปลอดภัย การมี Configuration Backup ที่ตรวจสอบและกู้คืนได้จริง ช่วยลดเวลาหยุดให้บริการและความผิดพลาดจากการตั้งค่าใหม่ด้วยมือ แต่ไฟล์ Backup เพียงอย่างเดียวไม่ใช่แผน Disaster Recovery (DR)

DR ที่สมบูรณ์ต้องมี Device Inventory, Firmware/License Compatibility, Network Diagram, Credentials ที่จัดเก็บปลอดภัย, Recovery Runbook, การทดสอบ และผู้อนุมัติ รวมถึงการประเมินผลกระทบต่อระบบที่เชื่อมต่อ เช่น Firewall, DHCP, Routing และ Monitoring

2. สถาปัตยกรรมการสำรองข้อมูลเครือข่าย

ตัวอย่างระบบ Lab มี SW01 (192.168.99.11), SW02 (192.168.99.12) และ R01 (192.168.99.13) อยู่บน Management Network โดยมี Automation Host เชื่อมต่อผ่าน SSH และส่ง Backup ไปยัง Storage ที่จำกัดสิทธิ์

Cisco SW01 / SW02 / R01
       | SSH (Management VLAN)
       v
Automation Host (Python / Ansible)
       |  validate + SHA-256 + inventory
       v
Encrypted Backup Repository
       |  off-site / immutable copy
       v
DR Recovery Workstation (authorized only)

ข้อควรระวัง: อย่าใช้ Production เป็นพื้นที่ทดลอง Restore และอย่าเก็บรหัสผ่านหรือ Secret ใน Git Repository หรือโฟลเดอร์ที่เปิดสาธารณะ

3. กำหนด Backup Scope และ Recovery Priority

รายการ	สิ่งที่ต้องเก็บ	หมายเหตุ
Running Configuration	show running-config	สถานะที่กำลังใช้งาน อาจยังไม่บันทึกถาวร
Startup Configuration	show startup-config	ค่าที่อุปกรณ์ใช้เมื่อเริ่มต้นใหม่
Device Inventory	Model, Serial, IOS/IOS XE Version	ตรวจสอบ Hardware/Software Compatibility
Interface & VLAN	show interfaces status, show vlan brief	คำสั่งขึ้นกับรุ่นและแพลตฟอร์ม
Routing & HA	show ip route, show standby brief	ตรวจสอบเส้นทางและ Redundancy
Firmware/License	เวอร์ชัน, License Entitlement, Image Hash	จัดเก็บตามสิทธิ์และนโยบายองค์กร
Topology & Port Map	Network Diagram, IP Plan, Cable Map	ใช้ประกอบการเปลี่ยนอุปกรณ์

ข้อมูลบางรายการ เช่น Private Key, Certificate หรือ License อาจต้องใช้ขั้นตอน Backup เฉพาะรุ่น ไม่ควรสมมติว่า show running-config ครอบคลุมทั้งหมด

4. กำหนด RPO, RTO และความถี่การสำรอง

RPO (Recovery Point Objective) คือช่วงข้อมูลหรือ Configuration ที่ยอมสูญเสียได้ ส่วน RTO (Recovery Time Objective) คือเวลาสูงสุดที่ตั้งเป้าให้บริการกลับมาใช้งานได้ ทั้งสองเป็นเป้าหมายที่ต้องได้รับอนุมัติและทดสอบ ไม่ใช่เวลาที่รับประกันจากการมีไฟล์ Backup

ระบบตัวอย่าง	RPO เป้าหมาย	RTO เป้าหมาย	กลยุทธ์
Core/Distribution	หลังทุก Change และอย่างน้อยรายวัน	2 ชั่วโมง	Spare พร้อมใช้งาน + Tested Restore
Access Switch	หลังทุก Change และรายวัน	4 ชั่วโมง	Standard Template + Spare
Lab/Noncritical	รายสัปดาห์	1 วันทำการ	Scheduled Restore

ตัวเลขในตารางเป็น สมมติฐานสำหรับวางแผน ต้องปรับตาม SLA, จำนวนอะไหล่, ความพร้อมของทีม และการพึ่งพาระบบจริง หาก Configuration เปลี่ยนระหว่างรอบ Backup ต้องมี Event-Driven Backup หลังอนุมัติ Change

5. Cisco CLI: ตรวจสอบและสำรอง Configuration

5.1 ตรวจสอบก่อน Backup

show version
show inventory
show running-config
show startup-config
show ip interface brief
show logging | last 30

บาง IOS ไม่รองรับ | last ให้ใช้คำสั่งที่รองรับบนรุ่นนั้นและตรวจสอบ Output ด้วยตนเอง ก่อนบันทึกให้ตรวจสอบว่าการเข้าถึงผ่าน SSH และสิทธิ์บัญชีถูกต้อง

5.2 การส่งไฟล์ด้วย SCP

! ตัวอย่างคำสั่งบนอุปกรณ์ที่รองรับ SCP client
copy running-config scp:
! ตอบ prompt: remote host, destination filename และ credentials

ต้องตรวจสอบความสามารถ SCP ของอุปกรณ์และตั้งค่า SSH/AAA ตามนโยบายก่อนใช้จริง หากมีข้อมูลลับใน Configuration ต้องป้องกันทั้งช่องทางส่งและปลายทางจัดเก็บ ไม่ควรเปิด TFTP ใน Production โดยไม่ประเมินความเสี่ยง

6. Python + Netmiko: Automated Read-Only Backup

ตัวอย่างนี้ใช้ Python และ Netmiko อ่าน show running-config จากอุปกรณ์ที่ได้รับอนุญาต พร้อมบันทึก Hash SHA-256 เพื่อใช้ตรวจสอบความสมบูรณ์ของไฟล์ภายหลัง ไม่แก้ Configuration ของอุปกรณ์

python -m venv .venv
# Linux/macOS: source .venv/bin/activate
# Windows PowerShell: .venv\Scripts\Activate.ps1
python -m pip install netmiko

6.1 ตัวอย่าง inventory.csv

name,host,device_type
SW01,192.168.99.11,cisco_ios
SW02,192.168.99.12,cisco_ios
R01,192.168.99.13,cisco_ios

6.2 Python Script สำหรับ Backup และ Hash

import csv
import getpass
import hashlib
from datetime import datetime, timezone
from pathlib import Path
from netmiko import ConnectHandler

backup_dir = Path("backups")
backup_dir.mkdir(mode=0o700, exist_ok=True)
username = input("SSH username: ")
password = getpass.getpass("SSH password: ")
secret = getpass.getpass("Enable secret (blank if not needed): ")
timestamp = datetime.now(timezone.utc).strftime("%Y%m%dT%H%M%SZ")

with open("inventory.csv", newline="", encoding="utf-8") as f:
    for device in csv.DictReader(f):
        name = device["name"]
        try:
            params = {
                "device_type": device["device_type"],
                "host": device["host"],
                "username": username,
                "password": password,
            }
            if secret:
                params["secret"] = secret
            with ConnectHandler(**params) as conn:
                if secret:
                    conn.enable()
                config = conn.send_command(
                    "show running-config", read_timeout=90
                )
            if not config.strip() or "Invalid input" in config:
                raise ValueError("Empty or invalid configuration output")
            data = config.encode("utf-8")
            filename = backup_dir / f"{name}-{timestamp}.cfg"
            with filename.open("xb") as out:
                out.write(data)
            digest = hashlib.sha256(data).hexdigest()
            (backup_dir / f"{name}-{timestamp}.sha256").write_text(
                f"{digest}  {filename.name}\n", encoding="utf-8"
            )
            print(f"{name}: backup saved; SHA256={digest}")
        except Exception as exc:
            print(f"{name}: BACKUP FAILED ({type(exc).__name__})")

ข้อจำกัด: Script นี้เป็นตัวอย่าง Lab ไม่ได้ตรวจสอบ Host Key อย่างเข้มงวดด้วยตนเอง, ไม่มี Secret Manager, ไม่มีการเข้ารหัสไฟล์ปลายทาง และยังไม่รองรับ Retry/Alert/Retention Policy ก่อนใช้ Production ควรเพิ่มมาตรการเหล่านี้และกำหนดสิทธิ์โฟลเดอร์ให้เหมาะกับระบบปฏิบัติการ

7. Ansible: Configuration Backup แบบหลายอุปกรณ์

เมื่อมี Switch/Router หลายสิบตัว สามารถใช้ Ansible Inventory และ cisco.ios.ios_config เพื่อสำรอง Running Configuration แบบรวมศูนย์ได้

# playbooks/backup.yml
---
- name: Back up Cisco IOS configuration
  hosts: cisco
  gather_facts: false
  tasks:
    - name: Back up running configuration
      cisco.ios.ios_config:
        backup: true
        backup_options:
          dir_path: ./backups

ansible-galaxy collection install cisco.ios ansible.netcommon
ansible-playbook -i inventory/hosts.yml playbooks/backup.yml --limit SW01 -k

Inventory ต้องกำหนด ansible_connection: ansible.netcommon.network_cli และ ansible_network_os: cisco.ios.ios พร้อมบัญชีที่มีสิทธิ์อ่าน Configuration การใช้ -k เป็นการถาม SSH Password และบางระบบต้องมี Enable Password เพิ่มเติม ควรทดสอบเวอร์ชัน Collection/Ansible ที่ใช้งานก่อนนำขึ้น Production

8. ตรวจสอบ Backup Integrity, Security และ Retention

8.1 ตรวจสอบ Hash SHA-256

# Linux/macOS (ในโฟลเดอร์ backups)
sha256sum -c SW01-20261029T010000Z.sha256

# Windows PowerShell
Get-FileHash .\SW01-20261029T010000Z.cfg -Algorithm SHA256

เปลี่ยนชื่อไฟล์ให้ตรงกับไฟล์ที่สร้างจริง Hash ช่วยตรวจจับความเปลี่ยนแปลงของข้อมูล แต่ ไม่ได้พิสูจน์ว่า Backup กู้คืนได้ และไม่ป้องกันการแก้ไขทั้งไฟล์ Config และ Hash พร้อมกัน ต้องใช้ Access Control, Audit Log และ Storage ที่ป้องกันการแก้ไขร่วมด้วย

8.2 Retention และการเข้ารหัส

กำหนดนโยบายตัวอย่าง: Daily 30 วัน, Weekly 12 สัปดาห์, Monthly 12 เดือน โดยพิจารณาข้อกำหนดองค์กร ใช้ Encryption at Rest, Off-site Copy, Immutable Backup ตามความเหมาะสม และทดสอบ Restore เป็นรอบ ไม่ส่งไฟล์ Configuration ที่มีข้อมูลลับไปยังที่จัดเก็บสาธารณะ

9. Disaster Recovery: ขั้นตอนกู้คืน Cisco Switch/Router

หลักการสำคัญ: การกู้คืนต้องเริ่มจากประเมินผลกระทบและยืนยันว่า Hardware/IOS/License/Port Layout เข้ากันได้ ไม่ควรโหลด Configuration เก่าลงอุปกรณ์ใหม่ทันที เพราะอาจทำให้ IP ซ้ำ, Routing ผิด, Trunk ไม่ตรง หรือ Management Access หาย

ลำดับ	ขั้นตอน	หลักฐาน/ผลลัพธ์
1	ประกาศ Incident และอนุมัติ DR	Incident ID, Owner, Impact
2	แยกอุปกรณ์เสียและตรวจ Physical	Power, Uplink, Port Status
3	เตรียม Spare และตรวจรุ่น/IOS/License	Compatibility Checklist
4	ตรวจ Hash และเลือก Backup ที่อนุมัติ	Backup ID, Timestamp, SHA-256
5	ตรวจและปรับ Device-specific Settings	Hostname, Interface Mapping, Management IP
6	กู้คืนใน Lab/Isolated Segment ก่อน	Restore Test Evidence
7	เชื่อมต่อ Production ตาม Change Plan	Change Approval, Rollback Window
8	ตรวจสอบ Connectivity/Services	VLAN, Routing, HA, Logs, Monitoring
9	ส่งมอบและปิด Incident	Acceptance Sign-off, Updated Baseline

10. Restore Testing: Lab และ Acceptance Test

10.1 ทดสอบกู้คืนในสภาพแวดล้อมแยก

ใช้ Spare Switch ที่ได้รับอนุญาตและ แยกจาก Production Network ตรวจสอบ Console Access, รุ่นอุปกรณ์, Interface Mapping, Boot Image และ Backup ที่จะนำเข้า หลังตรวจ Configuration แบบออฟไลน์จึงเลือกวิธีกู้คืนตามคู่มือรุ่นนั้น

คำสั่ง copy ... startup-config และการ Reload มีผลต่อการทำงานจริง จึงไม่ควรทำโดยอัตโนมัติในบทเรียนหรือระหว่างให้บริการ

10.2 Cisco CLI สำหรับตรวจสอบหลัง Restore

show version
show inventory
show ip interface brief
show interfaces status
show vlan brief
show interfaces trunk
show spanning-tree summary
show ip route
show logging

เลือกคำสั่งตามความสามารถอุปกรณ์และบทบาทของอุปกรณ์ ไม่ใช่ทุก Router จะรองรับคำสั่ง Switching เช่น show vlan brief หรือ show interfaces trunk

10.3 Acceptance Criteria

รายการ	ตัวอย่างเกณฑ์ผ่าน
Management	เข้าถึง SSH/Console ผ่านช่องทางที่อนุมัติ
Layer 2	VLAN/Trunk/STP ถูกต้อง ไม่มี Loop
Layer 3	Gateway, Route, Neighbor/HA ตรง Baseline
Security	AAA, ACL, SNMPv3, Syslog ตาม Policy
Monitoring	NMS เห็นอุปกรณ์และส่ง Alert ได้
Service	ทดสอบบริการธุรกิจสำคัญผ่าน End-to-End

11. Recovery Runbook และบทบาททีมงาน

บทบาท	ความรับผิดชอบ
Incident Commander	ประเมิน Severity, อนุมัติ Escalation, ติดตามเวลา
Network Engineer	วิเคราะห์เหตุ เลือก Backup และตรวจ Configuration
Field Technician	ตรวจ Physical, เปลี่ยน Spare, เชื่อมต่อสายตาม Port Map
Security/IT	ตรวจเหตุด้านความปลอดภัยและอนุมัติการใช้ Credentials
Service Owner	ยืนยันบริการกลับมาใช้งานและลงนาม Acceptance

Runbook ควรระบุ Contact Tree, Escalation Matrix, Incident Severity, Maintenance Window, Backup Location, Recovery Dependency, Vendor Support, Communication Template และ Rollback Criteria โดยไม่เปิดเผย Password ในเอกสาร

12. Troubleshooting เมื่อ Backup หรือ Restore ล้มเหลว

อาการ	สาเหตุที่เป็นไปได้	วิธีตรวจสอบ
SSH Timeout	Management Network/ACL/SSH Service	Ping/Route/ACL/SSH Log
Authentication Failed	AAA หรือสิทธิ์บัญชีไม่ถูกต้อง	ตรวจ AAA/TACACS+ และสิทธิ์ตาม Policy
Backup Empty/Truncated	Privilege ไม่พอ หรือ Command Timeout	ตรวจ Output, เพิ่ม Timeout, Compare Baseline
Hash Mismatch	ไฟล์เปลี่ยนหรือคัดลอกไม่ครบ	หยุดใช้ไฟล์และสอบสวนแหล่งที่มา
Restore Boot Failed	Image/License/Hardware ไม่เข้ากัน	ตรวจ Compatibility และ Console Log
Network Loop After Restore	Trunk/STP/Port Mapping ไม่ตรง	แยก Uplink และตรวจ Topology
Service Still Down	Routing/DNS/Firewall/Dependencies	ทดสอบ End-to-End และตรวจ Logs

13. Hands-on Lab: Backup → Validate → Restore Drill

สร้าง Inventory ของ SW01 และ SW02 ใน Lab พร้อมบันทึก Model, Serial, IOS และ Management IP
เชื่อมต่อ SSH ด้วยบัญชี Read-Only ที่ได้รับอนุญาตและรัน Script Backup
ตรวจไฟล์ .cfg และ SHA-256 พร้อมบันทึก Timestamp
ทดสอบ Integrity โดยคัดลอกไฟล์และเปลี่ยนข้อมูลในสำเนาเพื่อดูว่า Hash ไม่ตรงกัน
เตรียม Spare หรือ Emulator ที่รองรับและทบทวน Configuration โดยไม่เชื่อมต่อ Production
ทำ Restore Drill ตามคู่มืออุปกรณ์ พร้อมตรวจ VLAN, Interface, Routing และ Management Access
บันทึกเวลาที่ใช้จริง เปรียบเทียบ RTO เป้าหมาย และจัดทำ Improvement Action

เกณฑ์ผ่าน: มี Backup ที่อ่านได้, Hash ตรง, Restore Drill ผ่าน Acceptance Checklist และมี Evidence พร้อมผู้ตรวจสอบรับรอง

14. FAQ และสรุปแนวทาง Production

Backup Running Config ต่างจาก Startup Config อย่างไร?

Running Configuration คือค่าที่ใช้งานอยู่ ส่วน Startup Configuration คือค่าที่อุปกรณ์จะโหลดเมื่อเริ่มต้นใหม่ หากมีการเปลี่ยนค่าแต่ยังไม่ Save ทั้งสองอาจไม่ตรงกัน จึงควรเก็บและเปรียบเทียบตามนโยบาย

มี Backup แล้วถือว่าพร้อม Disaster Recovery หรือไม่?

ยังไม่เพียงพอ ต้องมีอุปกรณ์ทดแทนที่เข้ากันได้, Recovery Runbook, Credentials, Firmware/License, Network Documentation, การทดสอบจริง และผู้รับผิดชอบที่ชัดเจน

ควร Backup บ่อยแค่ไหน?

อย่างน้อยควรสำรองหลังการเปลี่ยน Configuration ที่อนุมัติ และตามรอบที่สัมพันธ์กับ RPO ของระบบ พร้อมแจ้งเตือนเมื่อ Backup ล้มเหลว

สรุป: ระบบ Cisco Network Backup & Disaster Recovery ที่เชื่อถือได้ต้องทำได้ครบวงจรตั้งแต่ Inventory → Backup → Integrity Check → Secure Storage → Restore Testing → Acceptance → Continuous Improvement ไม่ใช่เพียงมีไฟล์ Config เก็บไว้