Thực hành tốt nhất để kiểm tra sao lưu?


21

Đây là một tình huống phổ biến, khi quản trị viên tạo hệ thống để sao lưu tự động và quên nó. Chỉ sau khi hệ thống bị lỗi thông báo của quản trị viên, hệ thống sao lưu đó đã bị hỏng trước đó hoặc sao lưu không đáng tin vì một số lỗi và anh ta không có bản sao lưu hiện tại để khôi phục từ ... Vậy thực hành tốt nhất để tránh những tình huống như vậy là gì ??


Chúng tôi có giám sát dự phòng trong một tập lệnh ... nó được hợp nhất với giám sát khác và được gửi đến quản trị viên mỗi ngày. Nếu sao lưu toàn bộ bị bỏ qua (hoặc chỉ hoàn thành một phần), e-mail sẽ chỉ ra điều này.
bíp bíp

Câu trả lời:


27

Chạy máy khoan lửa ... cứ sau vài tháng, một ý kiến ​​hay là hệ thống XYZ ngừng hoạt động ... sau đó thực sự trải qua các hoạt động đưa nó trở lại trực tuyến với một VM mới, v.v. Nó giữ mọi thứ trung thực và giúp bạn nắm bắt sai lầm.


Chúng tôi đã làm điều này tại nơi làm việc để kiểm tra rằng các bản sao lưu an toàn nguồn trực quan của chúng tôi đang hoạt động tốt, may mắn là chúng đã hoạt động.
Jared

10

chế độ hộp xà phòng: ON

Tôi có thể nói rằng đơn giản là các bản sao lưu không được kiểm tra thường xuyên là vô giá trị.

Một công việc trước đây của tôi, chúng tôi có một chính sách rằng mọi hệ thống (sản xuất, thử nghiệm, giám sát phát triển, v.v.) nên được kiểm tra khôi phục sau mỗi 6 tháng.

Đây cũng là công việc của hầu hết các quản trị viên cơ sở để tài liệu được cập nhật. Junior được xác định bởi bao nhiêu công việc anh ấy / cô ấy đã quyên góp trên hệ thống cụ thể, đôi khi (thực tế khá thường xuyên) đó là "quản lý nhóm" đã làm điều đó

Chúng tôi có phần cứng đặc biệt dành riêng cho điều này (một hộp Intel và một hộp IBM / AIX) có thông số kỹ thuật thấp cho mọi thứ trừ không gian đĩa, vì chúng tôi không cần phải chạy bất cứ thứ gì thực sự trên máy chủ được khôi phục.

Khá nhiều công việc trong vài vòng đầu tiên nhưng nó đã khiến chúng tôi hợp lý hóa quá trình khôi phục, đó là phần quan trọng của sao lưu.


7

Vì dường như bạn đang đề cập đến thực tế là quản trị viên không nhận thấy rằng công việc sao lưu "bị hỏng" và không quá nhiều để một bản sao lưu hoạt động không hoạt động đúng, tôi sẽ đề xuất xây dựng một số loại kịch bản giám sát xung quanh các bản sao lưu.

Khi xây dựng một giải pháp sao lưu tự trồng tại nhà, tôi sẽ làm một cái gì đó như thế này:

  • Xây dựng một kịch bản để sao lưu dữ liệu của bạn.
  • Thực hiện khôi phục thử nghiệm để đảm bảo kịch bản hoạt động chính xác.
  • Trong tập lệnh hoặc thông qua một số phương tiện khác, thực hiện một cách để theo dõi trạng thái của các bản sao lưu (thành công, thất bại, đã chạy, không chạy).
  • Có theo dõi trạng thái theo dõi (email, cơ sở dữ liệu, một cái gì đó)

Một khi tất cả điều đó được thực hiện, bạn sẽ ổn thôi. Một điều nữa cần làm là thực hiện khôi phục kiểm tra thường xuyên. Nếu bạn có thêm phần cứng để tặng cho nguyên nhân đó là.

Nơi tôi làm việc, chúng tôi có một địa điểm ấm áp, mỗi tháng một lần chúng tôi chọn ngẫu nhiên một hệ thống hoặc cơ sở dữ liệu và đến địa điểm ấm áp của chúng tôi và thực hiện một bài tập phục hồi thử nghiệm trên kim loại trần để đảm bảo khả năng phục hồi dữ liệu của chúng tôi.

