Cách sao lưu VPS lên storage offshore đã mã hóa

Hầu như không ai thiết lập sao lưu ngay trong ngày triển khai server. Chuyện đó luôn xảy ra sau đó — sau khi một ổ đĩa đầy tràn giữa lúc nâng cấp, sau một lần xóa nhầm thư mục, sau khi một lần migration để lại một database khởi động bình thường nhưng trả lời sai, sau khi có kẻ đột nhập. Khoảng cách giữa việc vận hành một cỗ máy quan trọng và việc giữ một bản sao sống lâu hơn nó chính là khoảng thời gian nguy hiểm nhất trong toàn bộ chuyện tự vận hành, và hầu hết mọi người sống trong khoảng đó suốt nhiều tháng mà không hề hay biết, vì không có gì trục trặc trong một thời gian dài — rồi mọi thứ sụp đổ cùng lúc. Khép lại khoảng cách đó không khó và cũng không tốn kém. Thứ khiến nó có vẻ khó chính là từ "sao lưu" bị dùng cho bốn thứ hoàn toàn khác nhau, mà chỉ đúng một trong số đó còn tồn tại vào đúng cái ngày tồi tệ ấy.

Bốn thứ không phải là một bản sao lưu

Mỗi thứ trong số đó đều thực sự hữu ích và đáng để có. Nhưng không thứ nào trong số đó là một bản sao lưu, và tin rằng chúng là như vậy chính là lý do phổ biến nhất khiến người ta mất đi dữ liệu mà họ từng tưởng là an toàn. Sự phân biệt này không hề vụn vặt — mỗi thứ trong số đó thất bại đúng vào tình huống mà bạn cần một bản sao lưu nhất.

• RAID là uptime, không phải một bản sao lưu. Một mảng RAID sống sót qua một ổ đĩa chết mà không phải ngừng hoạt động, đó là lý do các máy chủ storage của chúng tôi chạy RAID-6 và chịu được hai lần hỏng cùng lúc. Nó không sống sót qua một thư mục bị xóa, một lần nâng cấp lỗi, một cây thư mục file bị người khác mã hóa, hay một bảng dữ liệu bị xóa mất — tất cả những điều đó đều được ghi trung thực lên mọi ổ đĩa trong cùng một khoảnh khắc.
• Snapshot là undo, không phải một bản sao lưu. Chúng nằm trên cùng hệ thống lưu trữ với dữ liệu, thường có thể nhìn thấy được bởi root trên cùng cỗ máy, và bất cứ thứ gì phá hủy volume hay host đều kéo theo cả các snapshot đó. Rollback nhanh, nhưng vô dụng khi cỗ máy đã không còn.
• Đồng bộ (sync) là nhân bản, không phải một bản sao lưu. Một công cụ đồng bộ tồn tại để làm cho phía xa khớp với phía gần, nên một lần xóa hay một lần hỏng dữ liệu sẽ được lan truyền sang bản sao nhanh như mạng cho phép. Nextcloud, Dropbox và rclone sync đều được thiết kế để hoạt động theo đúng cách đó.
• Lưu phiên bản và thùng rác là tiện lợi, không phải một bản sao lưu. Đó là các tính năng của ứng dụng, được lưu trong chính database của ứng dụng, với thời gian giữ lại tính bằng ngày. Khi chính ứng dụng đó bị hỏng, lịch sử phiên bản của nó cũng hỏng theo.
• Một bản sao trên cùng server không phải là offsite. Nếu sự cố là chính cỗ máy, tài khoản nhà cung cấp, hypervisor, hay một vụ tịch thu, thì mọi file trên cỗ máy đó đều nằm trong cùng một phạm vi ảnh hưởng sự cố (failure domain), bất kể nó nằm ở thư mục nào.

Một bản sao lưu là một bản sao tách biệt về không gian, tách biệt về thời gian và tách biệt về quyền kiểm soát. Tách biệt về không gian để một vụ hỏa hoạn hay một vụ tịch thu không cuốn đi cả hai. Tách biệt về thời gian để bạn có thể quay lại thời điểm trước khi hư hại xảy ra, thay vì chỉ có một bản sao trung thực của chính sự hư hại đó. Tách biệt về quyền kiểm soát để những thông tin xác thực bị đánh cắp từ cỗ máy đang chạy không thể chạm tới nó. Thiếu bất kỳ một trong ba điều đó là một tính năng tiện lợi khoác lên mình chiếc áo của một bản sao lưu.

