DPTCloud
Quay lại danh sách
Tin tức công nghệ

VPS 'Disaster Recovery as Code': Tự động hóa Backup, Replication và Failover với Terraform, Ansible và Scripts

19 tháng 5, 2026

Giới thiệu: Từ Disaster Recovery Thủ công đến "Như Mã Nguồn"

Trong thế giới điện toán đám mây và máy chủ ảo (VPS), thời gian ngừng hoạt động (downtime) không chỉ là bất tiện mà còn là mối đe dọa trực tiếp đến doanh thu, uy tín và hoạt động kinh doanh. Các sự cố như lỗi phần cứng, tấn công mạng, lỗi cấu hình nghiêm trọng, hoặc thậm chí lỗi của nhà cung cấp dịch vụ, có thể xảy ra bất cứ lúc nào. Chiến lược Disaster Recovery (DR) truyền thống thường phụ thuộc vào các bản sao lưu thủ công, tài liệu hướng dẫn phức tạp và quy trình khôi phục chậm chạp, dễ xảy ra lỗi của con người.

Phương pháp "Disaster Recovery as Code" (DRaC) ra đời để giải quyết những điểm yếu này. Tương tự như Infrastructure as Code (IaC), DRaC định nghĩa toàn bộ quy trình phục hồi sau thảm họa—từ backup, replication đến failover—thông qua các file cấu hình và script có thể đọc, quản lý bằng git, và triển khai tự động. Bài viết này sẽ hướng dẫn bạn xây dựng một hệ thống DRaC cho VPS, sử dụng bộ công cụ mạnh mẽ: Terraform để quản lý tài nguyên, Ansible để cấu hình tự động, và các script tùy chỉnh để điều phối luồng công việc phức tạp.

Kiến trúc Tổng quan cho Hệ thống DRaC

Một hệ thống DR tự động hóa hoàn chỉnh cần đáp ứng ba mục tiêu chính: Backup định kỳ và nhất quán, Replication dữ liệu theo thời gian thực hoặc gần thời gian thực sang một môi trường dự phòng, và Failover tự động hoặc một-click khi sự cố xảy ra. Kiến trúc đề xuất bao gồm các thành phần sau:

  • VPS Chính (Primary): Môi trường sản xuất đang chạy ứng dụng.
  • VPS Dự phòng (Secondary/DR Site): Được cấu phòng sẵn ở một vùng địa lý hoặc với một nhà cung cấp khác, ở trạng thái "ấm" (warm) – tài nguyên đã được cấp, hệ điều hành đã cài, chờ đồng bộ dữ liệu và ứng dụng.
  • Hệ thống Điều phối (Orchestrator): Một máy chủ riêng biệt hoặc dịch vụ chạy các script điều khiển, thường được viết bằng Bash/Python, kết nối với API của nhà cung cấp VPS (DigitalOcean, AWS, GCP, v.v.).
  • Kho lưu trữ Cấu hình: Một Git repository chứa toàn bộ mã Terraform, playbook Ansible, script và biến môi trường.
  • Hệ thống Giám sát: Công cụ như Nagios, Prometheus, hoặc UptimeRobot để phát hiện sự cố và kích hoạt quy trình failover.

Bước 1: Tự động hóa Backup với Script và Cron

Backup là nền tảng của mọi chiến lược DR. Thay vì thao tác thủ công, chúng ta sẽ tự động hóa toàn bộ.

1.1. Script Backup Toàn diện

Tạo một script Bash (perform_backup.sh) chạy trên VPS chính, thực hiện:

  • Dump cơ sở dữ liệu (MySQL/PostgreSQL) với timestamp.
  • Đóng gói (tar) thư mục ứng dụng (ví dụ: /var/www/html), loại trừ file cache hoặc log không cần thiết.
  • Đồng bộ các file đã đóng gói lên dịch vụ lưu trữ đám mây như AWS S3, Google Cloud Storage, hoặc Backblaze B2 sử dụng rclone hoặc aws cli.
  • Ghi log chi tiết và gửi thông báo qua email hoặc Slack khi hoàn thành hoặc thất bại.

1.2. Lập lịch với Cron và Giám sát

Đưa script vào crontab để chạy hàng ngày vào giờ thấp điểm:

0 2 * * * /usr/local/bin/perform_backup.sh >> /var/log/backup.log 2>&1

Sử dụng Ansible để đảm bảo script và cron job được triển khai nhất quán lên tất cả VPS chính. Playbook Ansible cũng có thể cài đặt và cấu hình các công cụ backup cần thiết như rclone.

Bước 2: Replication Tự động với Ansible và Rsync

Một bản backup hàng ngày là chưa đủ cho RPO (Recovery Point Objective) thấp. Chúng ta cần replication liên tục hoặc thường xuyên hơn.

2.1. Đồng bộ Cấu hình và Dữ liệu

Tạo một playbook Ansible (replicate.yml) chạy từ máy điều phối, thực hiện:

  1. Đồng bộ file ứng dụng: Sử dụng module synchronize (dựa trên rsync) để sao chép incremental các file từ Primary sang Secondary.
  2. Replicate database: Thiết lập replication master-slave cho MySQL/PostgreSQL, hoặc sử dụng tool như pg_basebackup cho PostgreSQL.
  3. Áp dụng cấu hình hệ thống: Đảm bảo cấu hình firewall, service, và users trên Secondary giống hệt Primary.

