Disaster Recovery & Migrations

1. Disaster Recovery là gì?

Bất kỳ sự kiện nào gây ảnh hưởng xấu tới business continuity (tính liên tục của hoạt động kinh doanh) hoặc tới tài chính của công ty đều được coi là một disaster (thảm họa). Disaster Recovery (DR) là việc chuẩn bị trước cho thảm họa đó và khôi phục lại hệ thống sau khi nó xảy ra. Nói cách khác, DR không phải là một dịch vụ bạn bấm bật lên, mà là một kế hoạch kiến trúc — bạn quyết định trước sẽ mất bao nhiêu dữ liệu và chịu dừng hệ thống bao lâu, rồi chọn công nghệ tương ứng với mức đó.

Có ba dạng DR mà bạn cần phân biệt, vì chi phí và độ phức tạp rất khác nhau:

On-premise ⇒ On-premise: DR truyền thống — bạn phải xây và duy trì hai trung tâm dữ liệu, rất đắt.
On-premise ⇒ AWS Cloud: DR kiểu hybrid — trung tâm dữ liệu của bạn là chính, AWS là nơi khôi phục.
AWS Cloud Region A ⇒ AWS Cloud Region B: hoàn toàn trên AWS, dùng region thứ hai làm nơi khôi phục.

RPO và RTO

Để bàn về DR một cách có định lượng, cần đúng hai khái niệm sau:

RPO – Recovery Point Objective (điểm khôi phục mục tiêu): khoảng thời gian tính ngược về trước từ lúc thảm họa xảy ra tới bản dữ liệu tốt cuối cùng. Khoảng này chính là lượng data loss (mất dữ liệu) mà bạn chấp nhận.
RTO – Recovery Time Objective (thời gian khôi phục mục tiêu): khoảng thời gian tính từ lúc thảm họa tới lúc hệ thống chạy lại được. Khoảng này chính là downtime (thời gian ngừng hoạt động) bạn chấp nhận.

Hình dung trên một trục thời gian: RPO nằm trước thời điểm thảm họa (tương ứng vùng dữ liệu bị mất), còn RTO nằm sau thời điểm thảm họa (tương ứng vùng hệ thống bị dừng). Hai con số này càng nhỏ thì hệ thống càng đắt — vì vậy việc chọn chiến lược DR thực chất là chọn điểm cân bằng giữa RPO/RTO và chi phí.

2. Bốn chiến lược Disaster Recovery

Slide liệt kê bốn chiến lược, xếp theo thứ tự RTO nhanh dần (và chi phí tăng dần):

Backup and Restore
Pilot Light
Warm Standby
Hot Site / Multi Site Approach

Backup and Restore

Đây là chiến lược có RPO cao nhất (mất nhiều dữ liệu nhất) và cũng rẻ nhất: bạn chỉ sao lưu dữ liệu định kỳ, không giữ hệ thống nào chạy sẵn ở phía khôi phục. Khi thảm họa xảy ra, bạn dựng lại hạ tầng từ các bản sao lưu đó.

Từ corporate data center (trung tâm dữ liệu của công ty), dữ liệu được đẩy lên AWS qua AWS Storage Gateway hoặc AWS Snowball, hạ cánh vào Amazon S3 rồi theo lifecycle chuyển dần sang Glacier cho lưu trữ lâu dài và rẻ. Song song, ở phía AWS bạn có scheduled regular snapshots (snapshot định kỳ theo lịch) cho EBS, RDS và Redshift, cùng với AMI để dựng lại Amazon EC2 và Amazon RDS khi cần.

Pilot Light

Với Pilot Light, một phiên bản nhỏ của ứng dụng luôn chạy trên cloud — chỉ đúng phần critical core (phần lõi quan trọng nhất), giống như ngọn lửa mồi luôn cháy nhỏ trong một lò đốt. Chiến lược này rất giống Backup and Restore, nhưng nhanh hơn vì các hệ thống quan trọng đã sẵn sàng.

Theo diagram: từ corporate data center, dữ liệu được Data Replication liên tục sang RDS đang chạy (running) trên AWS, trong khi các EC2 chưa chạy (not running). Route 53 đứng trước để chuyển hướng traffic sang phía AWS khi cần. Lúc có thảm họa, bạn chỉ cần bật EC2 lên, vì database đã có dữ liệu mới.

Warm Standby

Với Warm Standby, toàn bộ hệ thống đã chạy sẵn nhưng ở kích thước tối thiểu (minimum size). Khi thảm họa xảy ra, bạn chỉ cần scale lên mức tải production.

