Cách Sao Lưu VPS: Mã Hóa, Lưu Trữ Ngoài Và Khôi Phục Được

Mọi bản sao lưu đều hoạt động tốt cho đến ngày nó thực sự cần dùng đến. Snapshot thì nằm trên chính nền tảng vừa sập. Tệp tarball chạy mỗi đêm đã âm thầm thất bại từ khi một ổ đĩa đầy hồi tháng Ba. Bản dump cơ sở dữ liệu chỉ là một bản sao file chụp giữa lúc đang ghi, và khi khôi phục thì chẳng ra được gì. Bản sao lưu là phần duy nhất của một máy chủ mà bạn không thể đánh giá bằng cách nhìn vào nó — chỉ có thể đánh giá bằng cách khôi phục nó. Đây là cách xây dựng một bản sao lưu sống sót qua sự cố phần cứng, qua chính sai lầm của bạn, và qua việc người khác nắm được thông tin đăng nhập của bạn, mà không trao một bản sao đọc được của máy chủ cho bất kỳ ai lưu trữ nó.

Bốn thứ phá hủy một máy chủ, và mỗi thứ cần một cách đối phó khác nhau

Hãy thiết kế bản sao lưu xoay quanh sự cố, không phải xoay quanh công cụ. Bốn kịch bản sau chiếm gần như toàn bộ các trường hợp mất dữ liệu thực tế, và mỗi kịch bản đòi hỏi một điều khác nhau ở bản sao bạn giữ. Một thiết lập xử lý tốt một trong số đó sẽ cảm thấy hoàn toàn đầy đủ — cho đến khi gặp phải một kịch bản khác.

Snapshot không phải là bản sao lưu

Hai từ này thường bị dùng lẫn cho nhau, trong khi chúng mô tả hai đối tượng khác nhau với phạm vi sự cố khác nhau. Biết mình đang có cái nào sẽ quyết định bạn có thực sự có gì trong tay hay không.

3-2-1, và hai con số mà ai cũng bỏ quên

Quy tắc cũ này vẫn còn giá trị vì nó mô tả tính độc lập chứ không phải một hệ thống lưu trữ đơn thuần: ba bản sao dữ liệu, trên hai loại lưu trữ khác nhau, một trong số đó đặt ở một nơi khác. Hai điều bổ sung sau đây xử lý những sự cố từng hiếm gặp vào thời quy tắc này ra đời, nhưng nay đã trở thành chuyện thường ngày.

• Ba bản sao. Dữ liệu đang chạy cộng thêm hai bản sao lưu. Chỉ có hai bản sao nghĩa là bạn chỉ cách con số không đúng một lần khôi phục thất bại.
• Hai loại phương tiện lưu trữ, hoặc hai nhà cung cấp. Trên hạ tầng đi thuê, "phương tiện lưu trữ" thực chất có nghĩa là tính độc lập về quản trị — một bản sao thứ hai dưới cùng một tài khoản, trên cùng một nền tảng, trả bằng cùng một số dư, chỉ là một bản sao duy nhất khoác thêm vài bước thừa.
• Một bản ở nơi khác. Khác tòa nhà, khác mạng, khác cả khu vực pháp lý nếu điều đó quan trọng với bạn. /locations chính là phiên bản thực tế của ý tưởng này: hãy chọn một khu vực gặp sự cố độc lập với khu vực bạn đang bảo vệ.
• Một bản bất biến hoặc ngoại tuyến. Một bản sao mà chính máy chủ không thể xóa được, bởi vì ai sở hữu máy chủ thì cũng sở hữu luôn thông tin đăng nhập của nó.
• Không bản khôi phục nào chưa được xác minh. 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. Con số có ý nghĩa là số lần bạn đã khôi phục thành công, không phải số lần tác vụ báo cáo là thành công.

Sao lưu dữ liệu, dựng lại phần còn lại

