Veeam Backup & Replication — Đại Học

Tuần 15: Lab 14-15 & Case Studies thực tế

Trang chủ / Tuần 15 — Lab 14-15 & Case Studies

Kết Quả Học Tập

LAB 14: Full Enterprise DR Simulation

DR drill = kiểm tra toàn bộ DR plan trong môi trường prod-like. Mục tiêu: xác nhận RTO/RPO thực tế đạt yêu cầu, phát hiện điểm yếu trong quy trình, huấn luyện đội ngũ phản ứng sự cố.

Kịch Bản: "Ngày thứ Sáu, 10:00 PM — HCM Datacenter Bốc Cháy"

Thông báo từ NOC (22:03):
  ALERT: FIRE_DETECTED — DATACENTER_HCM
  Status: TOTAL_LOSS — All systems offline
  Affected: 85 Production VMs, 3 DB clusters
  Last backup: 21:15 (45 minutes ago)
  DR Site: HN datacenter — ONLINE, READY
  Action required: IMMEDIATE FAILOVER DECISION

Phase 1: Discovery & Assessment (22:00 — 22:30)

Bước 1: Nhận cảnh báo từ NOC — xác nhận severity
  → NOC: "HCM datacenter toàn bộ mất điện + hỏa hoạn"
  → Confirm: không phải false alarm (kiểm tra camera, liên hệ security)

Bước 2: Kích hoạt DR Plan
  → Gọi DR Coordinator (on-call)
  → Kích hoạt Emergency Communication Tree
  → Notify: CTO, CIO, Infrastructure Manager
  → Open DR runbook: /docs/dr-plan-v3.2.pdf

Bước 3: Đánh giá thiệt hại
  → HCM site: 100% mất — TOTAL LOSS confirmed
  → Inventory: 85 VMs, 3 DB clusters, 2 load balancers
  → Check HN site status: ALL GREEN ✓
  → Check last backup/replication timestamps

Bước 4: Quyết định Failover
  → Decision: FAILOVER TO HN SITE — approved by CTO
  → Assign roles: DBA team (DB tier), Infra team (App tier)
  → Set comms: status update every 30 minutes

Phase 2: Failover DB Tier (22:30 — 23:00)

DB tier là ưu tiên cao nhất — app servers không thể hoạt động nếu không có DB.

Veeam Console (HN site):
  Home → Replication → Failover Plans → DR-HCM-to-HN

  Hoặc manual failover từng VM:
  1. Home → Replicas → Ready → chọn DB-01, DB-02, DB-03
  2. Chuột phải → Failover Now
  3. Mode: Planned Failover (nếu source còn sống)
     Mode: Permanent Failover (nếu source đã mất hoàn toàn)
  4. Restore point: chọn bản gần nhất (21:15)
  5. Click Start

  Kết quả:
  DB-01 (Oracle Primary): RUNNING on HN-ESXi-01 ✓
  DB-02 (Oracle Standby): RUNNING on HN-ESXi-02 ✓
  DB-03 (MSSQL):          RUNNING on HN-ESXi-03 ✓

  Verify DB connectivity:
  → Test từ App-01: sqlplus sys@DB-01:1521 ✓
  → Test từ App-01: ping DB-01 ✓
  → Check Oracle alert log: no errors ✓

Lưu ý quan trọng: Với Oracle RAC, cần chạy srvctl start database -db PRODDB thủ công sau khi VM boot. Veeam không tự khởi động Oracle Clusterware.

Phase 3: Recovery App Tier (23:00 — 00:00)

Phương pháp: Instant Recovery (nhanh hơn full restore)

  Veeam Console → Home → Instant Recovery → Entire VM

  Danh sách VMs cần recover:
  ┌─────────────────┬──────────┬────────────────────┐
  │ VM Name         │ Priority │ Estimated Time      │
  ├─────────────────┼──────────┼────────────────────┤
  │ Web-01, Web-02  │ HIGH     │ ~6 min each         │
  │ App-01 .. App-10│ HIGH     │ ~6 min each         │
  └─────────────────┴──────────┴────────────────────┘

  Steps per VM:
  1. Select VM → Choose restore point (21:15)
  2. Target: HN-ESXi cluster
  3. Veeam mounts backup via NFS → VM starts in ~2 min
  4. Quick Migration: di chuyển VM storage về HN datastore
  5. Verify: ping, HTTP check, application log

  Timeline:
  → 12 VMs × ~6 min = ~72 min total
  → Concurrent: 3 VMs cùng lúc → thực tế ~25 min

  23:00: Start Web-01, Web-02, App-01 (concurrent)
  23:06: Start App-02, App-03, App-04
  23:12: Start App-05, App-06, App-07
  23:25: All VMs in Instant Recovery mode ✓
  23:55: Quick Migration hoàn tất tất cả VMs ✓