Quy tắc 3-2-1, và phiên bản sống sót được tới 2026

Quy tắc cũ là ba bản sao của dữ liệu, trên hai loại lưu trữ khác nhau, với một bản trong số đó là offsite. Quy tắc này vẫn còn giá trị theo thời gian vì bản chất nó là một quy tắc về sự cố không tương quan với nhau, chứ không phải về băng từ. Kể từ đó có thêm hai điều bổ sung đã chứng minh được chỗ đứng của mình, và cả hai đều xuất hiện vì những chuyện hồi đó chưa phổ biến khi quy tắc này được viết ra.

• Ba bản sao. Dữ liệu đang chạy, cộng thêm hai bản nữa. Hai bản sao nghĩa là chỉ còn cách một điểm lỗi duy nhất (single point of failure) đúng một sự cố nữa, và các điểm lỗi duy nhất luôn có cách tự hỏng đúng vào lúc bạn vẫn còn đang định sửa cái đầu tiên.
• Hai loại lưu trữ. Phần cứng khác nhau, phần mềm khác nhau, và lý tưởng nhất là một nhà cung cấp khác nhau. Hai volume trên cùng một host dùng chung một hypervisor, một control panel và một tài khoản — nghĩa là chúng cũng dùng chung mọi cách mà một tài khoản có thể bị mất.
• Một bản offsite. Đặt ở một nơi khác về mặt vật lý, trên hạ tầng không sập cùng lúc với hạ tầng của bạn. Đây là bản sao có ý nghĩa khi xảy ra hỏa hoạn, trộm cắp, tịch thu, hay một tài khoản bị đóng mà không báo trước.
• Một bản bất biến hoặc ngoại tuyến. Ransomware và một root bị xâm nhập đều tìm bản sao lưu trước tiên, và một đích mà server của bạn có thể ghi vào cũng chính là một đích mà server của bạn có thể xóa sạch. Thông tin xác thực chỉ-ghi-thêm (append-only) hoặc một thiết kế kiểu kéo (pull) biến điều đó từ một thảm họa thành một chuyện phiền toái.
• Không bản khôi phục nào chưa được kiểm chứng. Một bản sao lưu mà bạn chưa từng khôi phục thử chỉ là một giả thuyết. Đây là điều người ta bỏ qua nhiều nhất và hối hận nặng nề nhất, vì một tác vụ sao lưu đã báo thành công suốt hai năm hoàn toàn có thể đã âm thầm ghi ra những archive không dùng được suốt hai năm đó.

Cần sao lưu cái gì: trạng thái (state), không phải cả cỗ máy

Bản năng đầu tiên là tạo image toàn bộ server. Đó thường là hình dạng sai: các bản sao lưu image nặng, chậm, khó khôi phục có chọn lọc, và phần lớn những gì chúng chứa chỉ là một hệ điều hành nguyên bản mà bạn có thể cài lại trong một phút. Thứ bạn không thể tái tạo lại được chính là trạng thái (state) — những thứ chỉ tồn tại vì chính những gì bạn đã làm.

• Database, dump ra chứ không copy trực tiếp. Một file database đang chạy bị copy ngay trong lúc engine đang ghi là một file bị rách (torn file) — có thể khôi phục được, có thể khôi phục sai, và sẽ không có cách nào cho bạn biết là trường hợp nào. Hãy dùng công cụ dump riêng của engine, hoặc dừng service lại, hoặc chụp một filesystem snapshot rồi dump từ đó.
• Thư mục dữ liệu ứng dụng. File đã upload, media, các asset được tạo ra tự động — cây thư mục file mà một database trỏ tới. Nó phải được chụp lại đúng cùng một thời điểm với database của nó, nếu không bạn sẽ khôi phục một chỉ mục mô tả những file thực ra không hề tồn tại.
• Cấu hình và những thứ bạn từng chỉnh tay. Cấu hình web server và reverse proxy, các unit systemd, các mục cron, quy tắc firewall, và hai mươi lần sửa lặt vặt bạn từng làm lúc hai giờ sáng mà giờ chẳng còn nhớ nổi.
• Secret và key, xử lý riêng và cẩn thận hơn. Chứng chỉ TLS cùng private key của chúng, SSH host key, API token, và trên hết là file ví cùng seed. Những thứ này xứng đáng có một bản sao mã hóa riêng, không chỉ nằm trên một cỗ máy đi thuê.
• Định nghĩa container và volume. Các file compose và file environment, cộng với các named volume — đây chính là phần người ta hay quên, vì bản thân các container thì tái tạo lại dễ như trở bàn tay, còn volume của chúng thì không.
• Danh sách những gì đã cài đặt, chứ không phải bản thân việc cài đặt. Một bản kiểm kê ngắn gọn về package, phiên bản và thứ gì chạy ở đâu sẽ khôi phục nhanh hơn và nhỏ gọn hơn nhiều so với một image của toàn bộ root filesystem.

