Cliffhanger: Các bản sao lưu là đúng ở đây, phải không?

Trong công việc của tôi, sao lưu có mức độ ưu tiên thấp đáng ngạc nhiên. Chiến lược sao lưu đã được thực hiện cách đây một thời gian và kể từ đó, nó chỉ cho rằng các bản sao lưu đều ổn. Nếu bạn hỏi các sysadins, họ sẽ nói mọi thứ đều được sao lưu.

Nhưng sau đó, khi bạn yêu cầu một bản sao lưu CỤ THỂ, một nửa thời gian họ không có ở đó:

• Đĩa đã đầy
• Băng không thành công
• Có vẻ như ai đó đã vô hiệu hóa công việc sao lưu
• Kết nối mạng đã ngừng hoạt động
• Chúng tôi đã đặt hàng đĩa đó từ nhiều năm trước, nhưng tài chính đã không chấp thuận đơn đặt hàng
• Các tập tin bị hỏng
• Tệp chứa cơ sở dữ liệu sai
• Chỉ sao lưu nhật ký giao dịch (vô dụng mà không có đầy đủ)

Vài tuần trước, thảm họa đã đến rất gần khi một trong những máy chủ bị mất quá nhiều đĩa đột kích. May mắn thay, một đĩa vẫn đủ tốt để sao chép dữ liệu, nếu bạn đã thử rất nhiều lần.

Nhưng ngay cả sau thảm họa gần đó, tôi dường như không thể thuyết phục được các sysadins để cải thiện tình hình. Vì vậy, tôi tự hỏi, bất kỳ lời khuyên để mở mắt của mọi người? Dường như với tôi, chúng tôi đang đi dọc theo mép của một vách đá.

Bạn luôn phải có được những điều này cố định từ đầu.

Là chiến lược sao lưu hiện tại được hỗ trợ và hiểu bởi quản lý? Nếu không, nó vô dụng.

Quản lý điều hành cần biết về các vấn đề và những rủi ro có liên quan (mất dữ liệu tài chính mà bạn cần đưa ra một cách hợp pháp để tồn tại hoặc dữ liệu khách hàng phải mất nhiều năm để thu thập?) Và cân nhắc rằng trong việc quyết định hành động hoặc quyết định để ai đó (như bạn) hành động.

Nếu bạn không thể quản lý, hãy thử các bộ điều khiển kinh doanh hoặc các vị trí tài chính khác trong đó việc truy xuất dữ liệu và tính toàn vẹn của nó có tầm quan trọng cao đối với các báo cáo của công ty. Lần lượt họ có thể "bắt đầu cơn bão" nếu cần ...

Nơi để bắt đầu? Đây là một thảm họa đang chờ để xảy ra. Chức năng công việc chính của Sysadmins là đảm bảo dữ liệu được sao lưu và phục hồi. Mọi thứ khác chỉ là thứ yếu. Không nếu không nhưng là.

Dưới đây là một vài điều bạn có thể làm:

1. Theo dõi KPI để khôi phục. Có thể tạo ra một báo cáo cho thấy có bao nhiêu yêu cầu phục hồi đã thành công. Bất cứ điều gì ít hơn 100% nên được điều tra kỹ lưỡng. Quản lý báo cáo tình yêu và đây là bằng chứng cứng.

2. Cần có các quy trình được lập thành văn bản cho tất cả các hoạt động sao lưu và khôi phục, bao gồm tất cả các hệ thống và chiến lược sao lưu của chúng, xoay băng, lịch trình, đường dẫn leo thang, khôi phục thử nghiệm, vv Yêu cầu xem chúng.

3. Nói chuyện với người quản lý của quản trị viên hệ thống và nói lên mối quan tâm của bạn. Đi vũ trang với bằng chứng rằng khôi phục không hoạt động. Nếu không có niềm vui đi cao hơn.

Nghiêm túc - đá lên một cách ồn ào. Những thứ như thế này có thể phá hủy một công ty.

Đề xuất (tối thiểu) các thử nghiệm phục hồi thảm họa hàng năm. Công việc cần thiết để thực hiện kiểm tra thành công sẽ tiết lộ những thiếu sót.

Nơi tôi làm việc, chúng tôi có một bộ phận CNTT rất tốt, hàng năm họ tụ tập từ mọi văn phòng trên khắp châu Âu và có một 'lễ hội khôi phục' trên các máy chủ được thuê trong một trung tâm dữ liệu, mô phỏng hiệu quả những gì sẽ xảy ra nếu nhân viên đến làm việc một ngày và tìm thấy văn phòng đã bị cháy trong đêm.