Phase 4: DNS & Load Balancer Update (00:00 — 00:30)

DNS Update:
  # Xóa record cũ (HCM IP)
  dig company.com → xóa A record 103.x.x.x (HCM)

  # Thêm record mới (HN IP)
  DNS Server → Edit Zone company.com
  A company.com → 14.x.x.x (HN Load Balancer)
  TTL: 60 giây (đã set thấp trước DR drill)

  Load Balancer (HN) Update:
  → Login: https://lb-hn.company.local/admin
  → Backend Pool: update VIP → HN VMs
  → Health check: enable HTTP/HTTPS checks
  → Test: curl -I https://company.com (từ external IP)
  → Expected: HTTP 200 OK ✓

Propagation check:
  → nslookup company.com 8.8.8.8
  → Expected: 14.x.x.x (HN IP) ✓
  → Browser test: https://company.com → login page loads ✓

Phase 5: Communication & Documentation (00:30)

Status Email Template (gửi 00:35):

  Subject: [DR UPDATE] HCM Datacenter Incident — Services RESTORED
  To: [email protected], [email protected]

  Kính gửi Ban Lãnh Đạo,

  Sự cố: Hỏa hoạn tại HCM datacenter (22:03, Thứ Sáu)
  Trạng thái hiện tại: ĐÃ PHỤC HỒI trên HN site

  Timeline:
  22:03 — Phát hiện sự cố
  22:30 — Kích hoạt DR Plan
  23:00 — DB tier online tại HN
  00:30 — Toàn bộ dịch vụ online tại HN
  00:35 — Email thông báo này

  Metrics thực tế:
  ├─ RTO achieved: 2.5 giờ (target: 4 giờ) ✓ VƯỢT MỤC TIÊU
  ├─ RPO achieved: 45 phút (target: 2 giờ) ✓ VƯỢT MỤC TIÊU
  └─ Services recovered: 100% (12/12 VMs online)

  Bước tiếp theo:
  → Điều tra nguyên nhân hỏa hoạn
  → Lên kế hoạch tái thiết HCM site
  → Lên lịch failback khi HCM sẵn sàng

Metrics: Target vs Actual

Metric Target Actual Status
RPO (data loss)2 giờ45 phútVƯỢT MỤC TIÊU
RTO (total recovery)4 giờ2.5 giờVƯỢT MỤC TIÊU
DB tier recovery30 phút28 phútĐẠT
App tier recovery2 giờ55 phútVƯỢT MỤC TIÊU
Services recovered100%100%ĐẠT
Zero data corruptionBắt buộcĐạtĐẠT

Post-DR Lessons Learned

  • Thành công: DNS TTL được set thấp (60s) từ trước — DNS propagation chỉ mất 2 phút
  • Thành công: Veeam replication lag chỉ 45 phút — gần với RPO target
  • Cần cải thiện: Oracle Clusterware không tự start — cần automation script
  • Cần cải thiện: Load balancer cần được update tự động qua Veeam DR scripts
  • Action item: Tạo automated DR runbook script (Ansible) để giảm manual steps

LAB 15: Failback — Trở Về HCM Site

Sau khi HCM datacenter được tái thiết (1-2 tuần sau sự cố), team cần thực hiện failback — di chuyển workload từ HN về HCM.

Bước 1: Tái Thiết HCM Infrastructure

Checklist HCM Site Rebuild:
  □ ESXi hosts: cài đặt vSphere 8 mới
  □ vCenter: cài đặt + join vCenter cluster
  □ Veeam Proxy: cài đặt tại HCM
  □ Repository: khởi tạo lại (SOBR + NAS)
  □ Network: VLAN production, backup, replication
  □ Power: UPS + generator tested
  □ Fire suppression: FM-200 recharged ✓

Bước 2: Thiết Lập Failback Replication (HN → HCM)

Veeam Console (HN) → Replicas → chọn tất cả VMs đang running
  → Chuột phải → Failback to Production

  OR tạo Replication Job mới:
  Source: VMs đang chạy tại HN
  Target: HCM vCenter (vừa rebuild)
  Schedule: continuous (realtime sync)

  Monitor: Jobs → Replication → HN-to-HCM
  Wait until: Initial sync complete (delta sync < 5 min lag)

Bước 3: Planned Failover về HCM

