Tweet
DISASTER RECOVERY & MIGRATIONS TRÊN AWS – HIỂU ĐÚNG ĐỂ KHÔNG MẤT DỮ LIỆU
🌐 DISASTER RECOVERY & MIGRATIONS TRÊN AWS – HIỂU ĐÚNG ĐỂ KHÔNG MẤT DỮ LIỆU
Trong môi trường CNTT hiện đại, bất kỳ sự cố nào làm gián đoạn hoạt động kinh doanh hoặc gây thiệt hại tài chính đều được xem là thảm họa.
Disaster Recovery (DR) không phải là xử lý khi sự cố xảy ra, mà là chuẩn bị trước để phục hồi nhanh nhất khi thảm họa xuất hiện.
AWS cung cấp rất nhiều chiến lược và dịch vụ giúp doanh nghiệp xây dựng hệ thống phục hồi thảm họa và di chuyển hệ thống (migration) một cách linh hoạt, tiết kiệm và an toàn.
1️⃣ Các mô hình Disaster Recovery phổ biến
Tùy vào quy mô và ngân sách, doanh nghiệp có thể lựa chọn nhiều hướng DR khác nhau:
Để thiết kế DR đúng, bắt buộc phải hiểu RPO và RTO.
2️⃣ RPO và RTO – Hai chỉ số sống còn
RPO (Recovery Point Objective)
→ Cho biết doanh nghiệp có thể chấp nhận mất bao nhiêu dữ liệu.
Ví dụ: RPO = 1 giờ nghĩa là khi xảy ra sự cố, dữ liệu mất tối đa 1 giờ trước đó.
RTO (Recovery Time Objective)
→ Cho biết hệ thống được phép ngừng hoạt động bao lâu.
Ví dụ: RTO = 30 phút nghĩa là hệ thống phải hoạt động trở lại trong vòng 30 phút.
👉 RPO càng thấp, RTO càng nhanh thì chi phí càng cao.
3️⃣ Các chiến lược Disaster Recovery trên AWS
🔹 Backup & Restore – Đơn giản nhất, chi phí thấp nhất
Thường dùng cho hệ thống không yêu cầu khôi phục nhanh.
🔹 Pilot Light – Luôn duy trì phần cốt lõi
Nhanh hơn Backup & Restore nhưng vẫn tiết kiệm chi phí.
🔹 Warm Standby – Sẵn sàng ở mức tối thiểu
Cân bằng tốt giữa chi phí và thời gian phục hồi.
🔹 Multi-Site / Hot Site – Phục hồi trong vài phút hoặc vài giây
Phù hợp với ngân hàng, thương mại điện tử lớn, hệ thống critical.
4️⃣ Disaster Recovery trên nhiều AWS Region
AWS cho phép triển khai active-active giữa nhiều Region, kết hợp:
👉 Đây là kiến trúc DR cao cấp nhất trên AWS.
5️⃣ Các best practice Disaster Recovery trên AWS
Backup
High Availability
Replication
Automation
6️⃣ AWS DMS – Database Migration Service
AWS DMS giúp di chuyển database nhanh, an toàn và không downtime.
Đặc điểm chính:
Nguồn dữ liệu có thể là:
Đích đến có thể là:
7️⃣ AWS SCT – Schema Conversion Tool
AWS SCT dùng để chuyển đổi schema database khi đổi engine.
Ví dụ:
Không cần SCT nếu:
👉 SCT thường kết hợp cùng DMS để migrate trọn vẹn.
8️⃣ Migration RDS & Aurora
AWS hỗ trợ nhiều cách migrate:
Chọn cách nào phụ thuộc vào:
9️⃣ Chiến lược On-Premise với AWS
AWS hỗ trợ:
Ngoài ra còn có VMware Cloud on AWS cho doanh nghiệp muốn giữ nguyên VMware stack.
🔟 Di chuyển dữ liệu lớn vào AWS
Ví dụ chuyển 200TB:
👉 Snowball thường kết hợp với DMS hoặc DataSync.
Trong môi trường CNTT hiện đại, bất kỳ sự cố nào làm gián đoạn hoạt động kinh doanh hoặc gây thiệt hại tài chính đều được xem là thảm họa.
Disaster Recovery (DR) không phải là xử lý khi sự cố xảy ra, mà là chuẩn bị trước để phục hồi nhanh nhất khi thảm họa xuất hiện.
AWS cung cấp rất nhiều chiến lược và dịch vụ giúp doanh nghiệp xây dựng hệ thống phục hồi thảm họa và di chuyển hệ thống (migration) một cách linh hoạt, tiết kiệm và an toàn.
1️⃣ Các mô hình Disaster Recovery phổ biến
Tùy vào quy mô và ngân sách, doanh nghiệp có thể lựa chọn nhiều hướng DR khác nhau:
- On-Premise sang On-Premise: mô hình truyền thống, chi phí rất cao
- On-Premise sang AWS Cloud: mô hình hybrid, linh hoạt và tiết kiệm
- AWS Region A sang AWS Region B: mô hình cloud-native, độ sẵn sàng cao
Để thiết kế DR đúng, bắt buộc phải hiểu RPO và RTO.
2️⃣ RPO và RTO – Hai chỉ số sống còn
RPO (Recovery Point Objective)
→ Cho biết doanh nghiệp có thể chấp nhận mất bao nhiêu dữ liệu.
Ví dụ: RPO = 1 giờ nghĩa là khi xảy ra sự cố, dữ liệu mất tối đa 1 giờ trước đó.
RTO (Recovery Time Objective)
→ Cho biết hệ thống được phép ngừng hoạt động bao lâu.
Ví dụ: RTO = 30 phút nghĩa là hệ thống phải hoạt động trở lại trong vòng 30 phút.
👉 RPO càng thấp, RTO càng nhanh thì chi phí càng cao.
3️⃣ Các chiến lược Disaster Recovery trên AWS
🔹 Backup & Restore – Đơn giản nhất, chi phí thấp nhất
- Sao lưu dữ liệu bằng snapshot, AMI, backup database
- Khi xảy ra sự cố mới khôi phục lại
- RPO cao, RTO chậm
Thường dùng cho hệ thống không yêu cầu khôi phục nhanh.
🔹 Pilot Light – Luôn duy trì phần cốt lõi
- Chỉ chạy những thành phần quan trọng nhất trên AWS
- Dữ liệu được đồng bộ thường xuyên
- Khi có sự cố, bật thêm tài nguyên để chạy full hệ thống
Nhanh hơn Backup & Restore nhưng vẫn tiết kiệm chi phí.
🔹 Warm Standby – Sẵn sàng ở mức tối thiểu
- Toàn bộ hệ thống đã chạy trên AWS
- Nhưng chỉ ở cấu hình nhỏ
- Khi sự cố xảy ra, scale lên ngay
Cân bằng tốt giữa chi phí và thời gian phục hồi.
🔹 Multi-Site / Hot Site – Phục hồi trong vài phút hoặc vài giây
- Hệ thống chạy song song ở nhiều site
- Có thể là On-Premise + AWS hoặc Multi-Region AWS
- RTO cực thấp, chi phí rất cao
Phù hợp với ngân hàng, thương mại điện tử lớn, hệ thống critical.
4️⃣ Disaster Recovery trên nhiều AWS Region
AWS cho phép triển khai active-active giữa nhiều Region, kết hợp:
- Route 53 điều hướng traffic
- ELB và Auto Scaling
- Aurora Global Database để đồng bộ dữ liệu
👉 Đây là kiến trúc DR cao cấp nhất trên AWS.
5️⃣ Các best practice Disaster Recovery trên AWS
Backup
- Snapshot EBS, RDS automated backup
- Đẩy dữ liệu lên S3, S3 IA, Glacier
- Dùng lifecycle policy và cross-region replication
- On-Premise có thể dùng Snowball hoặc Storage Gateway
High Availability
- Route 53 để chuyển hướng DNS giữa các Region
- RDS Multi-AZ, ElastiCache Multi-AZ, EFS, S3
- VPN Site-to-Site dự phòng cho Direct Connect
Replication
- RDS cross-region replication
- Aurora Global Database
- Replicate DB từ on-premise lên RDS
Automation
- Dùng CloudFormation hoặc Elastic Beanstalk để dựng lại môi trường
- CloudWatch + Lambda để tự động phục hồi EC2
- Chaos engineering (Netflix Simian Army) để kiểm tra khả năng chịu lỗi
6️⃣ AWS DMS – Database Migration Service
AWS DMS giúp di chuyển database nhanh, an toàn và không downtime.
Đặc điểm chính:
- Database nguồn vẫn hoạt động trong quá trình migrate
- Hỗ trợ migrate cùng engine hoặc khác engine
- Hỗ trợ CDC – Continuous Data Capture
- Cần tạo một EC2 làm replication instance
Nguồn dữ liệu có thể là:
- On-Premise
- EC2
- Amazon RDS
- Amazon S3
- Azure SQL
Đích đến có thể là:
- RDS, Aurora
- Redshift
- DynamoDB
- S3, OpenSearch, Kinesis, DocumentDB
7️⃣ AWS SCT – Schema Conversion Tool
AWS SCT dùng để chuyển đổi schema database khi đổi engine.
Ví dụ:
- Oracle / SQL Server → Aurora, PostgreSQL
- Teradata → Amazon Redshift
Không cần SCT nếu:
- Chỉ chuyển từ On-Premise PostgreSQL sang RDS PostgreSQL
👉 SCT thường kết hợp cùng DMS để migrate trọn vẹn.
8️⃣ Migration RDS & Aurora
AWS hỗ trợ nhiều cách migrate:
- Restore snapshot
- Aurora Read Replica rồi promote
- Import dữ liệu từ S3
- Dùng mysqldump
- Dùng DMS khi cả hai DB đang chạy
Chọn cách nào phụ thuộc vào:
- Downtime cho phép
- Dung lượng dữ liệu
- Chi phí
9️⃣ Chiến lược On-Premise với AWS
AWS hỗ trợ:
- Import / Export VM
- Application Discovery Service để phân tích hệ thống
- Migration Hub theo dõi tiến trình
- Server Migration Service
- Application Migration Service (MGN) cho lift-and-shift
Ngoài ra còn có VMware Cloud on AWS cho doanh nghiệp muốn giữ nguyên VMware stack.
🔟 Di chuyển dữ liệu lớn vào AWS
Ví dụ chuyển 200TB:
- Internet 100 Mbps: ~185 ngày
- Direct Connect 1Gbps: ~18.5 ngày
- Snowball: ~1 tuần (nhanh nhất)
👉 Snowball thường kết hợp với DMS hoặc DataSync.