Ở một nhóm nhỏ, khôi phục sau thảm họa thường chỉ là một dòng duy nhất trong tài liệu mà chưa ai từng mở ra: sao lưu đã được bật. Câu đó đúng nhưng không phải là câu trả lời, bởi nó không nói gì về việc dữ liệu lấy lại sẽ cũ đến mức nào, việc khôi phục mất bao lâu, hay đã có ai từng thực hiện trọn vẹn một lần nào chưa.

Chính khoảng cách giữa việc có bản sao lưu và việc thật sự khôi phục được là nơi phần lớn sự cố gián đoạn biến thành sự cố nghiêm trọng. Một bản sao lưu tồn tại, còn mới, nhưng chưa bao giờ được khôi phục thì vẫn chỉ là một giả thiết, và thời điểm bạn kiểm chứng nó lại là thời điểm tệ nhất để phát hiện ra giả thiết đó sai.

Hai con số biến ý kiến thành kế hoạch. Bạn chịu mất được bao nhiêu dữ liệu, và bạn chịu ngừng hoạt động được bao lâu? Đó chính là mục tiêu điểm khôi phục và mục tiêu thời gian khôi phục của bạn. Chừng nào chưa có ai bên phía kinh doanh nói ra hai con số ấy, mọi tranh luận kỹ thuật về tần suất sao lưu đều không thể ngã ngũ, vì không có tiêu chí nào để đối chiếu.

RPO và RTO nói bằng lời dễ hiểu

Recovery point objective, tức RPO, là lượng dữ liệu bạn chấp nhận mất. Sao lưu hằng đêm nghĩa là RPO 24 giờ: một sự cố lúc 17 giờ sẽ cuốn đi toàn bộ những gì phát sinh từ đêm hôm trước. Nếu điều đó không thể chấp nhận thì lịch sao lưu đang sai, và mọi sự cẩn thận ở những chỗ khác đều không bù lại được.

Recovery time objective, tức RTO, là khoảng thời gian bạn chấp nhận ngừng hoạt động. Nó bao gồm tất cả: phát hiện, quyết định, cấp phát hạ tầng, khôi phục, kiểm chứng và chuyển lưu lượng trở lại. Các nhóm thường chỉ ước lượng bước khôi phục và quên mất năm bước còn lại, và đó chính là lý do những lần khôi phục thật kéo dài gấp nhiều lần so với dự tính.

Cả hai đều là quyết định kinh doanh chứ không phải quyết định kỹ thuật, và cả hai đều tốn tiền khi bị siết chặt hơn. RPO năm phút đòi hỏi sao chép liên tục. RTO một giờ đòi hỏi hạ tầng có thể dựng lại tự động, bởi dưới áp lực sẽ không ai cấu hình thủ công xong một máy chủ trong vòng một giờ.

Cuộc trao đổi có ích là cuộc trao đổi về đánh đổi. Hãy nói cho phía kinh doanh biết mỗi mức đòi hỏi chi phí bao nhiêu rồi để họ chọn, thay vì tự chọn một con số bên kỹ thuật và hy vọng nó khớp với những kỳ vọng chưa từng được nói ra.

Bản sao lưu chưa thử khôi phục thì không phải bản sao lưu

Những thất bại gây đau đớn hiếm khi là do không có bản sao lưu. Chúng thường là những bản sao lưu hóa ra không dùng được đúng vào lúc cần đến.

Các nguyên nhân phổ biến, tất cả chỉ lộ ra khi khôi phục: tác vụ đã âm thầm hỏng suốt nhiều tuần vì không ai theo dõi thành công kỹ như theo dõi thất bại. Bản dump lấy được lược đồ nhưng không lấy dữ liệu, hoặc chỉ lấy một phần các bảng vì có người từng thêm phần còn lại vào danh sách loại trừ. Tệp được mã hóa bằng khóa cất ngay trên chính chiếc máy vừa chết. Bản sao lưu nằm cùng tài khoản hoặc cùng vùng với thứ mà nó phải bảo vệ.

