Backup báo thành công mỗi đêm nhưng khôi phục thất bại: những nguyên nhân thường gặp

Có một kiểu sự cố đặc biệt khó chịu vì nó đến sau khi mọi thứ trông đều ổn. Bảng điều khiển 백업 xanh suốt sáu tháng, báo cáo hàng tuần không có mục nào màu đỏ, dung lượng lưu trữ tăng đều đặn đúng như dự kiến. Rồi một ngày có sự cố thật, đội vận hành mở bản sao gần nhất ra, và không khôi phục được.

Nguyên nhân gốc gần như luôn giống nhau: hệ thống sao lưu đang đo một thứ, còn bạn cần một thứ khác. Nó đo xem tác vụ có chạy hết mà không gặp lỗi hay không. Bạn cần biết dữ liệu bên trong có dùng được hay không. Hai câu hỏi này chỉ trùng nhau khi mọi điều kiện xung quanh đều thuận lợi, và trong sự cố thật thì hiếm khi có điều kiện nào thuận lợi.

Trạng thái thành công thực sự nói lên điều gì

Với hầu hết phần mềm sao lưu, trạng thái thành công có nghĩa là danh sách nguồn đã được đọc, dữ liệu đã được ghi ra đích, và tiến trình kết thúc với mã trả về bình thường. Đó là một thông tin có giá trị, nhưng nó không nói gì về việc dữ liệu đã ghi có nhất quán về mặt logic hay không, có đọc lại được hay không, có đủ để dựng lại một hệ thống hoạt động hay không.

Nói cách khác, tác vụ sao lưu xác nhận rằng một hành động sao chép đã diễn ra. Chỉ có một lần khôi phục thật mới xác nhận rằng khả năng phục hồi đang tồn tại. Dưới đây là những nguyên nhân thường gặp khiến khoảng cách giữa hai điều đó lộ ra đúng lúc tệ nhất.

Bản sao không nhất quán ở tầng ứng dụng

Đây là nguyên nhân phổ biến nhất với cơ sở dữ liệu và các ứng dụng có trạng thái. Khi bạn sao lưu ở mức tệp hoặc mức khối trong lúc ứng dụng vẫn đang ghi, kết quả có thể là một tập hợp các tệp thuộc về nhiều thời điểm khác nhau. Một phần nhật ký giao dịch mới hơn phần dữ liệu, hoặc ngược lại. Tệp trên đĩa vẫn đầy đủ, kích thước vẫn đúng, tác vụ vẫn báo thành công. Nhưng khi ứng dụng khởi động lại từ tập tệp đó, nó phát hiện trạng thái không thể dung hòa và từ chối mở.

Điều khiến trường hợp này nguy hiểm là nó không sinh ra lỗi ở phía sao lưu. Vấn đề chỉ tồn tại ở tầng ứng dụng, nơi hệ thống sao lưu không nhìn vào. Cách xử lý là dùng cơ chế sao lưu nhận biết ứng dụng, tức là phối hợp với ứng dụng để đưa nó về trạng thái nhất quán trước khi chụp, hoặc dùng công cụ sao lưu gốc của chính hệ quản trị dữ liệu đó. Và dù chọn cách nào, vẫn phải kiểm chứng bằng cách mở thật.

Phương tiện và bản sao chưa bao giờ được kiểm chứng

Dữ liệu ghi ra rồi nằm yên trong nhiều tháng không phải là dữ liệu bất biến về mặt vật lý. Khối lỗi phát sinh âm thầm, thiết bị xuống cấp, một quá trình di chuyển dữ liệu để lại bản sao thiếu, một tệp chỉ mục bị hỏng khiến toàn bộ chuỗi bản sao gia tăng phía sau không dùng được nữa.

Nhiều tổ chức bật tính năng kiểm tra tổng kiểm và coi như đã đủ. Kiểm tra tổng kiểm xác nhận rằng các khối đọc lại giống như lúc ghi, đây là một lớp bảo vệ tốt nhưng vẫn chỉ nói về tính toàn vẹn của khối. Nó không nói rằng tập hợp các khối đó tạo thành một hệ thống khởi động được. Một bản sao chỉ chuyển từ trạng thái giả định sang trạng thái tài sản sau lần khôi phục đầu tiên thành công.

