Sao lưu dữ liệu không hề đơn giản như bạn tưởng

Có một câu nói mà tôi đọc được đâu đó và nó cứ đọng lại mãi trong đầu: "Trên đời có hai loại người — những người đã từng mất sạch dữ liệu, và những người sẽ mất."

Nghe có vẻ bi quan, nhưng nếu bạn hỏi bất kỳ quản trị viên hệ thống nào, bạn sẽ nhận được vô số phiên bản khác nhau của cùng một câu chuyện. Mất dữ liệu xảy ra thường xuyên hơn chúng ta tưởng, và hầu hết chúng ta đều chuẩn bị cực kỳ kém cho khoảnh khắc đó — mà nó lại thường ập đến vào đúng thời điểm tồi tệ nhất.

Bài học từ một ổ cứng bị format nhầm

Tác giả bài viết gốc kể lại trải nghiệm thời thơ ấu: cả gia đình gom toàn bộ ảnh từ laptop và PC vào một ổ cứng ngoài để giải phóng dung lượng. Mọi thứ diễn ra tốt đẹp cho đến khi bố anh muốn dùng ổ đó để lưu trữ cho đầu thu truyền hình và bị hộp thoại yêu cầu format ổ đĩa. Ông bấm đồng ý. Danh mục file bị xóa sạch, và họ ngồi nhìn một ổ cứng "trống rỗng" trên danh nghĩa.

Rất dễ đổ lỗi cho bố anh, nhưng phải đến khi bước chân vào ngành công nghệ, anh mới nhận ra đó là một chuỗi sai lầm hệ thống:

• Đặt toàn bộ ảnh quan trọng vào một chỗ duy nhất và không hề có bản sao lưu nào
• Phần mềm tiêu dùng thường có cảnh báo rõ ràng rằng format ổ là mất dữ liệu — nhưng chiếc đầu thu truyền hình thì không, một thiết kế giao diện tồi tệ
• Và quan trọng nhất: tại sao lại kỳ vọng một người không chuyên hiểu hết những điều này?

May mắn là họ khôi phục được ảnh. Nhưng đó là một bài học rẻ tiền về cách xử lý dữ liệu: bạn không bao giờ được giữ những thứ quan trọng ở chỉ một nơi. Có cả triệu thứ có thể hỏng hóc — ổ cứng chết, bị trộm, hoặc hiện tượng "bit rot" khi dữ liệu mục ruỗng theo thời gian (ổ HDD dùng hạt từ tính có thể dịch chuyển không rõ nguyên nhân, còn SSD dùng transistor NAND rò rỉ điện và làm hỏng dữ liệu dần dần).

Từ ổ cứng dự phòng đến snapshot

Nguyên tắc đầu tiên là phải có bản sao lưu — tức một bản copy của file ở nơi khác. Nhưng chỉ vậy là chưa đủ.

Hãy tưởng tượng ổ cứng dự phòng của bạn luôn được cắm điện. Một con ransomware có thể mã hóa sạch file của bạn. Bạn có thể xóa nhầm file, hoặc tồi tệ hơn là chạy một script ghi đè toàn bộ bằng số 0. Nghĩa là bản sao lưu không nên là bản gương của ổ chính, vì chúng ta còn cần khả năng quay ngược thời gian khi bản thân mắc lỗi.

Điều này loại bỏ luôn kiểu sao lưu gương như RAID 1. Chúng ta cần một cơ chế khác có khả năng chụp ảnh trạng thái — gọi là snapshot.

Vậy bao lâu thì chụp một lần? Trong trường hợp ảnh gia đình, có lẽ mỗi tuần một lần là hợp lý. Nếu mất 6 ngày 23 giờ dữ liệu thì vẫn chấp nhận được. Trong ngành IT, người ta gọi đây là Recovery Point Objective (RPO) — mức độ dữ liệu tối đa có thể mất mà vẫn chấp nhận được.

Chỉ số RPO trong thực tế dao động rất lớn: dưới 30 giây với các tổ chức tài chính quan trọng, đến 24 giờ hoặc hơn với các doanh nghiệp nhỏ — nếu như họ có chiến lược phục hồi thảm họa nào.

Vấn đề dung lượng và chiến lược GFS

Chụp snapshot liên tục đồng nghĩa với gánh nặng lưu trữ tăng dần. Với RPO 24 giờ, bạn sẽ có 7 snapshot mỗi tuần, 30 mỗi tháng, 365 mỗi năm nếu không bao giờ dọn dẹp. Vậy nên bạn buộc phải xoay vòng (rotation) backup.

Cách ngây thơ nhất là giữ 14 ngày gần nhất, mỗi lần chụp mới thì xóa cái cũ nhất. Nhưng cách này buộc bạn phải túc trực kiểm tra xem có gì hỏng trong hai tuần qua không. Và giữ nguyên một năm backup cũng vô nghĩa — chuyện xảy ra giữa ngày thứ 2 và ngày thứ 3 của năm chẳng còn giá trị gì khi đã đến ngày thứ 364.

