Hiểu về tác động / rủi ro của việc tắt tính năng xác minh sao lưu trực tuyến trên bản sao lưu SQL


12

Hiện tại chúng tôi sử dụng các gói bảo trì tiêu chuẩn để sao lưu trên các máy chủ SQL Server 2005/2008 / 2008R2 / 2012 trong môi trường của chúng tôi và hộp "Xác minh tính toàn vẹn sao lưu" luôn được kiểm tra.

Một số bản sao lưu chạy rất lâu, vì vậy tôi đã khuyên bạn nên tắt tùy chọn đó, nhưng ban quản lý cần tôi ghi lại tác động và rủi ro của thay đổi này.

Tôi hiểu việc sử dụng và lịch sử của tùy chọn này, có vẻ như tôi không cần thiết phải tăng gấp đôi thời gian cho công việc sao lưu khi (theo ý kiến ​​của tôi), bất kỳ lỗi nào có thể xảy ra sẽ xảy ra trong bước sao lưu , không phải trong quá trình xác minh.

Tôi có lầm không? Có phải là rủi ro tối thiểu để tắt cái này không, nếu tôi đang sao lưu vào đĩa và không phát trực tuyến băng hoặc cái gì đó? (Chúng tôi sao lưu qua mạng vào thiết bị sao lưu EMC DD-800, nếu điều đó có liên quan.)

Có bất kỳ khuyến nghị chính thức nào của MS khi an toàn để tắt tính năng này không?

Bạn có chạy "xác minh" trên mọi bản sao lưu trong môi trường của mình không? Bạn có kiểm tra chúng không?

EDIT : Để làm rõ, khi bạn kiểm tra "xác minh tính toàn vẹn sao lưu" trong kế hoạch bảo trì, SQL sẽ thực hiện HOÀN TOÀN PHỤC HỒI đầy đủ trên mỗi cơ sở dữ liệu ngay sau mỗi lần sao lưu. Đây chỉ là dữ liệu / IO chuyên sâu như sao lưu ban đầu và (về cơ bản) nhân đôi thời gian tổng thể của công việc sao lưu. Điều này không giống như bật tùy chọn "tổng kiểm tra" khi sao lưu (điều này không thể thực hiện được trong trình hướng dẫn, theo như tôi biết).


Cảm ơn mọi người. Thêm một liên kết nữa để tham khảo của riêng tôi, về việc sử dụng cờ theo dõi để bật tổng kiểm tra trên các bản sao lưu, ngay cả khi sử dụng các gói bảo trì SQL: nebraskasql.blogspot.com/2014/03/
BradC

Câu trả lời:


5

Tôi có lầm không? Có phải là rủi ro tối thiểu để tắt cái này không, nếu tôi đang sao lưu vào đĩa và không phát trực tuyến băng hoặc cái gì đó?

Không, bạn đúng :-)

RESTORE VERIFYONLYchỉ không đảm bảo rằng bạn sẽ có thể khôi phục cơ sở dữ liệu của mình trong trường hợp tham nhũng. Về bản chất, nó sẽ không thực hiện bất kỳ kiểm tra tính toàn vẹn.

Một cách tốt hơn sẽ là định kỳ lấy các bản sao lưu của bạn và thực hiện khôi phục hợp lệ trên một máy chủ khác và thực hiện DBCC CHECKDB trên đó.

Đây là một lý do, tại sao tôi không phải là một fan hâm mộ lớn của các kế hoạch bảo trì vì GUI không đưa ra nhiều tùy chọn như backup .. with CHECKSUMT-SQL có thể đạt được.

Từ blog Huyền thoại của Paul Randal

24p) bằng cách sử dụng RESTORE B WITHNG XÁC MINH xác thực toàn bộ bản sao lưu

Không. Sử dụng VERIFYONLY chỉ xác nhận tiêu đề sao lưu trông giống như tiêu đề sao lưu. Chỉ khi bạn thực hiện sao lưu bằng cách sử dụng VỚI KIỂM TRA và thực hiện PHỤC HỒI VỚI XÁC MINH sử dụng VỚI KIỂM TRA thì việc khôi phục sẽ kiểm tra rộng hơn, bao gồm cả tổng kiểm tra trên toàn bộ bản sao lưu.

Bạn có chạy "xác minh" trên mọi bản sao lưu trong môi trường của mình không? Bạn có kiểm tra chúng không?

Tôi không chạy XÁC MINH. Thay vào đó, tôi sao lưu bằng CHECKSUM và sau đó khôi phục chúng + CHECKDB trên một máy chủ khác. Bạn có thể làm theo Phương pháp lấy mẫu thống kê để xác minh phương pháp sao lưu cơ sở dữ liệu nếu bạn muốn sáng tạo.

Điều này không giống như bật tùy chọn "tổng kiểm tra" khi sao lưu (điều này không thể thực hiện được trong trình hướng dẫn, theo như tôi biết).

Bạn có thể bật Trace Flag 3023 để CHECKSUMtùy chọn được bật tự động cho lệnh BACKUP. Như mọi khi, hãy kiểm tra hành vi của bất kỳ cờ theo dõi nào trong môi trường của bạn!

Điểm mấu chốt là - bỏ các kế hoạch bảo trì và sử dụng giải pháp sao lưu hợp lý hơn (gợi ý: giải pháp sao lưu của Ola) sẽ cho phép bạn tùy chỉnh nó dựa trên nhu cầu của bạn.

(Chúng tôi sao lưu qua mạng vào thiết bị sao lưu EMC DD-800, nếu điều đó có liên quan.)