Diagram cho thấy: phía on-premise có Reverse proxy → App Server → Primary DB; phía AWS có Route 53 → ELB → EC2 Auto Scaling ở mức minimum, và RDS Secondary (running) nhận Data Replication từ Primary DB, sẵn sàng failover.

Multi Site / Hot Site Approach

Đây là chiến lược có RTO rất thấp (vài phút hoặc vài giây) nhưng cũng rất đắt: full production scale chạy đồng thời cả trên AWS và on-premise. Kiến trúc giống Warm Standby nhưng EC2 Auto Scaling chạy ở mức production, và hai phía hoạt động theo kiểu active-active — Route 53 phân phối traffic cho cả hai, dữ liệu vẫn replicate và có failover sang RDS secondary.

All AWS Multi Region

Biến thể hoàn toàn trên AWS của Hot Site: hai region đều có ELB + EC2 Auto Scaling ở mức production, Route 53 định tuyến active-active giữa hai region và failover khi một region chết. Tầng dữ liệu dùng Aurora Global với một cụm primary và một cụm secondary ở region còn lại, nối bằng Data Replication.

Chiến lược	Hệ thống ở phía khôi phục	RPO / RTO	Chi phí
Backup and Restore	Không có gì chạy, chỉ có backup	RPO cao nhất	Thấp nhất
Pilot Light	Chỉ phần lõi (RDS chạy, EC2 tắt)	Nhanh hơn Backup and Restore	Thấp
Warm Standby	Toàn hệ thống chạy ở mức minimum	Nhanh — chỉ cần scale lên	Trung bình
Hot Site / Multi Site	Full production scale, active-active	RTO vài phút hoặc vài giây	Rất đắt

3. Mẹo thực hành Disaster Recovery

Slide tổng hợp các nhóm kỹ thuật cụ thể mà bạn ghép lại thành một kế hoạch DR. Đây là chỗ các dịch vụ đã học ở những chương trước được dùng lại đúng mục đích DR.

Backup:

EBS Snapshots, RDS automated backups / Snapshots…
Đẩy dữ liệu định kỳ sang S3 / S3 IA / Glacier, dùng Lifecycle Policy và Cross Region Replication.
Từ on-premise: dùng Snowball hoặc Storage Gateway.

High Availability:

Dùng Route 53 để chuyển DNS từ region này sang region khác.
RDS Multi-AZ, ElastiCache Multi-AZ, EFS, S3.
Site to Site VPN làm phương án khôi phục khi Direct Connect gặp sự cố.

Replication:

RDS Replication (Cross Region), AWS Aurora + Global Databases.
Replicate database từ on-premise vào RDS.
Storage Gateway.

Automation:

CloudFormation / Elastic Beanstalk để dựng lại toàn bộ một môi trường mới.
Dùng CloudWatch để recover / reboot EC2 instance khi alarm báo lỗi.
AWS Lambda cho các tự động hóa tùy biến.

Chaos:

Netflix có bộ công cụ “simian-army” chủ động terminate EC2 một cách ngẫu nhiên — tức là liên tục tự gây sự cố để chứng minh hệ thống chịu được sự cố.

4. DMS – Database Migration Service

AWS DMS (Database Migration Service) giúp bạn di chuyển database lên AWS nhanh và an toàn, với hạ tầng resilient và self healing (tự phục hồi khi gặp lỗi). Điểm quan trọng nhất về mặt vận hành: database nguồn vẫn hoạt động bình thường trong suốt quá trình migration — bạn không phải tắt hệ thống để chuyển dữ liệu.

DMS hỗ trợ hai kiểu migration:

Homogeneous migrations (cùng engine): ví dụ Oracle sang Oracle.
Heterogeneous migrations (khác engine): ví dụ Microsoft SQL Server sang Aurora.

Ngoài lần tải dữ liệu đầu tiên, DMS hỗ trợ Continuous Data Replication bằng CDC (Change Data Capture) — tiếp tục bắt và áp dụng các thay đổi phát sinh ở nguồn. Một chi tiết hay bị hỏi: bạn phải tạo một EC2 instance để chạy các replication task — DMS chạy trên một replication instance, không phải hoàn toàn serverless.

Nguồn và đích được hỗ trợ