Ranh giới ở đây rất đơn giản: nếu bạn có thể tái tạo lại nó từ một script hay một package manager trong mười phút, đừng sao lưu nó — chỉ cần ghi lại cách làm. Nếu nó chỉ tồn tại vì một điều gì đó bạn hoặc một người dùng đã làm, nó cần một bản sao. Nguyên tắc đó áp dụng từ một site nhỏ, qua một instance BTCPay, nơi ví và database là tất cả còn phần còn lại thì cài lại được, cho tới một server Nextcloud, nơi cây thư mục file và database của nó phải được chụp lại cùng nhau, nếu không thì chẳng cái nào còn giá trị mấy.

Định cỡ đích lưu trữ, và nó thực sự tốn bao nhiêu

Người ta thường ước lượng sai khoản này khá nặng, thường bằng cách định giá theo bản sao đầy đủ đầu tiên rồi nhân lên theo số ngày định giữ lại. Một công cụ sao lưu hiện đại không hoạt động theo kiểu đó. Nó chia dữ liệu thành các khối (chunk), lưu mỗi khối duy nhất đúng một lần, và nén những gì nén được — nên snapshot thứ hai của một server gần như không thay đổi gì sẽ gần như không tốn thêm dung lượng, và ba mươi snapshot mỗi ngày còn lâu mới tốn bằng ba mươi lần dung lượng của bản đầu tiên.

• Hãy dự trù dung lượng xấp xỉ kích thước trạng thái đang chạy của bạn, cộng thêm ba mươi tới năm mươi phần trăm cho lịch sử phiên bản, với một chính sách retention điển hình trên một server thay đổi ở tốc độ bình thường.
• Retention (thời gian giữ lại) mới là thứ quyết định mức tăng dung lượng, chứ không phải tần suất sao lưu. Snapshot theo giờ giữ trong hai ngày rẻ hơn snapshot theo ngày giữ trong ba năm. Hãy quyết định bạn thực sự cần quay lại xa tới đâu trong quá khứ, rồi prune tự động về đúng mốc đó.
• Dữ liệu đã nén rồi thì không nén thêm được nữa. Video, ảnh, archive và các blob đã mã hóa gần như giữ nguyên kích thước gốc, nên một server nặng về media cần dung lượng thật sự chứ không phải các thiết lập khôn khéo.
• Database khử trùng lặp (dedupe) kém giữa các lần dump, vì một bản dump đã nén của một database chỉ khác đi một chút cũng tạo ra một luồng byte hoàn toàn khác. Hãy dump ở dạng chưa nén và để công cụ sao lưu tự xử lý việc nén, chi phí lưu trữ của bạn sẽ giảm mạnh.
• Lượt upload đầu tiên là phần chậm duy nhất. Sau đó mỗi lượt chạy hằng đêm chỉ chuyển phần delta, thường chỉ vài megabyte trên hầu hết các server. Băng thông truyền tải ở đây là unmetered, nên lượt đầu tiên đó là câu hỏi về sự kiên nhẫn chứ không phải về ngân sách.