Bản năng tự nhiên là tạo image toàn bộ mọi thứ. Cách này tốn kém, khôi phục chậm, và nó bảo tồn trung thành luôn cả file binary đã bị xâm nhập, trạng thái package đang hỏng, và độ trôi cấu hình mà bạn không còn nhớ vì sao mình từng tạo ra nó. Một máy chủ chứa ba loại nội dung, và chỉ một trong số đó thực sự thuộc về bản sao lưu.

• Bao gồm /etc, /home, /root, /srv, thư mục gốc web của bạn, thư mục lưu trạng thái của ứng dụng, các named container volume, và một thư mục chứa các bản dump cơ sở dữ liệu mới nhất.
• Bao gồm cả công thức triển khai — các file compose, script Ansible hoặc shell, những ghi chú bạn viết lúc 2 giờ sáng. Hãy đưa nó vào version control nữa, nhưng cũng đặt một bản trong bản sao lưu, để việc khôi phục không bao giờ phải phụ thuộc vào khả năng truy cập được một dịch vụ thứ hai.
• Loại trừ /proc, /sys, /dev, /run và các thư mục tạm. Đây là các giao diện của kernel và không gian tạm; sao chép chúng chỉ tốn thời gian hoặc khiến tác vụ treo cứng.
• Loại trừ cache của package, thư mục build, cây dependency và virtualenv — bất cứ thứ gì một bước build có thể tạo lại được. Trên một máy chủ ứng dụng điển hình, đây chính là phần lớn dung lượng ổ đĩa.
• Loại trừ các file cơ sở dữ liệu đang chạy trực tiếp nếu bạn đã dump cơ sở dữ liệu đúng cách. Sao lưu cả hai nghĩa là bản lớn hơn, vô dụng hơn lại chính là bản mà ai đó sẽ đem ra khôi phục lúc ba giờ sáng.
• Đừng loại trừ các file ẩn. Phân nửa những gì quan trọng trên một máy Linux đều bắt đầu bằng một dấu chấm.

Cơ sở dữ liệu sẽ không sống sót qua một lần sao chép file

Đây là lý do phổ biến nhất khiến một lần khôi phục thất bại. Một cơ sở dữ liệu đang chạy giữ trạng thái trong bộ nhớ và ghi dữ liệu không theo đúng thứ tự; sao chép file của nó trong lúc đang chạy sẽ chụp lại một trạng thái bị xé lẻ, ghi dở dang — có thể khôi phục được, có thể khôi phục ra dữ liệu hỏng mà không báo lỗi, hoặc có thể không khôi phục được chút nào. Hãy tạo một bản dump đúng cách, rồi sao lưu chính bản dump đó.

• PostgreSQL: dùng pg_dump cho từng cơ sở dữ liệu, hoặc pg_dumpall cho toàn bộ cluster kể cả các role. Ở nơi mất một ngày dữ liệu là không thể chấp nhận, hãy thêm lưu trữ WAL để có thể khôi phục về đúng một thời điểm cụ thể, thay vì chỉ về được tối hôm qua.
• MySQL hoặc MariaDB: mysqldump cùng cờ --single-transaction cho ra một snapshot nhất quán trên InnoDB mà không chặn việc ghi dữ liệu. Nhưng trên MyISAM thì không — thêm một lý do nữa để không dùng MyISAM. Với tập dữ liệu lớn, một công cụ vật lý như mariabackup khôi phục nhanh hơn nhiều so với việc chạy lại một bản dump.
• SQLite: đừng bao giờ sao chép trực tiếp file. Hãy dùng lệnh .backup hoặc VACUUM INTO, vốn khóa file đúng cách. Sao chép một cơ sở dữ liệu đang có write-ahead log hoạt động chẳng khác nào một canh bạc mà sớm muộn bạn cũng cầm chắc phần thua.
• Redis: kích hoạt một lần lưu nền và sao lưu file snapshot kết quả, hoặc chạy ở chế độ chỉ-ghi-thêm (append-only) và sao lưu file log. Sao chép một snapshot đang chạy giữa lúc ghi dở sẽ cho ra một file bị cắt cụt, khi nạp lên chỉ còn là một tập dữ liệu rỗng.
• Container: volume chính là dữ liệu. Hãy dừng stack trong vài giây đủ để sao chép, hoặc chạy công cụ dump ngay bên trong container — nhưng đừng nén tar volume của một cơ sở dữ liệu đang chạy rồi gọi đó là một bản sao lưu.
• Bất cứ thứ gì khác có một tiến trình thường trực — chỉ mục tìm kiếm, message queue, các daemon sổ cái — đều có lệnh xuất dữ liệu nhất quán riêng của nó. Hãy tìm ra lệnh đó ngay từ bây giờ, đừng để tới lúc sự cố mới đi tìm.