Thiếu khóa mã hóa

Mã hóa dữ liệu sao lưu là việc nên làm, và cũng là việc tạo ra một điểm hỏng mới nếu quản lý khóa không được thiết kế cẩn thận. Có vài kịch bản lặp đi lặp lại: khóa được lưu trong hệ thống quản lý bí mật vốn cũng nằm trong phạm vi sự cố; khóa chỉ tồn tại trên máy chủ sao lưu đã hỏng; khóa đã được xoay vòng còn bản sao cũ vẫn dùng khóa trước đó mà không ai lưu lại; hoặc khóa nằm trong tài khoản cá nhân của một người đã rời tổ chức.

Có một nghịch lý cần chấp nhận: kho lưu khóa phục vụ khôi phục phải được bảo vệ nghiêm ngặt, nhưng đồng thời phải truy cập được trong tình huống mà nhiều hệ thống khác đã ngừng hoạt động. Điều này gần như luôn đòi hỏi một đường truy cập riêng, có kiểm soát và có ghi nhật ký, hoàn toàn tách khỏi hạ tầng thường ngày. Hãy kiểm tra đường đó trong diễn tập, vì đây là loại phụ thuộc chỉ lộ ra khi bạn thực sự cần nó.

Phụ thuộc khôi phục không được sao lưu

Đây là nguyên nhân gây bất ngờ nhiều nhất cho các đội đã làm sao lưu tương đối tốt. Họ bảo vệ cẩn thận các máy chủ ứng dụng và cơ sở dữ liệu, rồi phát hiện ra rằng để khôi phục được những thứ đó, họ cần một loạt dịch vụ nền mà không ai xếp vào danh sách quan trọng.

• Dịch vụ danh bạ và 인증. Nếu dịch vụ thư mục không khả dụng, nhiều ứng dụng sẽ khôi phục xong nhưng không ai đăng nhập được, kể cả quản trị viên.
• DNS phân giải nội bộ. Ứng dụng thường gọi nhau bằng tên chứ không bằng địa chỉ. Khôi phục vào môi trường không có phân giải tên đúng sẽ tạo ra một chuỗi lỗi kết nối rất khó chẩn đoán dưới áp lực.
• Máy chủ cấp phép. Một số phần mềm thương mại từ chối khởi động khi không liên lạc được với máy chủ cấp phép, hoặc khi phần cứng đã đổi và bản quyền cần kích hoạt lại.
• Hạ tầng chứng thư số nội bộ. Kết nối nội bộ dùng chứng thư do tổ chức tự cấp sẽ hỏng nếu cơ quan cấp chứng thư chưa được khôi phục trước.
• Kho bí mật và biến cấu hình. Ứng dụng khôi phục xong nhưng không có chuỗi kết nối cơ sở dữ liệu thì vẫn là ứng dụng không chạy.
• Bản thân cấu hình của hệ thống sao lưu. Danh mục và cấu hình của phần mềm sao lưu cũng cần được sao lưu ra ngoài, nếu không bạn có dữ liệu nhưng không có công cụ đọc nó.

Cách phát hiện nhóm nguyên nhân này rất đơn giản và rất khó chịu: thử khôi phục vào một môi trường tách biệt hoàn toàn, không có kết nối tới hạ tầng đang chạy. Mọi phụ thuộc ẩn sẽ hiện ra trong vòng vài giờ.

Chính sách lưu trữ đã hết hạn đúng điểm bạn cần

Không phải sự cố nào cũng được phát hiện ngay. Dữ liệu bị hỏng do một lỗi phần mềm, một quy trình nhập liệu sai, hoặc một hành vi phá hoại có chủ đích có thể tồn tại âm thầm nhiều tuần trước khi ai đó nhận ra. Khi đó câu hỏi không còn là bạn có bản sao hay không, mà là bạn có bản sao đủ cũ hay không.

Nhiều chính sách lưu trữ được thiết kế xoay quanh kịch bản mất dữ liệu đột ngột, nơi bản sao gần nhất luôn là bản tốt nhất. Với hỏng dữ liệu âm thầm, logic đó đảo ngược: bản gần nhất chính là bản chứa lỗi. Nếu chính sách chỉ giữ vài ngày gần nhất, mọi bản sao trong tay bạn đều đã nhiễm cùng một vấn đề.