Trong thực tế, đây là khoản bảo hiểm rẻ nhất trong toàn bộ stack của bạn. Một máy chủ storage khởi điểm $7.99/mo cho 1 TB trên RAID-6, nhiều hơn hẳn dung lượng mà trạng thái của một vài instance VPS sẽ chiếm dụng, còn STO-2 giá $12.99/mo cho gấp đôi con số đó. Thư viện media và thời gian giữ lại dài chính là nơi dung lượng thực sự quan trọng: STO-4 giá $22.99/mo cho bạn 4 TB, STO-8 giá $39.99/mo cho bạn 8 TB. Đích lưu trữ này nói được rsync, SFTP và một API tương thích S3, nên mọi công cụ sao lưu phổ biến đều làm việc được với nó mà không cần plugin, và các volume được mã hóa AES-256 khi lưu trữ (at rest), hỗ trợ tự mang khóa riêng (bring-your-own key) — dù như phần tiếp theo sẽ lập luận, bạn vẫn nên mã hóa trước khi dữ liệu rời khỏi nguồn.

Chọn công cụ, và mỗi công cụ thực sự dùng để làm gì

Không cần phải đau đầu quá mức ở đây. Ba công cụ bao phủ gần như mọi trường hợp, cả ba đều miễn phí, và sự khác biệt giữa chúng với nhau ít quan trọng hơn nhiều so với sự khác biệt giữa có và không có một công cụ nào cả. Hãy chọn theo hình dạng bài toán của bạn, chứ không phải theo benchmark.

• restic — lựa chọn mặc định được khuyên dùng cho hầu hết các server. Mã hóa phía client, tự khử trùng lặp, một binary tĩnh duy nhất không cần daemon, và ghi thẳng vào SFTP, các endpoint tương thích S3 và cả thư mục thường. Chế độ chỉ-ghi-thêm (append-only) của nó là con đường dễ nhất để có một đích mà một server bị xâm nhập không thể xóa sạch.
• BorgBackup — khử trùng lặp và nén cực tốt, rất hiệu quả trên các đường truyền chậm, đã trưởng thành và được kiểm chứng qua thời gian dài. Nó cần agent riêng của mình có sẵn tại đích đến cho các repository từ xa, một ràng buộc nhỏ để đổi lấy việc nhẹ hơn hẳn về dung lượng lưu trữ.
• rclone — công cụ đúng đắn khi công việc thực chất là di chuyển dữ liệu giữa các object store, hoặc khi bạn muốn một bản mirror thay vì một lịch sử theo phiên bản. Hãy kết hợp nó với lớp crypt riêng nếu bạn dùng trực tiếp, và nhớ rằng một lần sync thuần túy sẽ lan truyền cả các lượt xóa.
• Luôn dùng công cụ dump gốc cho database. mysqldump, pg_dump và các công cụ tương đương tạo ra một bản sao logic nhất quán mà chính engine chắc chắn đọc lại được. Dump ra một file, rồi để restic hay Borg lấy file đó — đừng cố thay thế việc dump bằng một kiểu copy file khôn khéo nào đó.
• Snapshot của nhà cung cấp chỉ nên dùng như một lớp cục bộ nhanh. Hãy chụp chúng để rollback nhanh quanh những lần nâng cấp rủi ro, và đừng bao giờ tính chúng là một trong ba bản sao của bạn.

Từng bước: một hệ thống sao lưu mã hóa hoạt động được trong một buổi