Sao lưu cục bộ vào đĩa và sau đó có công việc chuyển PowerShell sẽ sao chép sao lưu cục bộ từ máy chủ sang chia sẻ mạng (máy chủ dự phòng). Điều đó sẽ nhanh hơn so với việc sao chép trực tiếp vào chia sẻ mạng.

Ngoài ra, kích hoạt khởi tạo tệp tức thì, sẽ giúp tự động tăng trưởng trên các tệp dữ liệu cũng như giúp cắt giảm thời gian khôi phục (trong trường hợp bạn phải khôi phục cơ sở dữ liệu của mình). Nó luôn luôn tốt để có các tùy chọn tiện dụng.

Đọc tốt sẽ là: Sao lưu: Lập kế hoạch chiến lược phục hồi


Cảm ơn câu trả lời chi tiết của bạn. Tôi nghĩ rằng tôi có thể khuyên bạn nên bật tổng kiểm tra khi sao lưu, điều này sẽ bắt được tỷ lệ lỗi cao hơn một chút trong bước sao lưu và hy vọng sẽ bù đắp được rủi ro cao hơn (rất nhẹ) khi bỏ qua BACKUP XÁC MINH. Tôi hiểu những gì bạn đề xuất liên quan đến việc khôi phục thường xuyên trên một máy chủ khác, nhưng do quy mô của môi trường của chúng tôi, điều đó có vẻ không hợp lý, ngoại trừ có lẽ trên cơ sở lấy mẫu.
BradC

@BradC Rất vui vì câu trả lời của tôi hữu ích cho bạn. Ý chính của câu trả lời của tôi là sử dụng TSQLtrái ngược với GUI(duy trì kế hoạch) để bạn có thể tận dụng sự linh hoạt và điều chỉnh nó với bàn tay mở. Giống như FYI .. các kế hoạch bảo trì đã được tăng cường trong SQL Server 2016 CTP 2.4mà MS gọi là Kế hoạch bảo trì thông minh SQL Server - tích hợp các thực tiễn tốt nhất và có thể xác định các chiến lược tối ưu một cách nhanh chóng. Vẫn không có GUI nào có thể đánh bại TSQL :-)
Kin Shah

Cảm ơn @Kin. Tôi quen thuộc với cách tiếp cận tập lệnh hoàn toàn tùy chỉnh từ các môi trường khác, rõ ràng điều đó có thể có vấn đề riêng với lỗi và bảo trì tập lệnh. Chúng tôi đang đánh giá một số tác nhân nén của bên thứ 3, do đó có thể sẽ cần các tập lệnh tùy chỉnh cuối cùng.
BradC

2

Điểm mấu chốt là trừ khi bạn thực hiện khôi phục cơ sở dữ liệu ở đâu đó, bạn không thể hoàn toàn tin tưởng rằng một tệp sao lưu đã cho là tốt.

Thử nghiệm lý tưởng để xác minh các bản sao lưu của bạn là thiết lập một môi trường nơi các bản sao lưu cơ sở dữ liệu và các bản sao lưu nhật ký cơ sở dữ liệu, được khôi phục mọi lúc như một phần của quy trình hàng ngày của bạn. Đây là một trong những lợi thế của việc sử dụng log-Shipping ...

Nếu bạn vẫn muốn gắn bó với xác minh, bạn có thể thiết lập một môi trường cụ thể chỉ để làm điều này. Điều này sẽ giảm tải công việc từ máy chủ sản xuất (có lẽ) của bạn và giảm thời gian công việc.

Cuối cùng, bạn đã xem xét di chuyển ra khỏi kế hoạch bảo trì? Các tập lệnh như tập lệnh của Ola ngoại trừ các bản sao lưu và bảo trì: https://ola.hallengren.com/


Chúng tôi có thể tránh xa các kế hoạch bảo trì trong tương lai, vì chúng tôi đang đánh giá một số tác nhân dự phòng của bên thứ 3 (được tạo để hoạt động với thiết bị sao lưu cụ thể của chúng tôi). Tôi cho rằng những điều này sẽ yêu cầu các tập lệnh tùy chỉnh, tương tự như những gì Ola đã phát triển.
BradC

1

Về mặt kỹ thuật, việc khôi phục verfyonly giống như thực hiện khôi phục, tuy nhiên không có kiểm tra nào tốt hơn là thực sự khôi phục cơ sở dữ liệu để kiểm tra bản sao lưu hợp lệ của nó. Chúng tôi đã có một trường hợp được xác minh thông qua tuy nhiên cơ sở dữ liệu sẽ không khôi phục do tham nhũng, quan điểm của tôi là không coi đây là xác minh sao lưu dự phòng là ổn. Hiện tại chúng tôi đã phát triển một hệ thống khôi phục tất cả các cơ sở dữ liệu của chúng tôi để kiểm tra tính hợp lệ của chúng, rõ ràng không phải lúc nào cũng có thể, vì vậy hãy thử lấy mẫu cơ sở dữ liệu nhất định một tuần. Dài và ngắn không tin tưởng xác thực 100%.


Đúng, nhưng tôi không chắc liệu điều đó có thực sự trả lời câu hỏi của tôi không, vì tôi khuyên bạn nên tắt RESTORE XÁC MINH trong môi trường của chúng tôi. Trừ khi quan điểm của bạn là: "vì chỉ có một khôi phục đầy đủ thực tế sẽ chứng minh rằng sao lưu là khả thi, tắt tùy chọn này không làm tăng đáng kể rủi ro".
BradC

Chính xác, imo kiểm tra thực sự duy nhất là thực sự khôi phục thực tế
Gelder
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.