Chọn thời điểm: maintenance window (Chủ nhật 2:00 AM)

  1. Thông báo users: scheduled maintenance 2:00-4:00 AM
  2. Veeam → Replicas → HCM replicas → Planned Failover
  3. Veeam tự động:
     a) Tắt VMs tại HN
     b) Sync delta lần cuối → HCM replicas
     c) Khởi động VMs tại HCM
  4. Test: ping, HTTP, DB connection ✓
  5. Update DNS: company.com → HCM IP (103.x.x.x)
  6. Update Load Balancer: backend → HCM VMs
  7. Monitor 30 phút → confirm stable

Bước 4-5: Verify & Resume Normal Operations

Bước 4 — Verify HCM:
  □ Tất cả 12 VMs running tại HCM ✓
  □ Oracle DB: status OPEN, no errors ✓
  □ Web/App: HTTP 200 từ external ✓
  □ Users: login thành công ✓

Bước 5 — Resume Backup Operations:
  □ Backup jobs: schedule lại từ HCM source
  □ Replication: HCM → HN (bình thường)
  □ HN VMs (failback replicas): xóa sau 7 ngày confirm
  □ Update DR runbook: ghi nhận lessons từ incident
  □ Báo cáo: DR incident report → management

Case Study 1: Bệnh Viện Đa Khoa (HIPAA + Thông tư 24)

Bối Cảnh

Thông tin tổ chức:
├─ 500 giường bệnh, 2,000 nhân viên y tế
├─ Hệ thống HIS (Hospital Information System): Oracle DB 8TB
├─ PACS (Picture Archiving): 50TB X-ray, CT, MRI images
├─ EMR (Electronic Medical Records): SQL Server 3TB
│
Yêu cầu kinh doanh:
├─ RPO: 15 phút (bệnh nhân ICU không thể chờ > 15 phút)
├─ RTO: 30 phút (ER không thể thiếu HIS > 30 phút)
├─ Uptime: 99.9% (≤ 8.7 giờ downtime/năm)
│
Compliance requirements:
├─ HIPAA (partner với US hospital network)
├─ Thông tư 24/2023/TT-BYT (Bộ Y Tế VN)
└─ Lưu trữ 7 năm tối thiểu (hồ sơ bệnh nhân)

Giải Pháp Thiết Kế

Kiến trúc Veeam:
┌─────────────────────────────────────────────────────────┐
│                  BỆNH VIỆN — BACKUP ARCHITECTURE         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  HIS Oracle DB (8TB)                                    │
│  ├─ CDP Job → RPO 15 giây (Veeam CDP)                   │
│  ├─ Daily Full: 2:00 AM → NAS primary repo              │
│  └─ Backup Copy: 3:00 AM → Off-site NAS                 │
│                                                         │
│  PACS Imaging (50TB)                                    │
│  ├─ Weekly Full: Chủ nhật → NAS primary                 │
│  ├─ Daily incremental → NAS                             │
│  ├─ Monthly: export to LTO-9 Tape (off-site vault)      │
│  └─ Retention: 7 năm (tape không xóa được = WORM)       │
│                                                         │
│  EMR SQL Server (3TB)                                   │
│  ├─ Hourly incremental (CBT)                            │
│  └─ SureBackup hàng đêm (verify recoverability)         │
│                                                         │
│  Encryption: AES-256 tất cả backup jobs                 │
│  Key management: Hardware Security Module (HSM)          │
└─────────────────────────────────────────────────────────┘

Veeam Job Configuration:
  Job: HIS-CDP
  → Type: CDP Policy
  → Source: HIS-Oracle-01, HIS-Oracle-02 (cluster)
  → Target: CDP-Datastore (SSD, HN site)
  → RPO target: 15 giây
  → Journal: 24 giờ

  Job: PACS-Weekly
  → Type: Backup Job (Weekly Full)
  → GFS: Weekly 4, Monthly 12, Yearly 7
  → Target: SOBR (Performance: SSD, Capacity: NAS, Archive: Tape)
  → Encryption: AES-256, key: HSM-backed
Kết Quả Sau Triển Khai: Before vs After
Metric Before (Backup thủ công) After (Veeam CDP)
RPO (HIS)24 giờ15 giây
RTO (HIS)4-6 giờ22 phút
HIPAA auditKhông đạtĐạt (AES-256, immutable)
PACS retention3 năm (disk đầy)7 năm (tape archive)
Backup success rate67% (manual errors)99.8% (automated)