1. 01Triển khai đích lưu trữ và khóa chặt nó lạiMột máy chủ storage ở một khu vực khác với các server mà nó bảo vệ. SSH chỉ dùng khóa, user riêng của chính nó, và không tái sử dụng thông tin xác thực từ các cỗ máy sẽ ghi vào nó.
2. 02Chốt danh sách trạng thái trước khi đụng vào bất kỳ công cụ nàoGhi lại mọi đường dẫn và mọi database cần phải sống sót. Mười phút với một file text ngay bây giờ sẽ giúp bạn tránh khỏi lần khôi phục mà bạn phát hiện ra có một thư mục chẳng ai liệt kê.
3. 03Khởi tạo một repository đã mã hóaTạo một mật khẩu repository thật mạnh, khởi tạo repo qua SFTP hoặc S3, và lưu mật khẩu đó ở một nơi không phải chính server đang được sao lưu. Một repository mà khóa của nó chỉ tồn tại trên cỗ máy đã chết thì không thể khôi phục được.
4. 04Dump database trước, rồi mới archiveMột wrapper script dump từng database vào một thư mục staging, rồi chạy một lượt sao lưu duy nhất qua cả các bản dump lẫn cây thư mục file. Chính thứ tự đó khiến database và các file của nó nhất quán với nhau.
5. 05Chạy lượt sao lưu đầu tiên và theo dõi tới khi xongLượt đầu tiên là lượt lâu nhất. Hãy chạy nó trong một terminal multiplexer để một kết nối bị rớt không làm chết tiến trình, và ghi lại thời gian nó mất — giờ bạn cũng đã biết luôn khoảng thời gian cần cho một lần khôi phục.
6. 06Đặt retention và prune tự độngMột cấu hình kiểu bảy bản hằng ngày, bốn bản hằng tuần và sáu bản hằng tháng phù hợp với hầu hết các server. Hãy cấu hình prune ngay trong cùng tác vụ đó, nếu không repository sẽ phình to cho tới ngày nó ngừng hoạt động.
7. 07Lên lịch cho nó, rồi làm cho thất bại phải kêu toMột timer hằng đêm hoặc một mục cron, cộng thêm một cảnh báo khi tác vụ không báo cáo thành công. Một tác vụ sao lưu im lặng không khác gì việc không có tác vụ sao lưu nào cả, cho tới tận khi bạn nhận ra — dù mất bao nhiêu tháng đi nữa.
8. 08Khôi phục thử thứ gì đó ngay hôm nay, từ bản sao lưu, trên một cỗ máy khácKhông phải chỉ liệt kê nội dung archive — mà là một lần khôi phục thật sự của một file thật và một database thật lên một server nháp. Chừng nào bạn chưa từng làm việc này một lần, bạn mới chỉ có một script sao lưu, chứ chưa có một bản sao lưu.

Làm sao để bản sao sống sót qua chính thứ đã giết chết server

Đây là phần phân biệt giữa một bản sao lưu thật sự và một thứ chỉ gây phiền toái đôi chút cho kẻ tấn công. Nếu server giữ thông tin xác thực có thể xóa được các bản sao lưu, thì một root bị xâm nhập, một đợt ransomware, hay một script lỗi sẽ chạm tới cả hai bản sao trong cùng một phút. Cách khắc phục nằm ở cấu trúc, không phải ở việc dùng mật khẩu mạnh hơn.

• Dùng thông tin xác thực chỉ-ghi-thêm (append-only) từ phía nguồn. restic và Borg đều hỗ trợ một chế độ mà cỗ máy đang ghi có thể tạo snapshot mới nhưng không thể xóa hay prune những snapshot đã có. Việc prune khi đó sẽ chạy từ một nơi khác, theo lịch, với một khóa riêng.
• Ưu tiên thiết kế kiểu kéo (pull) bất cứ khi nào có thể. Một đích chủ động vươn vào nguồn để lấy dữ liệu, thay vì nguồn chủ động đẩy dữ liệu đi, nghĩa là nguồn không bao giờ giữ thông tin xác thực tới archive đó cả.
• Đừng bao giờ tái sử dụng SSH key hay mật khẩu repository giữa các server. Một cỗ máy bị xâm nhập chỉ nên khiến bạn mất bản sao lưu của đúng cỗ máy đó, chứ không phải toàn bộ hệ thống.
• Hãy giữ ít nhất một bản sao ở một khu vực pháp lý khác và một phạm vi ảnh hưởng sự cố khác. Đa dạng hóa khu vực không phải là hoang tưởng — đó là ranh giới giữa một sự cố phần cứng và một tổn thất toàn phần.
• Lưu khóa repository hoàn toàn bên ngoài hạ tầng. Một password manager, một hardware token, giấy viết tay cất trong két sắt. Bất cứ đâu, miễn không phải là những cỗ máy mà repository đó đang bảo vệ.
• Cảnh giác với những lần sao lưu bỗng nhiên thành công nhanh một cách đáng ngờ. Một tác vụ từng mất hai mươi phút mà giờ chỉ còn bốn mươi giây thường là đang sao lưu một thư mục trống hoặc chưa được mount, và nó vẫn sẽ tiếp tục báo cáo thành công trong lúc làm điều đó.