Sources	Targets
Database trên on-premise và EC2 instance: Oracle, MS SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, SAP, DB2	Database trên on-premise và EC2 instance: Oracle, MS SQL Server, MySQL, MariaDB, PostgreSQL, SAP
Azure: Azure SQL Database	Amazon RDS
Amazon RDS: tất cả, bao gồm Aurora	Redshift, DynamoDB, S3
Amazon S3	OpenSearch Service
DocumentDB	Kinesis Data Streams, Apache Kafka
	DocumentDB & Amazon Neptune
	Redis & Babelfish

Nhìn bảng này, điểm cần nhớ là danh sách target rộng hơn nhiều so với source — DMS không chỉ dùng để “chuyển database sang database”, mà còn để đẩy dữ liệu vào các đích phân tích và streaming như Redshift, S3, Kinesis Data Streams hay Apache Kafka.

AWS Schema Conversion Tool (SCT)

SCT (Schema Conversion Tool) chuyển đổi schema của database từ engine này sang engine khác. Ví dụ:

OLTP: từ SQL Server hoặc Oracle sang MySQL, PostgreSQL, Aurora.
OLAP: từ Teradata hoặc Oracle sang Amazon Redshift.

Nên dùng compute-intensive instance cho SCT để tối ưu quá trình chuyển đổi dữ liệu. Và đây là điểm rất hay bị bẫy: bạn KHÔNG cần SCT nếu migrate cùng một DB engine. Ví dụ On-Premise PostgreSQL ⇒ RDS PostgreSQL — engine vẫn là PostgreSQL, RDS chỉ là nền tảng chạy nó.

Diagram Continuous Replication mô tả một luồng đầy đủ: Oracle DB (source) ở corporate data center; trong VPC có AWS DMS Replication Instance ở Public Subnet và Amazon RDS for MySQL DB (target) ở Private Subnet; một server cài AWS SCT lo phần schema conversion, còn DMS lo phần data migration theo kiểu Full load + CDC.

DMS Multi-AZ Deployment

Khi bật Multi-AZ, DMS tự cấp phát và duy trì một standby replica của replication instance ở một Availability Zone khác, đồng bộ bằng synchronous replication. Lợi ích:

Cung cấp data redundancy (dự phòng dữ liệu).
Loại bỏ I/O freezes.
Giảm thiểu latency spikes (các đợt tăng độ trễ đột ngột).

5. Migration cho RDS & Aurora

Khi đích đến là Aurora, bạn không nhất thiết phải dùng DMS — có những đường ngắn hơn tùy vào nguồn đang ở đâu.

RDS & Aurora MySQL

Từ RDS MySQL sang Aurora MySQL:

Option 1: lấy DB Snapshot từ RDS MySQL rồi restore thành một MySQL Aurora DB.
Option 2: tạo một Aurora Read Replica từ RDS MySQL của bạn, và khi replication lag bằng 0 thì promote nó thành một DB cluster độc lập (cách này có thể mất thời gian và tốn tiền).

Từ MySQL bên ngoài sang Aurora MySQL:

Option 1: dùng Percona XtraBackup tạo một file backup trên Amazon S3, rồi tạo Aurora MySQL DB từ S3 đó.
Option 2: tạo Aurora MySQL DB trước, rồi dùng tiện ích mysqldump để migrate MySQL vào Aurora — chậm hơn cách qua S3.

Nếu cả hai database đều đang chạy, dùng DMS.

RDS & Aurora PostgreSQL

Từ RDS PostgreSQL sang Aurora PostgreSQL: hai option giống bên MySQL — restore từ DB Snapshot, hoặc tạo Aurora Read Replica rồi promote khi replication lag bằng 0 (mất thời gian và tốn tiền).

Từ PostgreSQL bên ngoài sang Aurora PostgreSQL: tạo một bản backup, đưa lên Amazon S3, rồi import bằng extension aws_s3 của Aurora. Nếu cả hai database đều đang chạy thì dùng DMS.

6. Chiến lược chuyển hệ thống on-premise lên AWS

Ngoài database, còn cả máy chủ và máy ảo phải chuyển. Slide gom lại các công cụ theo từng bước của một dự án migration:

Tải Amazon Linux 2 AMI về dưới dạng VM (định dạng .iso) để chạy trên VMWare, KVM, VirtualBox (Oracle VM), Microsoft Hyper-V — hữu ích khi bạn muốn môi trường on-premise giống môi trường AWS.
VM Import / Export:
- Migrate các ứng dụng đang có vào EC2.
- Tạo một chiến lược DR repository cho các VM on-premise của bạn.
- Có thể export ngược VM từ EC2 về on-premise.
AWS Application Discovery Service: thu thập thông tin về các server on-premise để lập kế hoạch migration — server utilization (mức sử dụng máy chủ) và dependency mapping (bản đồ phụ thuộc giữa các hệ thống); theo dõi bằng AWS Migration Hub.
AWS Database Migration Service (DMS): replicate theo cả ba hướng On-premise ⇒ AWS, AWS ⇒ AWS, AWS ⇒ On-premise; làm việc với nhiều công nghệ database (Oracle, MySQL, DynamoDB…).
AWS Server Migration Service (SMS): replication tăng dần (incremental) các server on-premise đang chạy lên AWS.