Chọn công cụ

Bốn công cụ sau bao trùm gần như mọi trường hợp. Đặc tính quan trọng nhất cần quan tâm là mã hóa diễn ra ở đâu. Nếu dữ liệu chỉ được mã hóa trong lúc truyền đi, rồi sau đó được mã hóa ở trạng thái nghỉ bởi chính nhà cung cấp lưu trữ, thì nhà cung cấp lưu trữ đó hoàn toàn đọc được nó — và bản sao lưu đã âm thầm trở thành điểm yếu nhất trong một hệ thống mà bạn đã gia cố kỹ càng ở mọi nơi khác.

Bản sao thứ hai nên đặt ở đâu

Đích lưu trữ không chỉ là dung lượng ổ đĩa, mà còn là một khu vực pháp lý và một mối quan hệ thanh toán. Dưới đây là bốn lựa chọn, xếp theo thứ tự tương đối về mức độ độc lập của chúng so với máy chủ bạn đang bảo vệ.

Xây dựng từng bước một

1. 1

   Trước tiên, quyết định hai con số

   Bạn có thể chấp nhận mất bao nhiêu dữ liệu — chính là khoảng cách giữa hai lần chạy — và bạn có thể chịu đựng downtime bao lâu. Mọi thứ khác đều xuất phát từ hai câu trả lời đó. Sao lưu mỗi giờ cho một trang web tĩnh chỉ là hình thức; sao lưu mỗi đêm cho một cơ sở dữ liệu đơn hàng là một quyết định cần được cân nhắc có chủ đích, chứ không phải sao chép nguyên xi từ một bài hướng dẫn nào đó.

2. 2

   Tạo đích lưu trữ

   Một instance thứ hai ở khu vực khác, với khóa SSH riêng và một user không có quyền hạn đặc biệt, chuyên dụng chỉ để làm home cho repository. Không chạy gì khác ở đó. Hãy giới hạn khóa này chỉ cho chạy đúng một lệnh bắt buộc, để một thông tin đăng nhập bị đánh cắp cũng chỉ có thể ghi thêm bản sao lưu, không bao giờ mở được shell.

3. 3

   Tạo khóa và lưu nó ở nơi khác

   Một cụm mật khẩu dài và ngẫu nhiên, được ghi lại ở một nơi vẫn còn tồn tại kể cả khi mất máy chủ. Khởi tạo repository, rồi tự chứng minh rằng bạn có thể liệt kê nội dung của nó từ một máy thứ ba, chỉ dựa vào những gì bạn đã ghi lại. Nếu không làm được, hãy khắc phục điều đó trước khi ghi bất kỳ bản sao lưu nào.

4. 4

   Dump cơ sở dữ liệu trước tiên

   Một script ngắn ghi các bản dump nhất quán vào một thư mục trung gian, và thoát với mã khác 0 nếu bất kỳ bản nào thất bại — chạy trước bước sao lưu file, chứ không chạy song song với nó. Một tác vụ vẫn tiếp tục chạy sau khi dump thất bại chính là cách người ta kết thúc với ba mươi ngày liền toàn file 0 byte.

