Khôi Phục RDS Từ Snapshot: Instance Mới Hay Ghi Đè Instance Cũ?

Một trong những câu hỏi xuất hiện thường xuyên nhất khi vận hành RDS trong môi trường production là: khi khôi phục từ snapshot, hệ thống có ghi đè lên instance hiện tại không, hay sẽ tạo ra một instance hoàn toàn mới với endpoint khác? Câu trả lời ảnh hưởng trực tiếp đến chiến lược disaster recovery, downtime window, và cách bạn cập nhật connection string trong ứng dụng.

TL;DR — Khôi Phục RDS Từ Snapshot

Câu hỏiCâu trả lời
Có ghi đè instance cũ không?Không. AWS luôn tạo instance mới.
Endpoint có thay đổi không?Có. Instance mới có endpoint khác hoàn toàn.
Instance cũ còn tồn tại không?Có, vẫn chạy bình thường cho đến khi bạn xóa thủ công.
Security Group, Parameter Group có được kế thừa không?Không tự động. Phải cấu hình lại sau khi restore.
Multi-AZ và Read Replica có được khôi phục không?Không. Phải bật lại thủ công sau restore.

Cơ Chế Hoạt Động Của RDS Snapshot Restore

RDS snapshot là một bản sao lưu toàn bộ storage volume của instance tại một thời điểm cụ thể, được lưu trên Amazon S3 (quản lý nội bộ bởi AWS, không hiển thị trong S3 console của bạn). Khi bạn thực hiện restore, AWS không có cơ chế 'in-place restore' — tức là không có tùy chọn nào để ghi đè dữ liệu lên instance đang chạy. Thay vào đó, quá trình restore luôn khởi tạo một DB instance mới từ đầu.

Lý do thiết kế này hợp lý: instance đang chạy có thể đang phục vụ traffic thực. Nếu restore ghi đè trực tiếp, bạn sẽ mất toàn bộ dữ liệu phát sinh sau thời điểm snapshot mà không có cơ hội kiểm tra trước. Mô hình 'tạo mới' cho phép bạn xác minh dữ liệu trên instance được restore trước khi quyết định chuyển hướng traffic.