Giải pháp là thay đổi độ chi tiết theo thời gian: càng gần hiện tại, snapshot càng dày; càng xa, càng thưa. Ví dụ bạn có thể xoay vòng backup hàng ngày sau 14 ngày, backup hàng tuần sau 7 tuần, và backup hàng tháng sau 12 tháng. Kỹ thuật này gọi là GFS rotation (Grandfather-Father-Son).

Deduplication — bài học từ nén video MPEG

Nếu bạn từng tìm hiểu cách MPEG nén video, bạn sẽ thấy một cảnh phim tĩnh — nhân vật nói chuyện nhưng nền đứng yên — được nén cực kỳ hiệu quả vì các frame gần như giống hệt nhau, chỉ khác một vector chuyển động nhỏ.

Snapshot cũng vậy. Và hóa ra sự thay đổi của file tuân theo phân phối đuôi béo (fat-tailed distribution): trong một khoảng thời gian, đại đa số file không thay đổi chút nào, chỉ một nhóm rất nhỏ thay đổi liên tục.

Vậy nên thay vì lưu các bản copy giống hệt nhau, ta nên deduplicate. Có thể dùng hard link để tham chiếu đến file đã tồn tại: chỉ lưu một file trên đĩa và trỏ đến nó từ mỗi snapshot. Cách này còn sống sót qua việc xoay vòng backup vì ta không xóa file, chỉ xóa entry trong thư mục. Công cụ rsnapshot dùng đúng cách tiếp cận này, và nó được gọi là incremental backup.

Lợi ích không chỉ nằm ở dung lượng. Khi phải truyền file qua mạng — đặc biệt là lên cloud — deduplication tiết kiệm rất nhiều băng thông, và điều đó ảnh hưởng trực tiếp đến hóa đơn hàng tháng của bạn.

Đến lúc này, chúng ta đã có một hệ thống: incremental, deduplicated, GFS-rotated, snapshot-based backup. Dùng rsync để kéo file từ máy chính và cronjob để chạy script. Metadata được giữ nguyên, quyền truy cập và quyền sở hữu file vẫn ổn.

Khi homelab và Docker phá vỡ mọi thứ

Nhưng rồi bạn thử áp dụng cho homelab với 10 container Docker và phát hiện backup thất bại. Lý do: nhiều container tạo ra file thuộc quyền root, và nếu bạn không cẩn thận, cronjob sẽ chạy dưới user mặc định.

Tệ hơn nữa, gần như mọi web app đều dùng database. Database thích lưu dữ liệu trong bộ nhớ rồi ghi theo lô để tăng hiệu năng — nghĩa là nếu kém may, khôi phục từ backup sẽ thất bại vì dữ liệu hỏng. Bạn buộc phải cho backup dump cả database và cấp quyền truy cập toàn bộ filesystem trên các volume Docker.

Quy tắc 3-2-1 và cái bẫy cloud

Rồi bạn đọc về những dòng ổ cứng có tỷ lệ hỏng cao khét tiếng và tự hỏi liệu có nên lưu backup trên hai máy dùng hai loại phương tiện khác nhau. Và khi nói đến an ninh vật lý, nên có một bản offsite trên cloud hoặc ở nhà người thân — để một cú sốc điện, lũ lụt hay hỏa hoạn không thể xóa sạch mọi thứ.

Đây chính là nguồn gốc của quy tắc 3-2-1: 3 bản copy, trên 2 loại phương tiện khác nhau, với 1 bản offsite.

Giả sử bạn chọn Amazon S3 làm nơi lưu offsite. Bạn nhanh chóng phát hiện thiết lập hiện tại không hoạt động vì hai lý do: một, file mất metadata khi upload lên S3; hai, chi phí upload nhiều file nhỏ lên S3 cực kỳ đắt đỏ. Cả hai điều này buộc bạn phải gom nhiều file vào một tarball — nhưng làm sao để chia thành các chunk 50MB một cách an toàn và có thể kiểm chứng được? Đây là lúc nên bỏ cuộc.

Đừng tự xây dựng hệ thống backup

Điều mà thoạt đầu nghe như một việc làm trong một buổi chiều hóa ra lại là một bài toán vô tận. Đơn giản là không đáng để gánh thêm áp lực tinh thần cho tất cả những thứ này.

Thay vào đó, hãy dùng những công cụ đã được kiểm chứng như Borg hoặc Restic — chúng xử lý mọi thứ và còn làm được nhiều hơn (mã hóa, deduplication ở cấp độ chunk, checksum). Và hãy dành lòng biết ơn sâu sắc đến cộng đồng mã nguồn mở vì đã xây dựng, duy trì và kiểm thử thực tế những công cụ này, trong khi tôn trọng lượng thử-và-sai cần thiết để đưa tất cả sự phức tạp đó vào một lớp trừu tượng mà chúng ta chỉ cần dùng.

Lời khuyên cuối: hãy thực sự test khôi phục

Tất cả những gì trên đây đều vô nghĩa nếu bạn không thực sự chạy thử khôi phục dữ liệu. Hãy đặt lịch kiểm tra restore mỗi 6 tháng một lần — đó là một thói quen vệ sinh số mà bạn cần thêm vào danh sách việc cần làm.

Và một lưu ý nhỏ cuối cùng: đừng bao giờ chạy backup lúc 2 giờ hay 3 giờ sáng — mọi thứ có thể trở nên đáng sợ đấy.