Việc chọn khu vực ở đây là một quyết định thực sự chứ không phải một chi tiết vặt vãnh, vì bản sao lưu và server production của bạn không nên bị tịch thu cùng trong một hành động duy nhất. Nếu điều đó quan trọng với những gì bạn đang chạy, chọn vị trí một cách có chủ đích đáng để bỏ ra vài phút, và đặt đích lưu trữ vào một chế độ pháp lý khác với nguồn chính là mục đích của cả việc này.

Khôi phục: phần mà chẳng ai từng diễn tập

Các lần khôi phục thất bại vì những lý do rất tầm thường, và chúng thất bại đúng vào thời điểm tồi tệ nhất vì đó là lúc duy nhất hầu hết mọi người thực sự thử khôi phục. Mọi thất bại dưới đây đều được phát hiện trong vài phút nếu diễn tập trước, và trong vài giờ nếu để tới lúc sự cố thật sự xảy ra.

• Mật khẩu repository chỉ tồn tại trên chính server đã chết, nên các archive vẫn còn nguyên vẹn nhưng không thể đọc được vĩnh viễn.
• Database khôi phục thành công nhưng cây thư mục file lại lấy từ một lượt chạy sau đó ba tiếng, nên ứng dụng hiển thị các bản ghi có file không hề tồn tại.
• Bản sao lưu chụp lại một thư mục đã âm thầm ngừng được mount, nên nó cứ trung thành archive một thư mục trống suốt mỗi đêm trong cả một năm trời.
• Không ai biết thứ tự khôi phục đúng — database trước hay file trước, service dừng hay vẫn đang chạy — và trạng thái khôi phục dở dang đó phải bị bỏ đi để làm lại từ đầu.
• Việc khôi phục mất tới mười một tiếng qua đường truyền hiện có, một con số chưa ai từng đo thử, trong khi kế hoạch phục hồi lại mặc định là chỉ mất có một tiếng.
• Quyền sở hữu và permission của file khôi phục lại sai, nên mọi thứ đều có mặt đầy đủ nhưng ứng dụng lại từ chối khởi động.
• Chỉ có snapshot mới nhất từng được kiểm thử, trong khi lỗi hỏng dữ liệu cần phục hồi lại đã bắt đầu từ sáu tuần trước.

Diễn tập hai lần một năm giải quyết được toàn bộ chuyện đó. Hãy triển khai một VPS dùng một lần, khôi phục vào đó từ repository thật, khởi động service, nhìn vào dữ liệu, rồi hủy cỗ máy đó đi. Nó tốn vài đô la và một tiếng đồng hồ, và nó biến toàn bộ hệ thống sao lưu từ một niềm tin thành một sự thật đã kiểm chứng. Hãy làm việc đó ít nhất một lần với runbook mở sẵn trước mặt, và sửa lại runbook ở bất cứ chỗ nào nó từng nói dối bạn.

Lớp riêng tư: một bản sao lưu có thể xóa sạch tính ẩn danh của bạn

Phần này riêng cho việc chạy offshore, và chỉ dễ làm đúng nếu bạn nghĩ tới nó trước lượt upload đầu tiên, chứ không phải sau đó. Một bản sao lưu là một bản sao đầy đủ, có lập chỉ mục, sống lâu dài của toàn bộ hạ tầng của bạn, nằm ở một nơi khác — điều đó khiến nó nhạy cảm y hệt bản gốc, và dễ bị quên mất hơn nhiều.

• Tên file và cấu trúc thư mục vẫn là metadata ngay cả khi nội dung đã được mã hóa. Mã hóa phía client trong restic và Borg che luôn cả tên file; một bản mirror rsync thuần túy thì không, và chỉ riêng một danh sách thư mục thôi cũng thường đủ để nhận diện server đó là gì và ai đang vận hành nó.
• Tài khoản ở đích lưu trữ cũng là một phần của câu chuyện. Một vault sao lưu được thuê bằng thẻ mang tên thật của bạn sẽ gắn cái tên đó với mọi thứ vault đó chứa, bất kể cỗ máy nguồn đã được giữ sạch cẩn thận tới đâu.
• Lưu lượng sao lưu là một kết nối bền bỉ, theo lịch, khối lượng lớn giữa hai địa chỉ. Đó là một trong những kiểu mẫu (pattern) dễ đọc nhất mà một server tạo ra, và nó chỉ thẳng vào đích lưu trữ mỗi đêm.
• Các snapshot cũ sống lâu hơn cả những quyết định đã tạo ra chúng. Thứ gì đó bạn đã ngừng lưu trữ từ một năm trước vẫn còn trong archive nếu retention chưa từng prune nó đi, một đặc tính tốt cho việc phục hồi nhưng lại tệ cho việc lộ thông tin.
• Log và lịch sử shell bị cuốn theo cùng mọi thứ khác. Archive đó thường xuyên chứa cả các địa chỉ IP, câu lệnh và thông tin xác thực mà bạn từng cẩn thận giữ kín trên cỗ máy đang chạy.