AWS Application Discovery Service chi tiết

Dịch vụ này giúp lập kế hoạch cho dự án migration bằng cách thu thập thông tin về các trung tâm dữ liệu on-premise — dữ liệu về mức sử dụng máy chủ và bản đồ phụ thuộc là những thứ quan trọng nhất cho một cuộc migration. Có hai chế độ:

Agentless Discovery (AWS Agentless Discovery Connector): lấy VM inventory, cấu hình, và lịch sử hiệu năng như CPU, memory, disk usage.
Agent-based Discovery (AWS Application Discovery Agent): lấy cấu hình hệ thống, hiệu năng hệ thống, các running process, và chi tiết các kết nối mạng giữa các hệ thống.

Dữ liệu thu được xem trong AWS Migration Hub.

AWS Application Migration Service (MGN)

MGN là “bản tiến hóa của AWS” cho CloudEndure Migration, và thay thế AWS Server Migration Service (SMS). Đây là giải pháp lift-and-shift (rehost) giúp đơn giản hóa việc đưa ứng dụng lên AWS:

Chuyển các server physical, virtual và cloud-based sang chạy native trên AWS.
Hỗ trợ nhiều nền tảng, hệ điều hành và database.
Downtime tối thiểu, chi phí giảm.

Cách hoạt động theo diagram: một AWS Replication Agent được cài trên máy nguồn (ở Corporate Data Center hoặc bất kỳ cloud nào), gồm Disks, OS, Apps, DB; agent continuous replication sang môi trường Staging trên AWS chạy bằng low-cost EC2 instance & EBS volume; đến thời điểm cutover, hệ thống được chuyển sang Production với target EC2 instance & EBS volume.

7. AWS Backup

AWS Backup là dịch vụ fully managed dùng để quản lý tập trung và tự động hóa việc backup xuyên nhiều dịch vụ AWS — bạn không cần tự viết script và làm thủ công nữa.

Các dịch vụ được hỗ trợ:

Amazon EC2 / Amazon EBS
Amazon S3
Amazon RDS (tất cả DB engine) / Amazon Aurora / Amazon DynamoDB
Amazon DocumentDB / Amazon Neptune
Amazon EFS / Amazon FSx (Lustre & Windows File Server)
AWS Storage Gateway (Volume Gateway)

AWS Backup hỗ trợ cross-region backups và cross-account backups — hai tính năng rất hợp với yêu cầu DR và với yêu cầu tách tài khoản để chống mất dữ liệu.

Backup Plans

AWS Backup hỗ trợ PITR (Point-In-Time Recovery) cho các dịch vụ có hỗ trợ, cho phép backup on-demand và theo lịch (scheduled), và cho phép tag-based backup policies (chọn tài nguyên để backup theo tag). Bạn tạo các backup policy gọi là Backup Plans, gồm:

Backup frequency: mỗi 12 giờ, hằng ngày, hằng tuần, hằng tháng, hoặc cron expression.
Backup window (khung thời gian chạy backup).
Transition to Cold Storage: Never, Days, Weeks, Months, Years.
Retention Period: Always, Days, Weeks, Months, Years.

Luồng sử dụng rất gọn: Create Backup Plan (frequency, retention policy) → Assign AWS Resources (EC2, EBS, RDS, DynamoDB, EFS, Aurora, FSx, Storage Gateway, DocumentDB, Neptune) → các tài nguyên đó được tự động backup vào Amazon S3.

AWS Backup Vault Lock

Backup Vault Lock áp đặt trạng thái WORM (Write Once Read Many) cho toàn bộ backup nằm trong AWS Backup Vault của bạn. Đây là lớp phòng thủ bổ sung để bảo vệ backup khỏi:

Các thao tác xóa do vô tình hoặc do cố ý phá hoại.
Các thay đổi làm rút ngắn hoặc sửa đổi retention period.

Và điểm mạnh nhất: khi đã bật, kể cả root user cũng không thể xóa backup.

8. VMware Cloud on AWS