5. 5

   Sao lưu các đường dẫn quan trọng

   Trỏ công cụ vào danh sách các đường dẫn cần bao gồm, áp dụng các loại trừ, rồi kiểm tra lại tính hợp lý của lần chạy đầu tiên. Nếu một repository mới tạo từ một máy chủ 40 GB mà chỉ ra 300 MB, có thứ gì đó đang bị bỏ sót một cách âm thầm; nếu nó ra tới 38 GB, các quy tắc loại trừ của bạn không hoạt động.

6. 6

   Lên lịch chạy, và làm cho thất bại phải ồn ào

   Một timer của systemd với độ trễ ngẫu nhiên, hoặc cron nếu đó là thói quen của bạn. Sau đó hãy để tác vụ tự báo cáo: gửi tín hiệu heartbeat về một hệ thống giám sát mỗi khi thành công, và bắn cảnh báo khi tín hiệu heartbeat ngừng đến. Thất bại âm thầm chính là kiểu thất bại bình thường nhất của các bản sao lưu, bởi vì không có gì trông có vẻ hỏng hóc khi chúng ngừng chạy — cho tới khi mọi thứ đều hỏng.

7. 7

   Thiết lập thời gian lưu giữ, và thực sự chạy prune

   Theo giờ trong một ngày, theo ngày trong hai tuần, theo tuần trong vài tháng, theo tháng trong một năm. Sau đó hãy chạy prune và xác nhận repository ngừng phình to. Một chính sách lưu giữ chỉ được cấu hình nhưng chưa bao giờ thực thi sẽ khiến đích lưu trữ đầy tràn, và kéo theo cả các bản sao lưu sụp đổ cùng nó.

8. 8

   Khôi phục thử một thứ gì đó ngay hôm nay

   Không phải một tác vụ kiểm thử suông — mà là một file thật, khôi phục vào một thư mục tạm, mở ra và kiểm tra hẳn hoi. Sau đó hãy đặt một ngày cụ thể trên lịch để khôi phục thử toàn bộ máy chủ. Lần khôi phục toàn bộ đầu tiên luôn luôn làm lộ ra điều gì đó: một đường dẫn bị thiếu, một quyền truy cập, một chứng chỉ, một user cơ sở dữ liệu chỉ từng tồn tại trên máy cũ.

Thời gian lưu giữ, và vì sao giữ lâu hơn lại rẻ hơn bạn tưởng

Thời gian lưu giữ thường được đặt theo bất cứ mức nào vừa với ổ đĩa, rồi bị bỏ quên luôn từ đó. Nó xứng đáng được suy nghĩ một cách có chủ đích, vì chính nó quyết định sai lầm nào có thể cứu vãn được. Một khoảng lưu giữ bảy ngày bắt được một file bị xóa vào thứ Ba. Nhưng nó không bắt được một sự cố hỏng dữ liệu đã bắt đầu từ sáu tuần trước và chỉ lộ ra khi một báo cáo cho ra kết quả sai, hay một kẻ xâm nhập đã âm thầm nằm vùng trên máy cả tháng trời trước khi ra tay.

Khử trùng lặp khiến tất cả những điều này rẻ hơn nhiều so với những gì bảng trên gợi ý: lần chạy thứ hai trên một máy chủ gần như không thay đổi chỉ lưu lại đúng phần đã thay đổi, nên một năm các điểm khôi phục hằng tháng trên một máy 40 GB thường chỉ tốn vài gigabyte, thay vì nửa terabyte. Hãy đặt chính sách dựa trên những gì bạn thực sự cần khôi phục, rồi mới kiểm tra hóa đơn. Bạn sẽ thường thấy mình hoàn toàn có thể chi trả cho phiên bản rộng rãi hơn.

Tính bất biến: phần ngăn chặn ransomware