2.2. Kích hoạt Replication Định kỳ

Playbook replication có thể được kích hoạt bởi Cron (ví dụ: mỗi 15 phút) hoặc bởi một hệ thống CI/CD như Jenkins/GitLab CI mỗi khi có thay đổi cấu hình được commit vào Git. Điều này đảm bảo DR site luôn ở trạng thái gần nhất có thể với production.

Bước 3: Quản lý Hạ tầng Dự phòng với Terraform

Terraform cho phép chúng ta khai báo toàn bộ hạ tầng VPS dự phòng dưới dạng mã.

3.1. Khai báo Tài nguyên DR

File dr-infra.tf định nghĩa:

  • VPS dự phòng với spec tương đương (hoặc tối thiểu chấp nhận được) tại một region khác.
  • Firewall rules, volumes, và network configuration cần thiết.
  • DNS record (ví dụ: dr.yourdomain.com) trỏ đến IP của VPS dự phòng, với TTL thấp.

Ưu điểm: Toàn bộ DR site có thể được tạo mới (terraform apply) hoặc hủy (terraform destroy) một cách nhất quán và nhanh chóng. Đây là cơ sở cho việc tái tạo hoàn toàn môi trường nếu cần.

Bước 4: Kịch bản Failover Tự động (Orchestration)

Đây là trái tim của hệ thống DRaC. Khi hệ thống giám sát phát hiện Primary down, một script điều phối chính (initiate_failover.sh) sẽ được kích hoạt.

4.1. Luồng Failover Tự động

  1. Xác nhận sự cố: Script kiểm tra lại trạng thái Primary từ nhiều nguồn để tránh báo động giả.
  2. Kích hoạt VPS Dự phòng: Nếu Secondary đang ở trạng thái "tắt", script sẽ gọi API để khởi động nó.
  3. Chuyển đổi Database: Nâng cấp database slave trên Secondary thành master, cập nhật cấu hình ứng dụng để trỏ đến database mới.
  4. Cập nhật DNS: Sử dụng API của nhà cung cấp DNS (Cloudflare, Route53) để thay đổi record chính (ví dụ: www.yourdomain.com) từ IP của Primary sang IP của Secondary. Đây là bước chuyển hướng lưu lượng thực tế.
  5. Khởi động Ứng dụng: Chạy playbook Ansible trên Secondary để đảm bảo tất cả services (web server, app server) đang chạy với cấu hình đúng.
  6. Thông báo: Gửi alert chi tiết đến đội ngũ vận hành về việc failover đã diễn ra.

4.2. Failback và Kiểm thử Định kỳ

Khi Primary được khôi phục, một quy trình failback có trật tự cần được thực hiện để đưa hệ thống về trạng thái ban đầu. Quan trọng hơn, toàn bộ kịch bản failover cần được kiểm thử định kỳ (ví dụ: hàng quý) trong môi trường cách ly để đảm bảo nó hoạt động khi khẩn cấp thực sự. Terraform và Ansible giúp việc tạo một môi trường sandbox để test trở nên dễ dàng và có thể hủy bỏ sau đó.

Lợi ích và Thách thức

Lợi ích

  • Giảm RTO đáng kể: Thời gian phục hồi từ vài giờ xuống còn vài phút.
  • Giảm lỗi con người: Quy trình được chuẩn hóa và tự động hóa.
  • Kiểm soát phiên bản và Tài liệu sống: Mã nguồn DR chính là tài liệu kỹ thuật chính xác nhất.
  • Khả năng kiểm thử: DR không còn là "hộp đen" không thể chạm vào.
  • Nhất quán: Môi trường dự phòng luôn đồng bộ với thiết kế và cấu hình mới nhất.

Thách thức cần lưu ý

  • Độ phức tạp ban đầu: Yêu cầu đầu tư thời gian để thiết kế, viết mã và tích hợp.
  • Quản lý Secret: API keys, database password phải được quản lý an toàn (sử dụng Vault, AWS Secrets Manager) và không được commit vào Git.
  • Chi phí: Duy trì một VPS dự phòng "ấm" và lưu trữ backup sẽ phát sinh chi phí liên tục.
  • Giám sát hệ thống DR: Bản thân hệ thống điều phối và các script cũng cần được giám sát để đảm bảo chúng sẵn sàng khi cần.

Kết luận

Áp dụng phương pháp "Disaster Recovery as Code" cho VPS không còn là lựa chọn xa xỉ, mà là một yêu cầu thiết yếu cho các doanh nghiệp coi trọng tính liên tục trong hoạt động. Bằng cách sử dụng Terraform, Ansible và các script tự động, bạn biến một quy trình phức tạp, dễ sai sót thành một tài sản mã nguồn có thể kiểm soát, cải tiến và tin cậy. Hãy bắt đầu từ những bước nhỏ: tự động hóa backup, sau đó xây dựng replication, và cuối cùng là kịch bản failover. Mỗi bước đều làm tăng khả năng phục hồi của hệ thống và mang lại sự an tâm cho cả đội kỹ thuật lẫn doanh nghiệp.

Trong kỷ nguyên số, khả năng phục hồi sau thảm họa không phải là một tính năng bổ sung—mà là nền tảng của sự tin cậy.