Để ông chủ lớn tham gia, nhắc nhở anh ta rằng nếu thảm họa xảy ra, anh ta sẽ không nhận được tiền thưởng vào năm đó (hoặc tệ hơn!) Và vì vậy có lẽ sẽ rất khôn ngoan khi tổ chức một cuộc tập trận khắc phục thảm họa tương tự. Sẽ không mất nhiều thời gian hoặc chi phí nhiều - quản trị viên được gửi đi với các băng sao lưu ngoại vi của họ và được yêu cầu mang đến một môi trường văn phòng giống hệt họ.

Sau đó ngồi lại và xem CNTT trở nên tốt hơn - một khi quản lý nhận ra rằng dữ liệu của công ty gần như bị mất vĩnh viễn, tia lửa sẽ bay (từ các tên lửa sẽ được đặt vào vị trí quản trị viên chiến lược)

Thật dễ dàng để đổ lỗi cho các quản trị viên - tuy nhiên Oskar có quyền: những điều này được thúc đẩy từ đầu. Nếu ban quản lý sẽ không chi nhiều tiền để ưu tiên sao lưu, thì các sysadins thường không gặp may và làm tốt nhất có thể với tài nguyên họ có.

Chìa khóa, nếu bạn là một trong những quản trị viên không may mắn đó - và tôi đã ở trên chiếc thuyền này vì một số cam kết của khách hàng - là bạn đảm bảo rằng việc quản lý được thông báo ngắn gọn, lặp đi lặp lại và theo cách có thể xác nhận bằng giấy tờ, rằng đây là một rủi ro cho doanh nghiệp.

Chiến lược của tôi là liên tục búa vào các vấn đề. Nếu bạn làm điều đó, đôi khi các vấn đề sẽ được khắc phục, nhưng chủ yếu là do bất kỳ ai tôi báo cáo không thể ẩn đằng sau lý do "Tôi không bao giờ được thông báo". Là một nhà tư vấn, tôi thường có thể đi tốt hơn. Tôi có thể khiến các sếp của mình tóm tắt quản lý cấp cao hơn tôi có thể có một lỗ hổng. Điều này lan truyền sự đổ lỗi xung quanh, hoặc ít nhất là tập trung nó ở mức cao hơn tôi.

Đồng thời bạn phải sáng tạo và làm việc chăm chỉ để giảm thiểu rủi ro với bất kỳ nguồn lực nào khách hàng có thể cung cấp.

Mặc dù trong một số trường hợp, quản trị viên có thể là có thể phạm tội, ban quản lý luôn có trách nhiệm: vì biết rủi ro và không làm đủ để giảm thiểu hoặc thuê những người không cảnh báo họ về những rủi ro này.

Tôi chịu trách nhiệm cho khoảng 200 máy chủ trải khắp Tây Bắc Vương quốc Anh và điều này rõ ràng là quá nhiều để kiểm tra thủ công.

Tôi định cấu hình sao lưu để khi hoàn thành, nó chạy tập lệnh (VBScript) xem qua nhật ký sao lưu, tìm hiểu xem bản sao lưu có hoạt động hay không và ghi một bản ghi vào cơ sở dữ liệu trung tâm với kết quả sao lưu. Sau đó, tại trụ sở chính, tôi chạy một kịch bản truy vấn cơ sở dữ liệu này và đưa cho tôi một danh sách các trang web trong đó bản sao lưu báo cáo lỗi hoặc không có báo cáo từ trang web.

Kết quả cuối cùng là khi tôi ngồi xuống bàn làm việc, tôi có một danh sách tất cả các trang web mà tôi cần kiểm tra bản sao lưu.

Điểm chính của tất cả những điều này là giả định mặc định là sao lưu thất bại và sao lưu được coi là chỉ hoạt động nếu VBScript của tôi không phát hiện ra lỗi và viết kết luận này cho cơ sở dữ liệu của tôi. Điều này đảm bảo các lỗi sao lưu không được chú ý.

Một số máy chủ sử dụng Backup Exec, một số NTBackup và một số chỉ sao chép tệp của họ sang máy chủ khác trên mạng. Việc máy chủ thực hiện loại sao lưu nào không quan trọng vì nó dễ dàng điều chỉnh VBScript của tôi để kiểm tra lỗi. Kịch bản của tôi thực sự khá cơ bản, nó chỉ mở báo cáo sao lưu dưới dạng tệp văn bản và greps cho các cụm từ như "không thể gắn kết", "băng đầy", "lỗi CRC", v.v. Tôi chắc chắn một lập trình viên chuyên nghiệp sẽ làm một công việc lắt léo. Tuy nhiên, toàn bộ điều này rất đơn giản và mạnh mẽ, và nó chủ động theo nghĩa là tôi thấy báo cáo lỗi sao lưu dù muốn hay không và tôi chỉ không nhận thấy lỗi nếu tôi quyết định bỏ qua báo cáo.

JR

PS 99% lỗi sao lưu là do người dùng quên thay băng dự phòng. Đừng chỉ yêu những người yêu thích :-)

Một bản sao lưu không được kiểm tra là không có bản sao lưu nào.