Mọi điều nói ở trên đều giả định đối thủ của bạn chỉ là sự ngẫu nhiên của rủi ro tự nhiên. Nhưng nếu đối thủ là một con người nắm quyền root, một tác vụ sao lưu thông thường chẳng khác nào một cuốn hướng dẫn sử dụng — thông tin đăng nhập nằm ngay trên máy, đích lưu trữ nằm ngay trong cấu hình, và repository sẽ bị xóa sạch trước khi quá trình mã hóa tống tiền kịp bắt đầu. Bốn cơ chế sau đây phá vỡ chuỗi đó, và chỉ cần một trong số chúng cũng đủ thay đổi kết cục.

• Repository chỉ-ghi-thêm (append-only). Chế độ append-only phía server của Borg, hoặc REST server của restic ở chế độ append-only, đều chấp nhận dữ liệu mới nhưng từ chối mọi yêu cầu xóa. Máy chủ chỉ có thể ghi; chỉ có bạn, từ một nơi khác, mới có thể chạy prune.
• Sao lưu theo mô hình kéo (pull). Host sao lưu là bên chủ động khởi tạo kết nối, và cũng là bên duy nhất giữ thông tin đăng nhập. Máy chủ production không có khóa, không có địa chỉ đích, và hoàn toàn không có đường nào tới repository.
• Khóa đối tượng (object lock). Storage tương thích S3 với một khoảng thời gian lưu giữ được áp đặt ngay ở cấp bucket, nơi việc xóa bị chính tầng lưu trữ từ chối, bất kể thông tin đăng nhập kia có được phép làm gì đi nữa.
• Thông tin đăng nhập riêng cho từng host. Một cỗ máy bị xâm nhập không nên kéo theo lịch sử của mọi cỗ máy khác. Khóa riêng, đường dẫn riêng, giới hạn riêng.
• Một bản sao thực sự ngoại tuyến. Một ổ đĩa đã rút phích cắm thì miễn nhiễm với mọi cuộc tấn công từ xa từng được viết ra. Không thời thượng, nhưng chưa từng bị đánh bại.

Bài diễn tập khôi phục

Khôi phục là một quy trình, mà một quy trình chưa ai từng thực hiện thì chỉ là chuyện hư cấu. Hãy chạy diễn tập này một lần ngay bây giờ, rồi lặp lại mỗi sáu tháng một lần, và ghi lại những gì bạn học được — những ghi chú đó rốt cuộc sẽ có giá trị chẳng kém gì bản thân dữ liệu.

1. 1

   Triển khai một instance trắng

   Cùng phiên bản hệ điều hành, không cài thêm gì khác. Một VPS tồn tại trong thời gian ngắn là đủ, và toàn bộ bài tập này tốn ít tiền hơn một bữa trưa.

2. 2

   Khôi phục chỉ bằng những gì bạn đã ghi lại

   Địa chỉ repository, cụm mật khẩu, các lệnh cần chạy. Nếu bạn cần một thứ gì đó chỉ tồn tại trên máy chủ mà bạn đang giả định là đã chết, thì bạn vừa tìm ra một lỗ hổng — đúng vào một ngày mà việc tìm ra nó không tốn kém gì cả.

3. 3

   Đưa dữ liệu trở lại trước khi khởi động ứng dụng

   Nạp bản dump cơ sở dữ liệu, đặt các file về đúng vị trí của chúng, rồi sửa lại quyền sở hữu và mode. Quyền sở hữu thường là điều bất ngờ nhất: các user ID dạng số từ máy cũ hiếm khi khớp với máy mới.

4. 4

   Khởi động dịch vụ và thực sự sử dụng nó

   Không phải chỉ chạy một lệnh kiểm tra trạng thái — mà hãy đăng nhập, tải một trang, chạy một truy vấn, gửi một tin nhắn. Một dịch vụ khởi động được không đồng nghĩa với một dịch vụ hoạt động được.

5. 5

   Đo thời gian, và ghi lại con số đó

   Toàn bộ quá trình mất bao lâu? Đó chính là thời gian khôi phục thực tế của bạn, và nó gần như luôn luôn dài gấp nhiều lần so với ước tính ban đầu. Hãy giữ ghi chú này bên cạnh cụm mật khẩu, và cập nhật cả hai mỗi khi stack có thay đổi.