Một điểm nữa dễ bỏ sót: chính sách lưu trữ và tính bất biến phải khớp nhau. Nếu thời hạn khóa bất biến ngắn hơn thời gian bạn cần để phát hiện sự cố, thì lớp bảo vệ đó không che đúng khoảng thời gian rủi ro.

Không đủ năng lực hoặc băng thông để khôi phục

Sao lưu là hoạt động gia tăng, chạy đều đặn với lượng dữ liệu nhỏ mỗi lần. Khôi phục là hoạt động toàn phần, dồn vào một khoảng thời gian ngắn. Một đường truyền hoàn toàn thoải mái với tác vụ sao lưu hàng đêm có thể mất nhiều ngày để kéo về toàn bộ tập dữ liệu, và không ai để ý điều này cho đến khi thử.

Các yếu tố thường bị bỏ qua khi tính toán: dữ liệu ở lớp lưu trữ lạnh cần thời gian chuẩn bị trước khi tải; giải nén và giải mã tiêu tốn tài nguyên tính toán đáng kể và có thể trở thành nút thắt trước cả đường truyền; khôi phục đồng thời nhiều hệ thống sẽ chia nhau cùng một băng thông, nên tổng thời gian không bằng thời gian của hệ thống lâu nhất; và môi trường đích cần đủ dung lượng trống, điều thường không đúng nếu bạn định khôi phục lên chính hạ tầng vừa gặp sự cố.

Chưa ai từng làm thật

Tất cả các nguyên nhân trên đều có một điểm chung: chúng có thể được phát hiện trước bằng một lần khôi phục thử, và hầu như không thể phát hiện bằng cách khác. Việc kiểm chứng bị bỏ qua không phải vì đội kỹ thuật không hiểu tầm quan trọng, mà vì nó cần thời gian con người, cần môi trường riêng, và cần được ưu tiên hơn những việc có vẻ khẩn cấp hơn.

Một quy trình khôi phục chỉ tồn tại trên tài liệu sẽ luôn chậm hơn dự tính, vì tài liệu bỏ qua những chi tiết mà người viết coi là hiển nhiên nhưng người thực hiện lúc hai giờ sáng thì không. Diễn tập cũng cho bạn một thứ khác mà không tài liệu nào thay thế được: sự tự tin của đội vận hành rằng họ đã làm việc này trước đây.

Danh sách kiểm tra để bắt đầu

• Chọn một hệ thống quan trọng và khôi phục thật vào môi trường tách biệt, đo thời gian từ lúc bắt đầu đến lúc nghiệp vụ xác nhận dữ liệu đúng.
• Xác nhận rằng cơ sở dữ liệu đang được sao lưu theo cách nhận biết ứng dụng, không chỉ ở mức tệp.
• Kiểm tra rằng khóa mã hóa có thể lấy được khi hạ tầng chính không khả dụng.
• Lập danh sách phụ thuộc cần có để khôi phục hệ thống đó, và kiểm tra từng phụ thuộc có được sao lưu hay không.
• Đối chiếu thời gian lưu trữ với thời gian trung bình để phát hiện một sự cố hỏng dữ liệu âm thầm.
• Ước lượng thời gian truyền toàn bộ tập dữ liệu ở điều kiện thật, không dùng thông số lý thuyết của đường truyền.
• Ghi lại kết quả và ngày thực hiện, rồi đặt lịch cho lần tiếp theo.

HiTechCloud có thể hỗ trợ gì

HiTechCloud là đối tác của AWS và Google Premier Partner, đồng thời vận hành hạ tầng đặt trong nước. Chúng tôi hỗ trợ doanh nghiệp kiểm chứng khả năng khôi phục thực tế, rà soát cấu hình sao lưu cho cơ sở dữ liệu và ứng dụng có trạng thái, lập bản đồ phụ thuộc khôi phục, và tổ chức diễn tập khôi phục trong môi trường tách biệt có đo thời gian. Nếu bạn muốn biết bản sao của mình có thực sự dùng được hay không, hãy liên hệ với đội ngũ của chúng tôi.