Thành thật mà nói, nếu dữ liệu của bạn rất quan trọng đối với bạn, bạn nên đầu tư vào một số phần mềm để quản lý các bản sao lưu cho bạn. Có hàng trăm sản phẩm ngoài kia cho việc này, từ giá rẻ và đơn giản, cho đến lớp doanh nghiệp.

Nếu bạn đang dựa vào một tập các tập lệnh viết tay đang chạy trong crontab để sao lưu công ty của bạn, sớm hay muộn bạn sẽ có thể bị đốt cháy.


4

Chúng tôi có các phiên bản 'Tham khảo' 60% kích thước của các hệ thống 'Sản xuất' của chúng tôi, chúng tôi sử dụng chúng để kiểm tra các thay đổi cuối cùng, chúng tôi khôi phục các bản sao lưu 'Sản xuất' cho các hệ thống này - nó kiểm tra sao lưu cộng với đảm bảo cả hai môi trường đều đồng hành với nhau .


1

Một cách tiếp cận là kịch bản một công việc "phục hồi" để chạy định kỳ, ví dụ: một công việc lấy một tệp văn bản cụ thể từ bản sao lưu gần đây nhất và gửi email cho bạn nội dung của nó. Nếu có thể, điều này nên - ít nhất là đôi khi - được thực hiện bằng cách sử dụng một hộp khác với hộp đã tạo hoặc sao lưu dữ liệu, chỉ để đảm bảo nó sẽ hoạt động nếu bạn cần làm như vậy. Ưu điểm là bạn có thể chắc chắn rằng các cơ chế mã hóa / giải mã, nén và lưu trữ của bạn đều hoạt động.

Đây là một chút liên quan đến các bản sao lưu chuyên dụng như email và máy chủ cơ sở dữ liệu, mặc dù thực hiện một số loại phục hồi quy mô nhỏ từ một bản sao lưu hộp thư DB hoặc cục gạch nhỏ và xác minh nội dung là có thể, chỉ cần tham gia thêm một chút.

Cách tiếp cận này cũng không nên thay thế khôi phục hoàn toàn định kỳ để đảm bảo bạn có thể khôi phục dữ liệu trong trường hợp khẩn cấp - nó chỉ cho phép bạn tự tin hơn một chút về tính toàn vẹn của công việc sao lưu hàng ngày.


1

Khi thực hiện khôi phục thử nghiệm, tôi không thực sự cảm thấy thoải mái ở điểm "điều này có vẻ tốt, các tệp được khôi phục, dường như không có tệp nào bị thiếu, ngay cả kích thước khớp" hoặc tại điểm "điều này có vẻ tốt, tôi đã khởi động ứng dụng của mình. .. không sụp đổ, hiển thị một số dữ liệu phong nha ".

Tôi muốn khôi phục máy chủ / cụm từ đầu, và sau đó thực sự sử dụng nó để sản xuất . Không phải trong một phút, không phải trong một giờ, mà là vĩnh viễn . Nếu bạn cho rằng khôi phục của bạn thành công, thì hoàn toàn không có lý do gì để không bắt đầu sản xuất. Đây không phải là một số hệ thống "bẩn", mà nên bị lãng quên. Đây là hệ thống mà bạn sẽ phải đối mặt sau một thảm họa thực sự. Vì vậy, nếu nó vượt qua giai đoạn "trông đẹp", hãy sống với nó. Sao lưu nó vào tối hôm sau. Hãy quên đi bản gốc. Có thể bạn sẽ khám phá một số trục trặc sử dụng phương pháp này, và bạn sẽ được buộc để sửa chữa tất cả trong số họ . Việc khôi phục tiếp theo của cùng một hệ thống có cơ hội tốt để thành công 100%.

Điều này bao gồm phần mềm sao lưu và máy chủ của bạn. Vâng, bạn cần phải khôi phục những điều này quá.