Chi phí thực sự là bao nhiêu

Sao lưu là khoản bảo hiểm rẻ nhất trong toàn bộ hạ tầng, vậy mà lại thường xuyên bị bỏ qua vì lý do giá cả. Dưới đây là vài con số cụ thể cho một máy chủ nhỏ, giả định dữ liệu nén và khử trùng lặp giống như dữ liệu thông thường vẫn vậy.

Hãy so bất kỳ con số nào ở trên với cái giá của một sự cố downtime mà chúng ngăn chặn được. Việc gọi tên con số cụ thể mới chính là điểm mấu chốt — lập luận phản đối việc sao lưu chưa bao giờ thực sự là về tiền bạc, một khi con số đã được viết ra rõ ràng.

Vai trò của nhà cung cấp trong bức tranh này

Một kế hoạch sao lưu phụ thuộc vào đúng hai thứ giống như máy chủ mà nó đang bảo vệ: một nơi độc lập để đặt bản sao, và một cách thanh toán không tạo thêm một hồ sơ mới ghi lại bạn là ai. Cả hai điều này còn quan trọng hơn ở đây so với ở máy chủ gốc, bởi vì bản sao lưu là một bản sao chép đầy đủ của mọi thứ mà máy chủ gốc đang bảo vệ.

Mọi gói /vps và /storage tại đây đều được triển khai từ một số dư tiền mã hóa trả trước, không yêu cầu KYC, trải khắp mười lăm khu vực được liệt kê tại /locations — nên bản sao thứ hai có thể đặt dưới một khu vực pháp lý khác với bản đầu tiên, mà không cần thêm bất kỳ bước xác minh danh tính nào trong toàn bộ chuỗi. Snapshot tức thì được bao gồm sẵn trên mọi instance để hoàn tác trong năm giây, băng thông không giới hạn nghĩa là cả lần tải lên đầu tiên lẫn lần khôi phục khẩn cấp đều không phải một sự kiện bị tính phí theo dung lượng, và /storage bổ sung ổ đĩa cấp terabyte được bảo vệ bằng RAID từ $8.99/mo mà không kiểm duyệt nội dung. /pay-with liệt kê các loại coin được chấp nhận, /offshore-hosting trình bày rõ khu vực pháp lý thực sự thay đổi được điều gì, và /guides có các bài viết liên quan về mã hóa ổ đĩa và về những gì một nhà cung cấp có thể và không thể nhìn thấy về một cỗ máy.

Danh sách kiểm tra

• Gọi tên rõ sự cố bạn đang phòng vệ trước khi chọn công cụ.
• Xem snapshot như một nút hoàn tác, không bao giờ xem nó là bản sao lưu.
• Sao lưu dữ liệu và cấu hình; dựng lại hệ điều hành bằng một script.
• Dump mọi cơ sở dữ liệu bằng đúng lệnh xuất dữ liệu nhất quán của riêng nó, và sao lưu chính bản dump đó.
• Mã hóa ngay phía client, trước khi bất cứ thứ gì rời khỏi máy.
• Giữ cụm mật khẩu của repository ở một nơi vẫn còn tồn tại kể cả khi mất máy chủ.
• Đặt ít nhất một bản sao dưới một nhà cung cấp, khu vực và phương thức thanh toán khác.
• Biến ít nhất một bản sao thành append-only, theo mô hình pull, hoặc ngoại tuyến, để một quyền root bị xâm nhập không thể xóa được nó.
• Bắn cảnh báo khi thiếu vắng một lần chạy thành công — thất bại vốn âm thầm, và chính sự im lặng đó là dấu hiệu.
• Khôi phục thử một file ngay hôm nay, và khôi phục thử toàn bộ máy chủ hai lần mỗi năm. Đo thời gian và ghi lại con số đó.