Điểm cuối cùng ấy ngày nay nặng ký hơn trước. Một bản sao lưu đặt trong cùng môi trường với hệ thống chạy thật chỉ được bảo vệ trước hỏng hóc phần cứng và không trước bất cứ điều gì khác. Nó không sống sót qua việc tài khoản bị chiếm, qua một thao tác xóa nhầm ở cấp tài khoản, hay qua mã độc tống tiền vươn tới mọi thứ mà cùng bộ thông tin đăng nhập đó vươn tới được.

Cách duy nhất để biết một bản sao lưu còn dùng được là khôi phục nó. Hãy đưa việc đó vào lịch, làm tối thiểu mỗi quý một lần, và bấm giờ. Con số bấm giờ ấy mới là RTO thật của bạn, khác với con số ghi trong tài liệu.

Khôi phục sau thảm họa phải bao trùm những gì

Dữ liệu là phần hiển nhiên và hiếm khi là phần chậm. Thứ kéo dài quá trình khôi phục hầu như luôn là những hạng mục chưa ai liệt kê ra.

Cơ sở dữ liệu, thứ ai cũng nhớ. Các tệp người dùng tải lên, nằm ở một nơi tách biệt và thường không hề có bản sao lưu nào. Cấu hình và khóa bí mật, thường chỉ tồn tại trên chính chiếc máy đang chạy. DNS và chứng chỉ, không thể tạo lại nhanh nếu tài khoản đang giữ chúng lại đúng là thứ bạn vừa mất. Bản thân hạ tầng, tức là máy chủ, mạng và các quy tắc, dựng lại rất nhanh nếu được định nghĩa bằng mã và chậm đến khổ sở nếu được tạo ra bằng cách bấm chuột.

Và cả hiểu biết về việc mọi thứ ghép với nhau ra sao, yếu tố quyết định lớn nhất đối với thời gian khôi phục ở một nhóm nhỏ. Một hệ thống mà chỉ một người dựng lại được từ trí nhớ sẽ có thời gian khôi phục đúng bằng mức độ sẵn sàng của người đó, và như thế thì không phải là kế hoạch.

Hãy viết bản kiểm kê trước khi viết kế hoạch. Phần lớn các nhóm phát hiện ít nhất một thành phần hoàn toàn không có bản sao lưu ngay khi lập danh sách, và phát hiện theo cách đó rẻ hơn rất nhiều so với cách còn lại.

Một kế hoạch gói gọn trong một trang

Tài liệu dài sẽ không được đọc trong lúc sự cố đang diễn ra. Hãy nhắm tới thứ mà một người mệt mỏi có thể làm theo lúc ba giờ sáng mà không phải suy nghĩ.

Kế hoạch cần có: ai là người quyết định rằng việc khôi phục đã bắt đầu, vì sự do dự trước câu hỏi tình huống này đã tính là thảm họa hay chưa là nguồn chậm trễ rất phổ biến. Bản sao lưu nằm ở đâu và tiếp cận bằng cách nào, kể cả thông tin đăng nhập không phụ thuộc vào hệ thống đã sập. Các bước khôi phục theo đúng thứ tự, đủ cụ thể để làm theo mà không phải ứng biến. Cách kiểm chứng rằng nó đã thành công, nghĩa là một phép kiểm tra cụ thể chứ không phải cảm giác thấy trang web tải được. Và phải báo cho ai, cả bên trong lẫn bên ngoài.

Hãy cất nó ở nơi sống sót qua sự cố. Một kế hoạch khôi phục chỉ được lưu bên trong chính hệ thống mà nó phải khôi phục là sai lầm lặp đi lặp lại và hoàn toàn có thể tránh được.

Lập luận tương tự áp dụng cho quyền truy cập. Nếu chỉ một người giữ thông tin đăng nhập tài khoản hosting, thời gian khôi phục của bạn bị giới hạn bởi việc người đó có nghe máy hay không. Hướng dẫn tăng cường bảo mật máy chủ Linux của chúng tôi trình bày những kiểm soát truy cập mà tất cả điều này phụ thuộc vào.

Vừa đủ, không cần hoàn hảo

Một nhóm nhỏ không cần hệ thống dự phòng nóng ở vùng thứ hai. Chi phí là có thật và sự phức tạp kéo theo những kiểu hỏng hóc của riêng nó.