Không có ngân sách để mua phần cứng chuyên dụng để khôi phục?

  • Tạo một điểm mà bạn thực sự cần một ngân sách. Mỗi lần nhắc nhở những người ra quyết định rằng một thử nghiệm khôi phục hợp lệ, trong suốt quá trình khôi phục vẫn chưa xảy ra. (Và vâng, thu thập bằng chứng để che mông của bạn. Thế giới khó khăn.)
  • Trong hầu hết các tổ chức đôi khi có một doanh nghiệp cần di chuyển một số hệ thống sang phần cứng khác, vì vậy hãy sử dụng cơ hội. Luôn chọn phương thức "khôi phục từ bản sao lưu" để di chuyển, giả vờ rằng bạn vừa mất phần cứng ban đầu. Vâng, nó có nghĩa là nhiều thời gian chết hơn, xin lỗi về điều đó. Ít nhất bạn sẽ tự tin rằng bản sao lưu của bạn là hữu ích.
  • Không di cư? Có thể bạn có thể mượn một số phần cứng trong hai tuần và thực hiện hai bài kiểm tra khôi phục (khôi phục phần cứng đã mượn, đợi hơn một tuần, khôi phục từ mượn về bản gốc, sống với nó). Thông thường, nếu có một phần cứng mới được mua cho một số hệ thống mới và bạn sắp xếp mọi thứ hợp lý, bạn có thể dễ dàng mượn nó - bằng cách cung cấp để kiểm tra toàn diện nó trong hai tuần. Nếu phần cứng mới không giống 100% với phần cứng cũ, điều đó sẽ giúp bài kiểm tra của bạn trở nên tuyệt vời hơn. Làm thế nào để bạn biết nếu bạn có được phần cứng giống hệt nhau trong trường hợp thảm họa thực sự?
  • Bất kỳ hệ thống mới đang được thực hiện bởi bạn tại thời điểm này? Bạn có thể kiểm tra khôi phục ngay bây giờ? Không sử dụng phần cứng bổ sung, chỉ cần ghi đè lên hệ thống mới vì bạn có kiến ​​thức mới về cách triển khai lại nhanh chóng. Điều này hoạt động nếu nó không có dữ liệu quan trọng. Một lần nữa, đi đến sản xuất trên phiên bản được khôi phục, không phải trên phiên bản mới được cài đặt lại.

1
  1. Khoan chữa cháy.
  2. Chính sách kiểm tra tất cả các bản sao lưu cứ sau 6 tháng là một ý tưởng rất hay
  3. Khi nói đến thử nghiệm, bạn cần xem xét từng ứng dụng hoặc hệ thống sao lưu của bạn. Lý tưởng nhất, những gì cấu thành một bản sao lưu "thành công" hoặc "có thể phục hồi" nên được liệt kê trong Mô tả dịch vụ hoặc SOP (tài liệu vận hành) cho bản sao lưu của bạn, cùng với các chi tiết khác như thời gian lưu, bladibla.

Bạn có thể thấy rằng một số loại sao lưu có thể dễ dàng khôi phục được kiểm tra bởi các tập lệnh (chẳng hạn như cơ sở dữ liệu) trong khi các loại khác cần một số đầu vào thủ công (khôi phục Active Directory). Tự động hóa càng nhiều càng tốt về điều này, đảm bảo có một số loại báo cáo được thực hiện và đảm bảo "ai đó" cũng thực hiện các bài kiểm tra thủ công theo định kỳ. Một môi trường biệt lập (bản sao thu nhỏ của prod) sẽ giúp thực hiện kiểm tra khôi phục dễ dàng hơn.


1
Tha thứ cho câu hỏi, nhưng câu trả lời này có thêm bất cứ điều gì chưa được nói không?
MadHatter hỗ trợ Monica

Cứ sau 6 tháng? Tôi làm những cái quy mô nhỏ cứ sau vài tuần.
Tombull89

0

Mặc dù chúng tôi không kiểm tra các bản sao lưu nhưng chúng tôi có thành phần kiểm tra và báo cáo sao lưu tập trung trong hệ thống mà chúng tôi đã phát triển BackupRadar.com. Hãy kiểm tra xem nó có giúp ích gì với thành phần đó không. Nó đính kèm một bản sao của email thành công / thất bại vào chính sách sao lưu và nó cũng sẽ đính kèm ảnh chụp màn hình nếu phần mềm sao lưu của bạn cũng có khả năng gửi chúng.

Cảm ơn, Patrick


-1

Đảm bảo rằng hoạt động sao lưu được ghi lại, sau đó viết một cái gì đó (tất nhiên là perl) để phân tích các bản ghi tìm kiếm thất bại, chắt lọc nó và gửi nó dưới dạng email hàng ngày.


2
Điều này không giải quyết được tình huống trong đó chiến lược sao lưu tự nó bị lỗi.
Jared
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.