Kết Quả Học Tập
- Thực hiện DR drill hoàn chỉnh trong môi trường enterprise (prod-like)
- Phân tích 3 case study ngành: Healthcare, Finance, Manufacturing
- Thực hiện failback từ DR site về production site
- Đánh giá RPO/RTO thực tế vs mục tiêu đề ra
- Hiểu compliance yêu cầu của HIPAA, PCI-DSS, Thông tư 09 NHNN
- Thiết kế backup strategy cho OT/SCADA air-gapped environment
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út | VƯỢT MỤC TIÊU |
| RTO (total recovery) | 4 giờ | 2.5 giờ | VƯỢT MỤC TIÊU |
| DB tier recovery | 30 phút | 28 phút | ĐẠT |
| App tier recovery | 2 giờ | 55 phút | VƯỢT MỤC TIÊU |
| Services recovered | 100% | 100% | ĐẠT |
| Zero data corruption | Bắ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
| 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 audit | Không đạt | Đạt (AES-256, immutable) |
| PACS retention | 3 năm (disk đầy) | 7 năm (tape archive) |
| Backup success rate | 67% (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
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