Tôi thường xuyên thấy mọi người đặt câu hỏi về các chiến lược sao lưu mà họ nên sử dụng cho cơ sở dữ liệu của mình. Nó dường như không bao giờ thất bại, mọi câu hỏi kiểu này mà tôi đã gặp trên nhiều diễn đàn khác nhau chưa bao giờ bao gồm các yêu cầu khôi phục của họ. Tôi thường bối rối khi xem xét các yêu cầu khôi phục của bạn trước khi thiết kế chiến lược sao lưu của bạn. Khi được nhấn cho các yêu cầu, tôi thường sẽ nhận được các yêu cầu dự phòng, ví dụ:
- Bản sao lưu không được gây ra bất kỳ thời gian ngừng hoạt động nào
- Cần có khả năng sao lưu các nhật ký làm lại đã lưu trữ
- Các bản sao lưu phải được ghi vào băng
Những yêu cầu này là tốt và tốt, nhưng theo ý kiến của tôi, bạn không bao giờ nên thiết kế chiến lược sao lưu của mình mà không ghi lại các yêu cầu khôi phục của bạn trước và thu thập thông tin quản lý.
Vì vậy, đây là một số câu hỏi mà tôi tự hỏi mình khi thiết kế một chiến lược dự phòng. Lưu ý rằng những câu hỏi này đều tập trung vào khía cạnh khôi phục của sự việc.
- Tôi có thể chịu được bao nhiêu mất mát dữ liệu khi khôi phục cơ sở dữ liệu? Không mất dữ liệu? Một giờ mất dữ liệu có thể chấp nhận được sau khi khôi phục cơ sở dữ liệu không?
- Tôi có cần chuyển tiếp bất kỳ giao dịch nào, tức là thực hiện khôi phục tại thời điểm không?
- Tôi có cần khôi phục nội dung của một lược đồ trong khi giữ nguyên các lược đồ khác không?
- Tôi phải mất bao lâu để thiết lập và chạy cơ sở dữ liệu sau khi bị lỗi?
- Tôi cần phải khắc phục những loại lỗi nào? Rõ ràng, tôi cần có khả năng khôi phục sau sự cố máy chủ hoàn toàn hoặc mất đĩa. Tuy nhiên, tôi có cần khôi phục lại những lỗi do con người gây ra như ai đó vô tình xóa bảng không?
- Tôi có được yêu cầu khôi phục bản sao lưu vào các máy chủ khác như một phần của quá trình làm mới cơ sở dữ liệu phát triển hoặc thử nghiệm từ bản sao sản xuất không?
Nếu bạn hỏi hầu hết mọi người trong cộng đồng Oracle những ngày này, họ sẽ cho bạn biết sử dụng RMAN để sao lưu cơ sở dữ liệu của bạn. RMAN là một sản phẩm tuyệt vời và tốt hơn so với các bản sao lưu nóng hoặc lạnh do người dùng quản lý kiểu cũ. Một số Oracle DBA sẽ yêu cầu bạn sử dụng RMAN để thực hiện sao lưu nóng và chạy cơ sở dữ liệu sản xuất của bạn ở chế độ nhật ký lưu trữ. Bằng cách đó, bạn sẽ bao gồm nhiều tình huống khôi phục mà bạn có thể phải đối mặt. Nhưng điều gì sẽ xảy ra nếu câu trả lời của bạn cho câu hỏi 4 là bạn có 1 giờ để sao lưu và chạy và cơ sở dữ liệu của bạn có kích thước 10TB. Chúc bạn may mắn khi cố gắng khôi phục hoàn toàn cơ sở dữ liệu 10TB trong 1 giờ với RMAN. Và RMAN sẽ không thể trả lời câu hỏi 3 vì RMAN không sao lưu ở cấp giản đồ.
DBA có nhiều công cụ để sao lưu và khôi phục dữ liệu trong cơ sở dữ liệu. Những công cụ đó bao gồm, nhưng cũng không giới hạn:
- Trình quản lý khôi phục của Oracle (RMAN)
- Bản sao lưu do người dùng Oracle quản lý
- Xuất / nhập Oracle hoặc Bơm dữ liệu
- Ảnh chụp nhanh dựa trên đĩa
- Sao chép dựa trên đĩa
- Bảo vệ dữ liệu của Oracle
Vậy bạn sử dụng cái nào? Mỗi thứ đều có ưu và nhược điểm. Khi bạn biết các yêu cầu khôi phục của mình, các công cụ để sao lưu cơ sở dữ liệu của bạn bắt đầu trở nên rõ ràng hơn. Và bạn có thể cần sử dụng nhiều hơn một công cụ sao lưu để đáp ứng tất cả các yêu cầu khôi phục của mình. Nếu bạn sử dụng, như một số gợi ý, RMAN với chế độ Nhật ký lưu trữ và không có gì khác, và người quản lý của bạn đến gặp bạn và nói "bạn cần sao lưu cơ sở dữ liệu 10TB này và chạy trong 1 giờ!" công việc của bạn cũng có thể đang hoạt động tốt.
Dẫn đến điểm tiếp theo, hãy ghi lại các yêu cầu khôi phục của bạn và đưa chúng vào Thỏa thuận mức dịch vụ (SLA) của bạn. Khi viết và kiểm tra SLA, ban quản lý của bạn có thể nói rằng họ không muốn mất dữ liệu. Tại thời điểm này, bạn có thể đưa ra những ưu và nhược điểm của việc triển khai giải pháp không mất dữ liệu… và cũng đề cập đến chi phí! Nhiều công ty phải trả giá cao cho giải pháp không mất dữ liệu nhưng đối với các công ty khác, chi phí này rất nhỏ khi so sánh với gánh nặng tài chính của việc mất bất kỳ giao dịch nào. Đây là lúc mà việc mặc cả và đổi hàng phát huy tác dụng. Nếu ban quản lý nhấn mạnh vào một giải pháp không mất dữ liệu, thì họ phải tìm ra quỹ để hỗ trợ nó vì RMAN (miễn phí) sẽ không cung cấp nó. Khi bạn đã ghi lại các yêu cầu khôi phục trong SLA, thì ban quản lý sẽ khó yêu cầu bạn khôi phục thứ gì đó mà chiến lược sao lưu của bạn không được thiết kế để hỗ trợ. Nếu SLA được đưa ra và họ yêu cầu bạn khôi phục mọi giao dịch đơn lẻ và chiến lược sao lưu của bạn không cho phép điều đó, thì bạn sẽ có một tài liệu nói rằng không bao giờ cần mất dữ liệu và điều này có thể giúp tiết kiệm công việc của bạn.
Điều đó đang được nói, khi bạn đã ghi lại các yêu cầu khôi phục của mình trong SLA, hãy đảm bảo rằng chiến lược sao lưu của bạn sẽ cho phép bạn thực hiện mọi tình huống khôi phục được ghi lại trong SLA. Công việc của bạn có thể phụ thuộc vào nó. Nếu SLA cho biết không mất dữ liệu và bạn không triển khai Data Guard mặc dù ban quản lý sẵn sàng cấp vốn cho nó, thì họ có thể chấm dứt hoạt động của bạn vì bạn không tuân thủ công việc của mình.
Cuối cùng, không có chiến lược sao lưu / phục hồi nào là hoàn chỉnh trừ khi nó được kiểm tra kỹ lưỡng. Bạn nên thử nghiệm mọi chiến lược khôi phục được yêu cầu để đảm bảo rằng bạn có thể đáp ứng tất cả các yêu cầu được nêu trong SLA. Thử nghiệm nên được thực hiện không ít hơn một lần một năm vì hai lý do… một, đảm bảo rằng các thay đổi đối với hệ thống không tác động tiêu cực đến khả năng thực hiện khôi phục bắt buộc của bạn và hai là giúp bạn cập nhật về cách thực hiện khôi phục để nếu bạn phải làm điều đó thật, bạn không phải lóng ngóng về thủ tục. Trong quá trình thử nghiệm, bạn có thể thấy rằng phương pháp sao lưu của mình sẽ hỗ trợ các tình huống khôi phục được yêu cầu, nhưng rất tốt nếu bạn cần chúng.
Và tôi không thể nói đủ… Thử nghiệm, thử nghiệm và thử nghiệm!