Bài Học: Vì Sao Tape Vẫn Quan Trọng với PACS?

  • 1. Immutability pháp lý: WORM tape không thể modify → chứng cứ pháp lý nếu tranh chấp y tế
  • 2. Chi phí thấp hơn disk: LTO-9 tape = $30/TB vs $200/TB HDD cho long-term archival
  • 3. Ransomware-proof: Tape offline = không thể bị mã hóa bởi ransomware
  • 4. Regulatory requirement: Thông tư 24 yêu cầu lưu trữ vật lý riêng biệt
  • 5. 50TB PACS × 7 năm = 350TB total — tape là lựa chọn kinh tế duy nhất

Case Study 2: Ngân Hàng TMCP (PCI-DSS + Thông tư 09 NHNN)

Bối Cảnh

Thông tin tổ chức:
├─ 200 chi nhánh toàn quốc
├─ Core banking (Temenos T24): Oracle RAC cluster, 20TB
├─ Internet Banking: 500,000 giao dịch/ngày
├─ ATM network: 3,000 máy ATM
│
Yêu cầu đặc biệt:
├─ RPO: ZERO — KHÔNG chấp nhận mất bất kỳ transaction nào
├─ RTO: 15 phút (Ngân hàng Nhà nước VN requirement)
├─ DR drill: bắt buộc hàng quý (theo Thông tư 09)
└─ PCI-DSS Level 1 (> 6 triệu transactions/năm)
│
Compliance:
├─ PCI-DSS v4.0 (Payment Card Industry)
├─ Thông tư 09/2020/TT-NHNN (NHNN)
└─ Circular 19/2018 (IT risk management)

Giải Pháp: CDP + Active-Active

Architecture: Active-Active Datacenter (HCM ↔ HN)

  T24 Core Banking:
  ├─ Oracle RAC: 4 nodes (HCM x2, HN x2)
  ├─ Veeam CDP: continuous replication
  │   → RPO measured in SECONDS (không phải phút)
  │   → CDP Journal: 24 giờ rollback
  ├─ RMAN Integration:
  │   → Veeam Plug-in for Oracle RMAN
  │   → Backup: RMAN → Veeam Repo (không dùng default CBT)
  │   → Schedule: archived logs every 15 min
  └─ Kết quả: Oracle-consistent backup

  Air-gap Tape:
  ├─ Daily export: 11:00 PM → LTO-9 tape library
  ├─ Tape vaulting: thuê xe tải bảo mật → vault offsite
  ├─ Retention: 7 năm (PCI-DSS yêu cầu)
  └─ Quarterly test restore (mandatory drill)

  DR Drill Process (Thông tư 09 compliant):
  Bước 1: Thông báo NHNN (48h trước)
  Bước 2: Thực hiện failover (Chủ nhật 2:00 AM)
  Bước 3: Test toàn bộ chức năng T24
  Bước 4: Nộp báo cáo kết quả cho NHNN (48h sau)

Challenge: Oracle RAC Backup — Không Dùng Default CBT

Oracle RAC có cấu trúc shared-disk đặc biệt — Changed Block Tracking (CBT) thông thường không capture đủ consistency cho Oracle.

# Giải pháp: Veeam Plug-in for Oracle RMAN
# Cài đặt trên Oracle server:
rpm -ivh VeeamPluginforOracleRMAN-12.x.rpm

# RMAN script (cấu hình trong Oracle):
RMAN> CONFIGURE CHANNEL DEVICE TYPE SBT
  PARMS 'SBT_LIBRARY=/opt/veeam/VeeamPluginforOracleRMAN/libOracleRMANPlugin.so';

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
# → Backup đi vào Veeam Repository (Oracle-consistent)

# Ưu điểm:
# ├─ Application-consistent (không cần VSS)
# ├─ Granular restore: tablespace, datafile, SCN point-in-time
# └─ Hỗ trợ RAC multi-node

Kết Quả: 0 data loss trong 3 production incidents trong 2 năm

3 incidents: power failure (HCM), network cut (HN), storage controller failure — tất cả đều failover thành công trong < 12 phút, không mất transaction nào.

Case Study 3: Nhà Máy Sản Xuất (OT/SCADA Air-Gapped)

Bối Cảnh

Thông tin tổ chức:
├─ Dây chuyền tự động hóa 24/7 (PLC, SCADA, DCS)
├─ Windows XP SP3 + Windows 7 legacy SCADA servers
│   (không thể patch — vendor không hỗ trợ phiên bản mới)
├─ Production downtime = $50,000/giờ
├─ Shift changeover: mỗi 8 giờ (backup window nhỏ)
│
Constraints:
├─ Air-gapped OT network (HOÀN TOÀN không có internet)
├─ No VMware/Hyper-V (physical servers)
├─ Legacy OS: Windows XP SP3, Windows 7 SP1
└─ Vendor restriction: không cài phần mềm thứ 3 lên SCADA controller

