Gần đây có anh bạn nói với tôi rằng server OVH của công ty ảnh bị revert dữ liệu về 8 tháng trước. Tôi không tin, nhưng vẫn vào kiểm tra.

Và quả thật, những thay đổi gần đây mất sạch, server trở về trạng thái của quá khứ. Nó rơi vào 1 trong 2 kịch bản:

  • Ổ cứng Zombie (Forgotten Drive): Một trong hai ổ RAID bị loại khỏi array do lỗi tạm thời (gọi là ổ B). Ổ A vẫn sống và hoạt động tiếp, một ngày đẹp trời ổ A đột tử, hệ thống boot lại bằng ổ B (ổ zombie chứa dữ liệu cũ).
  • Sự cố vật lý từ nhà cung cấp: OVH mất data và bản backup gần nhất của họ là 8 tháng trước. Họ âm thầm restore trong đêm. Nói thật, với OVH thì điều gì cũng có thể xảy ra.

Hiện tại OVH chưa trả lời ticket. Nhưng vấn đề chính ở đây là bạn tôi không có bản external backup nào cho đống website đó cả.

Backup trước, nói chuyện sau 2

Anh bạn tôi đã dọn dẹp đủ loại site bị hack, server sập nguồn, hay database lỗi corrupt. Kinh nghiệm không thiếu, lại có sự trợ giúp của AI. Nhưng anh vẫn mắc một sai lầm sơ đẳng nhất của SysAdmin: Quên Backup.

Mục lục hide
1. Sự ảo tưởng về Ctrl+Z
2. Bản Backup của Schrodinger
3. Quy tắc 3-2-1
4. Giám sát
5. Tự động hóa

1. Sự ảo tưởng về Ctrl+Z

Khi sự cố xảy ra, trình độ của bạn không quan trọng bằng bản backup gần nhất bạn có.

Dân Dev viết code trên IDE quen tay Ctrl+Z (Undo). Nhưng khi bạn SSH vào server, gõ lệnh trên terminal, không có nút Undo nào cả.

Một lệnh rm -rf sai đường dẫn, một câu DROP TABLE thiếu WHERE, hay đơn giản là update OS và nó conflict thư viện… Website trắng trang.

Lúc đó, khách hàng không quan tâm nguyên nhân là gì. Họ chỉ hỏi: “Bao giờ thì web chạy lại?”

  • Nếu có backup: “Tầm 15 phút nữa.”
  • Nếu không: “…” (Im lặng và cập nhật CV).

Thế nên, nguyên tắc số 1 SysAdmin: Backup first, always! Trước khi deploy code mới? Backup. Trước khi chạy lệnh update? Backup. Trước khi đi ngủ? Kiểm tra backup.

2. Bản Backup của Schrodinger

File backup vừa tồn tại vừa không tồn tại cho đến khi bạn thử Restore nó.

Tôi từng gặp trường hợp hệ thống báo backup thành công suốt 6 tháng. Đến khi server chết ổ cứng, lôi backup ra restore thì mới phát hiện file rỗng (0KB) do script lỗi permission. Cũng may tôi có thói quen thi thoảng cold-backup thủ công về ổ NAS tại nhà nên gọi là “cứu được”, nhưng vẫn bị khách hàng chửi cho không trượt phát nào.

Bài học rút ra: Đừng chỉ setup backup. Hãy định kỳ (hàng tuần/tháng) thử xóa một môi trường staging và khôi phục lại từ backup. Nếu chưa từng thử restore, coi như bạn chưa có backup.

3. Quy tắc 3-2-1

Chi phí lưu vài trăm GB backup rẻ hơn rất nhiều so với cái giá phải trả khi thông báo với khách hàng: “Xin lỗi, chúng tôi đã mất tất cả.”

  • 3 bản Copy dữ liệu (ít nhất): Nghĩa là ngoài dữ liệu gốc (Production) đang chạy, bạn phải có thêm 2 bản sao lưu nữa.
    • Việc Copy file code.zip ra thành code_bak.zip nằm trên cùng 1 server không được tính là 2 bản. Lỡ tay xóa hay ổ cứng hỏng là đi cả đôi. Vì vậy 3 bản này phải độc lập về mặt logic.
  • 2 Loại phương tiện lưu trữ (Media Type): Đừng lưu tất cả trên cùng một loại ổ cứng.
    • Ví dụ đúng: Bản chính trên SSD VPS. Backup 1 trên NAS văn phòng. Backup 2 trên Cloud Object Storage (S3, GCS).
    • Lưu ý: RAID không phải là Backup. RAID chỉ giúp hệ thống chạy tiếp khi chết 1 ổ cứng (Availability), chứ không cứu được dữ liệu khi bạn lỡ tay xóa file hay dính Ransomware.
  • 1 Bản Off-site (Khác vị trí địa lý): Quan trọng nhất để chống thảm họa vật lý (cháy, lũ, trộm cắp).
    • Rủi ro: Server đặt ở Data Center Hà Nội, backup ra con server khác… nằm ngay rack bên cạnh. Một vụ hỏa hoạn (như vụ OVH cháy ở Strasbourg năm 2021) sẽ thiêu rụi cả Production lẫn Backup.
    • Giải pháp: Đẩy một bản lên Cloud (Region khác như Singapore/Tokyo) hoặc sync về máy tính cá nhân.

Tóm lại: 1 bản chạy, 1 bản local backup, 1 bản cloud backup. Nếu dùng Serverless thì chọn Cloud Provider khác nhau (AWS backup sang GCP).

4. Giám sát

No news is often Bad news.

Bạn setup script chạy lúc 3 giờ sáng. Sáng dậy log im re, không báo lỗi. Bạn nghĩ: “Ngon, đêm qua mọi thứ suôn sẻ.”

Tuy nhiên, theo định luật Murphy thì sự im lặng của hệ thống backup thường là dấu hiệu của thảm họa. Cron service có thể treo, server có thể reboot đúng lúc đó, script có thể output ra file rỗng.

Nguyên tắc giám sát backup:

  1. Ồn ào khi thất bại: Nếu exit code khác 0, hệ thống phải “gào thét” ngay (Telegram, Slack, SMS). Đừng ghi log vào file text mà cả năm chẳng ai đọc.
  2. Check cả đầu ra: Script báo “Success” chưa chắc đã ổn. Hãy check logic: File có > 0KB không? Dung lượng có sụt giảm bất thường không? (Database 5GB backup còn 100MB là có biến).
  3. Dead Man’s Switch (Quan trọng): Đừng chỉ chờ báo lỗi. Hãy dùng cơ chế “Heartbeat”. Nếu đến 4 giờ sáng mà Monitoring không nhận được tín hiệu “Backup thành công”, nó phải báo động. Đây là cách duy nhất phát hiện việc backup bị “quên” chạy.

5. Tự động hóa

Automate the boring, monitor the chaos.

Con người hay quên và lười. Đừng chạy backup bằng tay. Script hóa nó, ném vào Cronjob, dùng AWS Lifecycle Manager… miễn là nó tự chạy.

DevOps giỏi thường hay khoe mình rảnh, vì họ làm những thứ để bản thân trở nên “thừa thãi”. Hệ thống phải tự biết bảo vệ nó. Mục tiêu đơn giản: Tắt điện thoại đi ngủ và biết rằng sáng mai dù server có cháy, dữ liệu khách hàng vẫn an toàn ở nơi khác.

Kết: Web hay App sập, dựng lại phút mốt. Nhưng dữ liệu đã mất là mất vĩnh viễn. Hãy check lại hệ thống backup của bạn ngay sau khi đọc bài này nhé!