graph LR SNAP["DB Snapshot
Thời điểm T"] RESTORE["Restore Process
AWS cấp phát compute mới"] NEW["Instance Mới
Endpoint: new-db.xxx.rds.amazonaws.com"] OLD["Instance Gốc
Vẫn chạy bình thường"] APP["Application
Cần cập nhật connection string"] SNAP --> RESTORE RESTORE --> NEW OLD -->|Không bị ảnh hưởng| OLD NEW -->|Endpoint mới| APP OLD -->|Endpoint cũ - không thay đổi| APP
  1. Snapshot: Bản sao storage volume tại thời điểm T, lưu trên S3 nội bộ của AWS.
  2. Restore Process: AWS cấp phát compute mới, gắn storage được khôi phục từ snapshot.
  3. New Instance: Instance mới có endpoint riêng, hoàn toàn độc lập với instance gốc.
  4. Original Instance: Vẫn tiếp tục chạy, không bị ảnh hưởng bởi quá trình restore.
  5. Application: Phải cập nhật connection string thủ công để trỏ đến endpoint mới.

Những Gì Không Được Kế Thừa Khi Restore Từ Snapshot

Đây là điểm mà nhiều engineer bị bất ngờ trong lần đầu thực hiện restore production. Snapshot chỉ lưu dữ liệu storage — không lưu cấu hình runtime của instance. Sau khi restore xong, bạn sẽ thấy instance mới sử dụng default parameter group và default security group của VPC, không phải các giá trị từ instance gốc.

Cụ thể, các thành phần sau không được tự động kế thừa:

  • Security Groups: Instance mới gắn với default security group. Nếu ứng dụng không thể kết nối được ngay sau restore, đây thường là nguyên nhân đầu tiên cần kiểm tra.
  • DB Parameter Group: Sẽ dùng default parameter group của engine version tương ứng.
  • DB Option Group: Tương tự, sẽ dùng default option group.
  • Multi-AZ: Bị tắt sau restore. Phải bật lại thủ công nếu cần.
  • Read Replicas: Không được khôi phục. Phải tạo lại từ đầu.
  • Enhanced Monitoring và Performance Insights: Phải bật lại thủ công.
Hãy nghĩ về snapshot như một ảnh chụp ổ cứng — nó lưu dữ liệu bên trong, không lưu cách ổ cứng đó được cắm vào hệ thống. Khi bạn restore, bạn lấy dữ liệu ra và lắp vào một máy mới, nhưng cấu hình mạng, firewall, và tuning của máy cũ không đi kèm.

Thực Hiện Restore Từ Snapshot Qua AWS CLI

Trước khi restore, xác định snapshot identifier cần dùng. Lệnh dưới đây liệt kê các snapshot thuộc về một instance cụ thể, sắp xếp theo thời gian tạo:

aws rds describe-db-snapshots \
  --db-instance-identifier your-db-instance-id \
  --query 'DBSnapshots[*].{ID:DBSnapshotIdentifier,Time:SnapshotCreateTime,Status:Status}' \
  --output table \
  --region us-east-1

Sau khi xác định được snapshot, thực hiện restore. Lưu ý: --db-instance-identifier ở đây là tên của instance mới sẽ được tạo ra, không phải instance gốc:

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier your-restored-instance-name \
  --db-snapshot-identifier your-snapshot-id \
  --db-instance-class db.t3.medium \
  --db-subnet-group-name your-subnet-group \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --no-multi-az \
  --region us-east-1

Theo dõi trạng thái của instance mới cho đến khi chuyển sang available:

aws rds describe-db-instances \
  --db-instance-identifier your-restored-instance-name \
  --query 'DBInstances[0].{Status:DBInstanceStatus,Endpoint:Endpoint.Address}' \
  --output table \
  --region us-east-1

Sau khi instance ở trạng thái available, lấy endpoint mới để cập nhật ứng dụng:

aws rds describe-db-instances \
  --db-instance-identifier your-restored-instance-name \
  --query 'DBInstances[0].Endpoint.Address' \
  --output text \
  --region us-east-1

IAM Policy Tối Thiểu Để Thực Hiện Restore

Nếu bạn đang chạy restore từ CI/CD pipeline hoặc một role tự động hóa, đây là policy tối thiểu cần thiết. Lưu ý rằng rds:DescribeDBSnapshots và rds:DescribeDBInstances yêu cầu Resource: "*" vì đây là list/describe actions:

🔽 Xem IAM Policy (click để mở rộng) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRDSSnapshotDescribe",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBSnapshots",
        "rds:DescribeDBInstances",
        "rds:DescribeDBSubnetGroups"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowRDSRestore",
      "Effect": "Allow",
      "Action": [
        "rds:RestoreDBInstanceFromDBSnapshot"
      ],
      "Resource": [
        "arn:aws:rds:us-east-1:123456789012:snapshot:*",
        "arn:aws:rds:us-east-1:123456789012:db:*"
      ]
    }
  ]
}

Quy Trình Chuyển Đổi Traffic Sau Khi Restore

Đây là phần mà nhiều team thực sự mất thời gian. Instance mới đã sẵn sàng, nhưng ứng dụng vẫn đang trỏ vào endpoint cũ. Có hai hướng tiếp cận phổ biến:

graph TD RESTORED["Instance Mới Sẵn Sàng
available"] CHOICE{"Cơ chế kết nối
hiện tại là gì?"} DIRECT["Connection string trực tiếp
đến RDS endpoint"] DNS["Custom DNS alias
Route 53 CNAME"] PROXY["RDS Proxy endpoint"] ACTION1["Cập nhật endpoint
trong config/secret"] ACTION2["Cập nhật CNAME record
trỏ sang endpoint mới"] ACTION3["Cập nhật target group
của RDS Proxy"] DONE["Traffic chuyển sang
instance mới"] RESTORED --> CHOICE CHOICE --> DIRECT CHOICE --> DNS CHOICE --> PROXY DIRECT --> ACTION1 DNS --> ACTION2 PROXY --> ACTION3 ACTION1 --> DONE ACTION2 --> DONE ACTION3 --> DONE
  1. Cập nhật connection string trực tiếp: Thay endpoint trong config/secret. Đơn giản nhưng yêu cầu restart ứng dụng hoặc connection pool reload.
  2. Dùng Route 53 CNAME: Nếu ứng dụng kết nối qua một DNS alias tùy chỉnh thay vì endpoint RDS trực tiếp, bạn chỉ cần cập nhật CNAME record trỏ sang endpoint mới. Không cần thay đổi config ứng dụng, nhưng phải tính đến TTL của DNS record.
  3. Dùng RDS Proxy: Nếu đang dùng RDS Proxy, cập nhật target group của Proxy để trỏ sang instance mới. Ứng dụng vẫn kết nối qua endpoint của Proxy, không đổi.

Trường Hợp Thực Tế: Misdiagnosis Khi Restore

Tình huống hay gặp: restore xong, instance mới ở trạng thái available, nhưng ứng dụng báo lỗi kết nối. Team đầu tiên nghi ngờ dữ liệu bị hỏng trong snapshot, hoặc engine version không tương thích.

Thực tế, nguyên nhân gần như luôn là security group. Instance mới đang dùng default security group của VPC, không có inbound rule cho port 3306 (MySQL) hay 5432 (PostgreSQL) từ security group của ứng dụng. Snapshot không lưu thông tin security group, và lệnh restore chỉ áp dụng security group nếu bạn truyền tham số --vpc-security-group-ids một cách tường minh.

Kiểm tra nhanh bằng CLI:

aws rds describe-db-instances \
  --db-instance-identifier your-restored-instance-name \
  --query 'DBInstances[0].VpcSecurityGroups' \
  --output table \
  --region us-east-1

Nếu output chỉ hiển thị default security group thay vì security group của ứng dụng, đó là vấn đề. Sửa bằng cách modify instance:

aws rds modify-db-instance \
  --db-instance-identifier your-restored-instance-name \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --apply-immediately \
  --region us-east-1

Security group không phải cấu hình được lưu trong snapshot — đây là behavioral side effect của thiết kế restore, không phải bug. Nhưng nếu không biết trước, bạn sẽ mất 20-30 phút đi sai hướng.

Restore Từ Snapshot Cho RDS — Wrap-Up và Bước Tiếp Theo

Điểm cốt lõi cần nhớ: khôi phục RDS từ snapshot luôn tạo ra một DB instance mới với endpoint mới. Instance gốc không bị ảnh hưởng. Đây là thiết kế có chủ đích, cho phép bạn kiểm tra dữ liệu được restore trước khi chuyển hướng traffic production.

Checklist trước khi chuyển traffic sang instance được restore:

  • Xác nhận security group đúng đã được gắn vào instance mới
  • Kiểm tra parameter group và option group nếu instance gốc dùng custom group
  • Bật lại Multi-AZ nếu cần thiết cho production
  • Cập nhật connection string hoặc DNS alias
  • Tạo lại Read Replicas nếu cần
  • Bật lại Enhanced Monitoring và Performance Insights
  • Xóa instance gốc sau khi đã xác nhận instance mới hoạt động ổn định (để tránh phát sinh chi phí)

Tham khảo thêm tài liệu chính thức: Restoring from a DB snapshot — AWS Documentation.

Glossary — Thuật Ngữ Chính

Thuật ngữGiải thích
DB SnapshotBản sao lưu toàn bộ storage volume của RDS instance tại một thời điểm cụ thể, do người dùng hoặc AWS tạo ra.
DB Instance IdentifierTên định danh duy nhất của một RDS instance trong một AWS region và account.
DB EndpointDNS hostname được AWS cấp phát cho RDS instance, dùng để kết nối từ ứng dụng.
Parameter GroupTập hợp các tham số cấu hình engine database (MySQL, PostgreSQL...) áp dụng cho RDS instance.
RDS ProxyProxy layer được quản lý bởi AWS, đứng trước RDS instance, giúp quản lý connection pooling và che giấu endpoint thực của instance.

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

EC2 Không Có Internet Trong Custom VPC: Cách Gắn Internet Gateway và Cập Nhật Route Table

Bạn tạo một custom VPC, launch EC2 instance vào public subnet, SSH vào được — nhưng ping google.com trả về timeout hoàn toàn. Đây là một trong những lỗi phổ biến nhất khi làm việc với EC2 không có internet trong custom VPC, và nguyên nhân gần như luôn nằm ở một trong ba lớp: thiếu Internet Gateway, route table chưa có default route, hoặc Security Group/NACL chặn traffic ra ngoài. TL;DR — EC2 Không Có Internet Trong Custom VPC Lớp kiểm tra Triệu chứng Fix Internet Gateway Không có IGW hoặc IGW chưa attach vào VPC Tạo IGW, attach vào VPC Route Table Không có route 0.0.0.0/0 → igw-xxx Thêm default route trỏ vào IGW Subnet Association Subnet dùng main route table không có IGW route Associate subnet với route table đúng Public IP EC2 không có public IP hoặc Elastic IP Enable auto-assign public IP hoặc gắn EIP Security Group Outbound rule bị xóa hoặc quá hạn chế Thêm outbound rule cho port 80/443 hoặc all...
Đọc thêm

RDS Multi-AZ: Lợi Ích Thực Sự Là Gì và Khi Nào Nên Bật?

Một trong những câu hỏi hay gặp nhất khi thiết kế hệ thống trên AWS là: bật Multi-AZ cho RDS có giúp tăng hiệu năng đọc không, hay nó chỉ phục vụ mục đích failover? Câu trả lời ngắn gọn là: Multi-AZ không cải thiện hiệu năng đọc — nhưng nếu bạn đang vận hành hệ thống production mà thiếu nó, bạn đang chấp nhận một rủi ro downtime không cần thiết. TL;DR — RDS Multi-AZ là gì và có lợi ích gì? Multi-AZ là cơ chế high availability của RDS, không phải cơ chế scale-out. Bảng dưới tóm tắt những điểm quan trọng nhất: Khía cạnh Multi-AZ Read Replica Mục đích chính High availability, failover tự động Scale-out đọc, giảm tải primary Standby có nhận traffic đọc không? Không (với Multi-AZ DB Instance) Có Replication Synchronous Asynchronous Failover tự động Có Không (thủ công) RTO mục tiêu Thường dưới 2 phút (tùy engine) Không áp dụng Ảnh hưởng hiệu năng ghi Có thể tăng nhẹ latency do sync replication Không...
Đọc thêm

Lỗi CORS trên API Gateway: Cách bật CORS và Lambda phải trả về header gì

Frontend gọi API Gateway và nhận ngay lỗi 'Access-Control-Allow-Origin' — đây là một trong những lỗi phổ biến nhất khi tích hợp React/Vue với backend AWS, và cũng là lỗi dễ chẩn đoán sai nhất. Vấn đề không chỉ nằm ở việc bật CORS trong console, mà còn ở chỗ Lambda của bạn có thực sự trả về đúng headers trong response hay không. TL;DR — Tóm tắt nhanh Vấn đề Nguyên nhân Fix CORS error trên preflight OPTIONS API Gateway chưa có method OPTIONS hoặc chưa enable CORS Enable CORS trong console hoặc thêm OPTIONS method thủ công CORS error trên request thực (GET/POST) Lambda response thiếu header Access-Control-Allow-Origin Thêm header vào Lambda response body CORS error khi Lambda trả về lỗi (4xx/5xx) Lambda Proxy Integration không tự inject CORS headers vào error response Lambda phải tự trả về CORS headers ngay cả khi có lỗi CORS hoạt động như thế nào với API Gateway Trước khi đi vào fix, cần hiểu đún...
Đọc thêm