Giải Pháp: Veeam Agent (Air-Gapped)

Lý do không dùng agentless:
  → Agentless = Veeam cần access vCenter/Hyper-V API
  → OT network không có hypervisor
  → Physical servers → BẮT BUỘC dùng Veeam Agent for Windows

Kiến trúc Air-Gapped Backup:
┌─────────────────────────────────────────────────────┐
│  OT NETWORK (air-gapped)                            │
│                                                     │
│  SCADA-01 (WinXP)  ──→  Veeam Agent for Windows    │
│  SCADA-02 (Win7)   ──→  (cài trực tiếp trên server) │
│  HMI-01 (Win10)    ──→                              │
│                          ↓                          │
│                   USB-HDD (encrypted)               │
│                    (mang tay ra ngoài)               │
└─────────────────────────────────────────────────────┘
         ↓ Physical transport (2x/tuần)
┌─────────────────────────────────────────────────────┐
│  IT NETWORK (có internet)                           │
│  Veeam Backup Server → import USB → Repository      │
│  Retention: 4 restore points (weekly)               │
└─────────────────────────────────────────────────────┘

Legacy OS Support:
  Veeam Agent for Windows hỗ trợ: Windows XP SP3+ ✓
  (Veeam B&R agentless: yêu cầu Win Server 2008+)

Backup Schedule:
  → Trigger: shift changeover (8:00, 16:00, 00:00)
  → Window: 30 phút (change rate thấp → incremental nhỏ)
  → USB rotation: 4 USB drives (weekly rotation)
  → Offsite vault: 1 bản/tuần → secured storage

Kết Quả: 3 Ransomware Attacks Thất Bại trong 18 Tháng

Attack #1 (Tháng 3): Ransomware từ USB bị nhiễm → SCADA-02 bị mã hóa → Restore từ backup 4 giờ trước → Downtime: 45 phút
Attack #2 (Tháng 8): Contractor laptop kết nối HMI → Spread qua SMB → 3 servers bị mã hóa → Restore cả 3 → Downtime: 2 giờ
Attack #3 (Tháng 14): Phishing email (IT network) cố gắng pivot sang OT → Air-gap ngăn chặn hoàn toàn → Downtime: 0

Bài Học: Legacy Systems Cần Backup Strategy Riêng

  • 1. Không thể patch ≠ không thể backup: Veeam Agent hỗ trợ Windows XP SP3+
  • 2. Air-gap là lớp bảo vệ mạnh nhất: Attack #3 bị chặn hoàn toàn bởi network isolation
  • 3. USB rotation phải có quy trình nghiêm ngặt: Mỗi USB có serial number, checklist ký nhận
  • 4. Test restore định kỳ: Backup không test = backup giả → mỗi tháng restore 1 server vào lab
  • 5. Vendor lock-in: Một số SCADA vendor tính phí "re-licensing" nếu restore vào hardware khác → kiểm tra hợp đồng trước

Bài Tập Thực Hành

BT1: Viết DR Runbook cho Bệnh Viện

Dựa theo Case Study 1, viết DR runbook chi tiết cho kịch bản: HIS Oracle server bị ransomware lúc 3:00 AM.

  • Tối thiểu 10 bước thực hiện (từ phát hiện đến phục hồi)
  • Chỉ định người phụ trách từng bước (DBA, SysAdmin, Manager)
  • Xác định mục tiêu RTO/RPO và cách verify
  • Bao gồm communication plan (ai gọi cho ai)

BT2: Tính TCO cho Ngân Hàng 200 Chi Nhánh

Dựa theo Case Study 2, tính Total Cost of Ownership cho giải pháp backup/DR hoàn chỉnh trong 3 năm:

  • Veeam license: CDP + Universal License cho 100 VMs + Oracle plugin
  • Storage: SSD repo (CDP target), NAS (primary), Tape library (archive)
  • Network: bandwidth HCM ↔ HN replication
  • Labor: 2 FTE backup admin × 3 năm
  • So sánh với chi phí downtime nếu không có DR (tham khảo $50k/hour)

BT3: OT/SCADA Backup Design — Air-Gapped Environment

Thiết kế backup solution cho nhà máy có: 15 SCADA servers (Windows 7), 5 HMI (Windows 10), 2 Engineering Workstations, backup window mỗi 8 tiếng (shift change), budget $20,000:

  • Phương án backup (Veeam Agent configuration)
  • USB rotation scheme (số lượng USB, rotation schedule)
  • Recovery testing procedure (không làm gián đoạn sản xuất)
  • Bill of materials: Veeam license, storage hardware

Checklist Hoàn Thành Tuần 15