Cách khắc phục đều rất bình thường. Hãy dùng một công cụ mã hóa cả tên file lẫn nội dung. Thuê đích lưu trữ theo đúng cách bạn đã thuê nguồn — từ một host chưa từng hỏi bạn là ai, nạp tiền từ một số dư tiền mã hóa, kèm theo một lần nạp Monero nếu bạn muốn khép luôn cả dấu vết thanh toán. Định tuyến việc truyền dữ liệu qua một đường hầm WireGuard nếu chính kiểu mẫu lưu lượng đó khiến bạn lo ngại. Và áp dụng đúng quy trình gia cố mười phút đầu tiên đó cho cỗ máy storage giống hệt như bạn đã áp dụng cho production, vì một cỗ máy đang giữ bản sao của mọi thứ không phải là một mục tiêu kém giá trị hơn bản gốc — mà thường còn là một mục tiêu giá trị hơn.

Những sai lầm khiến người ta mất sạch dữ liệu

• Tin tưởng RAID, snapshot hay một thư mục sync chính là bản sao lưu, rồi mới phát hiện ra chúng thực sự thuộc loại nào đúng vào cái ngày điều đó thực sự quan trọng.
• Giữ bản sao duy nhất trên cùng server, cùng tài khoản hay cùng nhà cung cấp với chính thứ đang được bảo vệ.
• Copy trực tiếp file database đang chạy thay vì dump nó, rồi khôi phục một archive sai một cách âm thầm, khó nhận ra.
• Sao lưu cây thư mục file và database ở hai thời điểm khác nhau, khiến chẳng cái nào khớp với cái nào khi khôi phục.
• Lưu mật khẩu repository ngay trên chính cỗ máy mà repository đó đang bảo vệ.
• Cấp cho nguồn quyền xóa toàn phần trên đích lưu trữ, để rồi một lần bị xâm nhập kéo theo luôn cả các archive.
• Không bao giờ prune, cho tới khi đích lưu trữ đầy và tác vụ hằng đêm đã âm thầm thất bại suốt nhiều tuần liền.
• Sao lưu hàng trăm gigabyte dữ liệu blockchain công khai trong khi file ví lại chẳng nằm trong bất kỳ archive nào.
• Chỉ cấu hình cảnh báo khi thất bại chứ không bao giờ cảnh báo khi vắng mặt, nên một tác vụ đã ngừng chạy hoàn toàn thì chẳng báo cáo gì cả.
• Chỉ kiểm thử snapshot mới nhất, rồi phát hiện ngay giữa một sự cố thật rằng lỗi hỏng dữ liệu đã có từ trước đó rồi.

Sao lưu là thứ ít thú vị nhất mà bạn sẽ cấu hình, và cũng là thứ duy nhất mà sự vắng mặt của nó là không thể cứu vãn. Mọi thứ khác trên một server đều có thể dựng lại được từ một package manager và một buổi chiều; trạng thái thì không. Hãy dành một buổi ngồi xuống làm cho xong: liệt kê những gì cần sống sót, dump các database, gửi một archive đã mã hóa tới một máy chủ storage ở một quốc gia khác, prune theo lịch, cảnh báo khi im lặng, và khôi phục thử thứ gì đó thật trước khi bạn đóng terminal lại. Rồi để nó yên đó. Thước đo của một hệ thống sao lưu tốt chính là việc bạn quên mất nó tồn tại — cho tới đúng buổi sáng nó biến một thảm họa thành một tiếng đồng hồ hơi phiền phức.