Thứ mà phần lớn nhóm nhỏ thực sự cần rẻ hơn nhiều: bản sao lưu ở một tài khoản tách biệt với thông tin đăng nhập mà hệ thống chạy thật không dùng được, một lần khôi phục được kiểm thử và bấm giờ theo lịch, hạ tầng định nghĩa bằng mã để dựng lại mà không phải đào bới, và một kế hoạch một trang mà có người đã thật sự đọc.

Bộ này bao trùm hỏng hóc phần cứng, xóa nhầm, tài khoản bị chiếm và mã độc tống tiền, tức là hầu hết những gì thật sự xảy ra. Mọi thứ vượt quá đó là quyết định về việc giảm thêm thời gian ngừng hoạt động thì đáng giá bao nhiêu, và đó là câu hỏi dành cho phía kinh doanh chứ không dành cho phía kỹ thuật.

Mecanik rà soát và xây dựng đúng những phần này trong dịch vụ phân tích bảo mật máy chủ . Câu hỏi đầu tiên bao giờ cũng giống nhau và không liên quan tới công nghệ: bạn ngừng hoạt động được bao lâu, và ai đã quyết định con số đó?

Bài viết liên quan: SLA uptime thực sự có ý nghĩa , Bảo mật chuỗi cung ứng phần mềm cho nhóm nhỏ , Tác nhân AI trong doanh nghiệp: chi phí và thất bại và Phát triển phần mềm fintech tại Anh: FCA, rails và chi phí .

Câu hỏi thường gặp

RPO và RTO nghĩa là gì? Recovery point objective là lượng dữ liệu bạn chấp nhận mất, nên sao lưu hằng đêm hàm ý RPO 24 giờ. Recovery time objective là khoảng thời gian bạn chấp nhận ngừng hoạt động, bao gồm phát hiện, quyết định, cấp phát hạ tầng, khôi phục, kiểm chứng và chuyển lưu lượng trở lại. Cả hai đều là quyết định kinh doanh, và cả hai đều tốn kém hơn khi bị siết chặt.

Vì sao bản sao lưu chưa thử khôi phục lại không phải bản sao lưu? Vì các kiểu hỏng chỉ lộ ra khi khôi phục. Tác vụ âm thầm hỏng suốt nhiều tuần khi không ai theo dõi thành công kỹ như thất bại, bản dump lấy lược đồ mà thiếu dữ liệu hoặc bỏ sót các bảng bị loại trừ, khóa mã hóa nằm trên chính chiếc máy đã chết, và bản sao đặt cùng tài khoản với thứ nó bảo vệ. Hãy khôi phục mỗi quý và bấm giờ.

Nên lưu bản sao lưu ở đâu? Ở một tài khoản hoặc một vùng tách biệt, với thông tin đăng nhập mà hệ thống chạy thật không dùng được. Bản sao lưu đặt trong cùng môi trường chỉ chống được hỏng hóc phần cứng và không chống được gì khác: nó không sống sót qua việc tài khoản bị chiếm, qua thao tác xóa ở cấp tài khoản, hay qua mã độc tống tiền vươn tới mọi thứ mà cùng bộ thông tin đăng nhập đó vươn tới được.

Người ta hay quên đưa gì vào kế hoạch khôi phục sau thảm họa? Các tệp tải lên được lưu tách khỏi cơ sở dữ liệu, cấu hình và khóa bí mật chỉ tồn tại trên máy đang chạy, DNS và chứng chỉ nằm trong tài khoản mà bản thân nó cũng có thể mất, hạ tầng được tạo bằng cách bấm chuột thay vì định nghĩa bằng mã, và hiểu biết về cách mọi thứ ghép với nhau khi chỉ một người nắm giữ.

Nhóm nhỏ có cần hệ thống dự phòng nóng không? Thường là không. Chi phí là có thật và sự phức tạp thêm vào mang theo những kiểu hỏng hóc của riêng nó. Bản sao lưu ở tài khoản tách biệt, một lần khôi phục được kiểm thử và bấm giờ, hạ tầng định nghĩa bằng mã và một kế hoạch một trang có người đã đọc sẽ bao trùm hỏng hóc phần cứng, xóa nhầm, tài khoản bị chiếm và mã độc tống tiền, tức là hầu hết những gì xảy ra.