Có một việc trong nghề vận hành mà làm đúng thì không ai thấy gì, còn làm sai thì cũng không ai thấy gì, cho đến đúng cái ngày không còn cơ hội sửa. Việc đó là backup.
Có lần một anh bạn nói với tôi rằng server OVH của công ty anh vừa quay về dữ liệu của 8 tháng trước. Tôi không tin. Dữ liệu không tự lùi lịch như vậy. Nhưng tôi vẫn vào kiểm tra, và đúng là mọi thay đổi trong 8 tháng gần nhất biến mất, server đang chạy một trạng thái của quá khứ.
Lúc đó nguyên nhân chưa rõ. Có vài khả năng được đem ra bàn, từ ổ RAID đến chuyện bên nhà cung cấp, nhưng bàn thì bàn, không ai có bằng chứng, và ticket gửi OVH lúc ấy chưa có phản hồi. Điều rõ ràng duy nhất nằm ở câu hỏi tiếp theo: bản sao bên ngoài server đâu? Câu trả lời là không có.
Terminal không có nút Undo
Dân viết code sống với Ctrl+Z nhiều năm, đến mức ngón tay tự tin hơn cái đầu. Lỡ tay thì lùi một bước. Thói quen đó đi theo lúc SSH vào server, và ở đó nó không còn chỗ dựa.
Một câu DELETE FROM thiếu WHERE, một lệnh rm -rf lệch đường dẫn, một lần update hệ điều hành kéo theo xung đột thư viện. Lệnh chạy xong trong chưa tới một giây, trang web trắng. Lúc đó khách hàng không hỏi lệnh nào gây ra. Họ chỉ hỏi bao giờ web chạy lại.
Kinh nghiệm của người cầm terminal vẫn có giá: biết đánh giá tình hình, biết thử cách nào trước, biết đừng làm gì để hỏng thêm. Nhưng thứ quyết định web chạy lại nhanh hay chậm, và lấy lại được bao nhiêu, là bản backup gần nhất, bản đó bao nhiêu tuổi, và khôi phục từ nó mất bao lâu. Có bản sao thì người giỏi có nhiều lựa chọn và ít phải cầu may. Không có bản sao thì người giỏi cũng chỉ còn những cách cứu hộ chậm, tốn tiền và không chắc ăn.
Vì vậy thứ tự công việc nên đặt ngược lại so với bản năng. Trước khi deploy thì backup. Trước khi chạy update thì backup. Còn tranh luận tại sao hỏng, lỗi ở ai, có nên đổi nhà cung cấp không, để sau. Dữ liệu còn thì mọi cuộc nói chuyện đều có thể diễn ra. Dữ liệu mất thì cuộc nói chuyện nào cũng ngắn đi rất nhiều.
Backup chỉ tồn tại sau khi khôi phục được
Tôi từng có một hệ thống báo backup thành công đều đặn suốt 6 tháng. Đến hôm server chết ổ cứng, lôi file ra khôi phục mới thấy chúng rỗng, 0KB, do script dính lỗi phân quyền. Nó không ghi được gì nhưng vẫn báo xong, và suốt nửa năm không ai mở file ra xem.
May là tôi có thói quen thi thoảng cold backup thủ công về ổ NAS ở nhà. Bản đó có thật, nên gọi là cứu được. Khách hàng vẫn chửi, và chửi đúng, vì tôi đã tin một dòng chữ "Success" suốt nửa năm mà không một lần kiểm chứng.
Bài học rút ra khá nhàm nhưng vẫn phải nhắc: một bản backup chưa từng được khôi phục thử thì về mặt thực tế chưa phải là backup. Nó là một file có tên gợi hy vọng. CISA, cơ quan an ninh mạng của Mỹ, trong hướng dẫn chống ransomware cũng khuyên kiểm tra khôi phục định kỳ, chứ không chỉ dừng ở việc có bản sao. Bạn có thể đọc trong Ransomware Guide .
Một lần thử khôi phục là bằng chứng tốt, nhưng là bằng chứng cho hệ thống đó, phạm vi đó, ở thời điểm đó. Dữ liệu đổi, script đổi, quyền truy cập đổi, nên việc này cần lặp lại định kỳ và cần bao đủ những gì bạn thật sự muốn lấy lại.
Trước khi thử, nên tự trả lời hai câu. Hệ thống được phép nằm im bao lâu trước khi dùng lại được, và bạn chấp nhận mất tối đa bao nhiêu dữ liệu gần nhất. Đó là hai mục tiêu. Lần thử khôi phục cho bạn con số đo thật để đem so với mục tiêu ấy. Hai con số hay khác nhau nhiều hơn người ta tưởng, và tốt hơn là biết điều đó vào một buổi chiều rảnh thay vì vào ngày có sự cố.
Ba bản, nhưng không được chết cùng nhau
Quy tắc 3-2-1 nhiều người thuộc, nhưng hay thuộc sai một chi tiết. Nó là giữ tổng cộng 3 bản dữ liệu tính cả bản gốc đang chạy, lưu trên 2 loại phương tiện khác nhau, và có 1 bản ở nơi khác. Một cảnh báo bảo mật do CISA đồng phát hành nhắc lại quy tắc này trong phần khuyến nghị.
Con số 3 dễ đạt trên giấy. Chép code.zip thành code_bak.zip cùng một thư mục, về mặt đếm thì đã có hai bản. Về mặt rủi ro thì gần như vẫn là một, vì chúng chia sẻ quá nhiều điểm hỏng chung. Ổ hỏng là mất cả đôi. Lệnh xóa nhầm thư mục là mất cả đôi.
RAID cũng hay bị tính nhầm vào đây. RAID giúp hệ thống chạy tiếp khi một ổ chết, tức là tăng khả dụng. Nó không giúp gì khi bạn xóa nhầm, vì RAID sẽ xóa nhầm giúp bạn trên mọi ổ cùng lúc, rất đúng và rất nhanh.
Snapshot và các cơ chế đồng bộ lên cloud cũng cần nhìn kỹ ở một điểm: ai có quyền xóa. Nếu tài khoản đang chạy production có quyền xóa luôn cả snapshot hay bucket chứa bản sao, thì một lần lộ credential hay một script chạy sai có thể dọn sạch cả hai. Chuyển sang nhà cung cấp khác không tự giải quyết chuyện này. Cái cần tách là quyền và đường đi tới bản sao, chứ không chỉ cái tên công ty trên hóa đơn.
Bản ở nơi khác thì chống thảm họa vật lý. Backup đặt ở rack cạnh bên production thì cháy cũng cạnh bên. Hướng dẫn chống ransomware của CISA còn khuyên thêm hai điều: giữ ít nhất một bản offline, tức là không nối thường trực với hệ thống đang chạy, và mã hóa các bản sao. Cái NAS ở nhà của tôi hồi đó ít nhất không nằm cùng server, và chừng đó đã đủ để lần ấy còn đường lui.
Khi hệ thống im lặng
Script backup chạy lúc 3 giờ sáng. Sáng dậy không thấy cảnh báo. Người bình thường sẽ hiểu là đêm qua ổn. Người làm vận hành đủ lâu sẽ hỏi lại một câu: ổn, hay là không có gì chạy nên không có gì để báo.
Cron có thể treo. Server có thể reboot đúng giờ đó. Script có thể gặp lỗi ở giữa chừng mà vẫn báo thành công, nếu nó chỉ kiểm tra việc mình đã chạy xong chứ không kiểm tra có dữ liệu trong file hay không. Sự im lặng của một hệ thống backup chứa rất ít thông tin, và một hệ thống giám sát chỉ chờ tín hiệu lỗi sẽ bỏ sót toàn bộ nhóm sự cố "không chạy".
Cách sửa là đảo chiều. Thay vì chờ báo lỗi, hệ thống giám sát chờ tín hiệu "đã xong", và nếu đến giờ hẹn mà không nhận được thì báo động. Cùng với đó là theo dõi tuổi của bản backup mới nhất. Một bản ba tuần tuổi có thể đủ cho dữ liệu ít thay đổi, nhưng với dữ liệu đổi mỗi giờ thì ba tuần là ba tuần công việc mất trắng. Ngưỡng báo động nên đi theo câu hỏi bạn chấp nhận mất bao nhiêu ở phần trên.
Kích cỡ file cũng đáng để mắt. Database vài GB mà bản backup bỗng nhỏ bất thường so với các lần trước thì chưa chắc là hỏng, có thể do nén hoặc do dữ liệu thật sự thay đổi. Nhưng đó là tín hiệu để mở ra xem, chứ không nên để trôi qua. Sụt mạnh là lý do để kiểm tra, không phải kết luận.
Cuối cùng là phần hay bị quên nhất: những thứ cần có để khôi phục ngoài file dữ liệu. Khóa mã hóa đang nằm ở đâu, ai mở được. Tài khoản truy cập kho backup còn hoạt động không. File cấu hình, biến môi trường, chứng chỉ đã có trong bản sao chưa. Một bản backup mã hóa rất tốt với chiếc khóa nằm trên chính server vừa chết là một câu đố không có lời giải.
Việc dễ nhất lại là việc hay bị bỏ qua
Nếu kể lại cả bài theo cách ngắn nhất thì nó chỉ còn hai ý. Backup đáng tin khi bạn đã khôi phục từ nó, và còn kiểm tra lại định kỳ. Và nó chỉ hữu ích khi không chết cùng production, dù production chết vì ổ cứng, vì lệnh gõ nhầm, vì đám cháy hay vì một tài khoản bị lộ.
Phần lịch chạy và báo động thì nên giao cho máy. Script, cron, hệ thống giám sát, dùng gì cũng được, miễn là không ai phải tự nhớ đêm qua backup đã chạy chưa. Nhưng có những việc máy không quyết thay: backup cái gì, bỏ cái gì, bản sao nằm ở đâu, ai có quyền xóa, và thế nào mới được tính là khôi phục thành công. Lifecycle rule của nhà cung cấp cũng chỉ quyết giữ bản sao bao lâu, nó không tự tạo ra bản sao. Máy giúp bạn không phải nhớ, còn kết quả thì vẫn cần có người mở ra xem theo lịch.
Tám tháng dữ liệu của anh bạn tôi đáng lẽ đã nằm ở một chỗ khác từ lâu, lặng lẽ, đều đặn, và có người mở ra xem mỗi tháng một lần. Nếu lúc này bạn chưa chắc hệ thống của mình có khôi phục được không, thì đó chính là câu trả lời. Đi kiểm tra trước, chuyện khác nói sau.
No comments yet