Một số khách hàng dùng VMware Cloud để quản lý trung tâm dữ liệu on-premise của họ. Họ muốn mở rộng dung lượng của trung tâm dữ liệu sang AWS nhưng vẫn tiếp tục dùng phần mềm VMware Cloud — và đó chính là lý do VMware Cloud on AWS tồn tại.

Use case:

Migrate các workload dựa trên VMware vSphere sang AWS.
Chạy workload production xuyên các môi trường private, public và hybrid cloud dựa trên VMware vSphere.
Có một chiến lược disaster recovery.

Theo diagram, khách hàng vẫn dùng On-Premises vCenter để quản lý môi trường vSphere-based của mình, đồng thời quản lý cả phần VMware Cloud on AWS nằm trong AWS Cloud; phần này truy cập được các dịch vụ AWS như Amazon EC2, Amazon S3, Direct Connect, Amazon FSx, Amazon RDS, Amazon Redshift.

9. Chuyển khối lượng dữ liệu lớn vào AWS

Slide cuối chương làm một bài toán rất đáng nhớ: cần chuyển 200 TB dữ liệu lên cloud, đường Internet có băng thông 100 Mbps. Cùng một khối dữ liệu, ba phương án cho ra ba mốc thời gian khác nhau hoàn toàn:

Phương án	Thời gian thiết lập	Thời gian truyền 200 TB
Qua Internet / Site-to-Site VPN	Dựng được ngay (immediate)	200 × 1000 × 1000 × 8 / 100 Mbps = 16.000.000 s ≈ 185 ngày
Qua Direct Connect 1 Gbps	Lâu, riêng phần thiết lập một lần đã hơn một tháng	200 × 1000 × 8 / 1 Gbps = 1.600.000 s ≈ 18,5 ngày
Qua Snowball	—	Khoảng 1 tuần cho toàn bộ quá trình end-to-end

Ngoài ra:

Snowball có thể kết hợp với DMS — dùng Snowball để chuyển khối dữ liệu lịch sử khổng lồ, rồi DMS bắt phần thay đổi phát sinh.
Với nhu cầu replication/transfer liên tục: dùng Site-to-Site VPN hoặc DX (Direct Connect) kết hợp DMS hoặc DataSync.

Tóm tắt nhanh

Chủ đề	Cần nhớ
RPO vs RTO	RPO = mất bao nhiêu dữ liệu (nhìn về trước thảm họa) · RTO = ngừng bao lâu (nhìn về sau thảm họa)
Bốn chiến lược DR	Theo RTO nhanh dần: Backup and Restore → Pilot Light → Warm Standby → Hot Site / Multi Site
Nhận diện từng chiến lược	Pilot Light: RDS chạy, EC2 tắt · Warm Standby: cả hệ thống chạy ở mức minimum · Hot Site: full production ở cả hai phía, active-active
All AWS Multi Region	Route 53 active-active cộng Aurora Global (primary/secondary) để làm Hot Site hoàn toàn trong AWS
DMS	Migrate database mà nguồn vẫn chạy, homogeneous và heterogeneous, hỗ trợ CDC, cần một EC2 replication instance; Multi-AZ thêm standby replica đồng bộ
SCT	Chỉ cần khi đổi engine; cùng engine (PostgreSQL ⇒ RDS PostgreSQL) thì không cần SCT
Migrate sang Aurora	DB Snapshot restore hoặc Aurora Read Replica rồi promote khi lag = 0; từ ngoài vào thì qua S3 (Percona XtraBackup cho MySQL, extension `aws_s3` cho PostgreSQL) hoặc `mysqldump` (chậm hơn); cả hai DB đang chạy thì dùng DMS
Application Discovery Service	Khảo sát và dependency mapping, agentless hoặc agent-based; xem kết quả ở Migration Hub
Application Migration Service (MGN)	Lift-and-shift, thay thế SMS; agent replicate liên tục vào staging rồi cutover sang production
AWS Backup	Backup tập trung nhiều dịch vụ, có cross-region và cross-account, Backup Plans với retention và cold storage
Backup Vault Lock	WORM — backup không xóa được, kể cả root user, và retention không rút ngắn được
VMware Cloud on AWS	Giữ nguyên phần mềm VMware vSphere, mở rộng data center sang AWS
200 TB lên cloud	Internet 100 Mbps ≈ 185 ngày · Direct Connect 1 Gbps ≈ 18,5 ngày · Snowball ≈ 1 tuần (ghép được với DMS cho phần thay đổi)