Розуміння впливу / ризику відключення "перевірити цілісність резервного копіювання" на резервну копію SQL

В даний час ми використовуємо стандартні плани технічного обслуговування резервних копій на серверах SQL Server 2005/2008 / 2008R2 / 2012 в нашому середовищі, і прапорець "Перевірити цілісність резервного копіювання" завжди перевірявся.

Деякі резервні копії працюють дуже довго, тому я рекомендував вимкнути цю опцію, але менеджмент потребує мене, щоб задокументувати вплив та ризики цієї зміни.

Я розумію використання та історію використання цієї опції, мені просто видається непотрібним подвоювати час виконання завдання резервного копіювання, коли (на мій погляд) будь-яка помилка, яка, можливо , станеться під час кроку резервного копіювання , а не під час перевірки.

Я помиляюся? Чи мінімальний ризик вимкнути це, якщо я створюю резервну копію на диск, а не на потокову стрічку чи щось таке? (Ми створюємо резервну копію по мережі на пристрій резервного копіювання EMC DD-800, якщо це доречно.)

Чи є якісь офіційні рекомендації для MS, коли безпечно вимкнути це?

Ви запускаєте "перевірити" на кожному резервному копії у вашому оточенні? Ви їх на місці перевіряєте?

РЕДАКТУВАННЯ : Для уточнення під час перевірки "перевірки цілісності резервного копіювання" в плані технічного обслуговування SQL виконає повне ВІДНОВЛЕННЯ ВЕРСІЙНО на кожній базі даних відразу після кожної резервної копії. Це так само, як дані / введення-виведення, як і оригінальна резервна копія, і (в основному) подвоює загальний час виконання завдання резервного копіювання. Це не те саме, що включити параметр "контрольна сума" при резервній копії (що, наскільки я знаю, неможливо зробити у майстра).

Я помиляюся? Чи мінімальний ризик вимкнути це, якщо я створюю резервну копію на диск, а не на потокову стрічку чи щось таке?

Ні, ви праві :-)

RESTORE VERIFYONLYтільки не забезпечить можливість відновлення вашої бази даних у разі пошкодження. За своєю природою він не проводитиме жодних перевірок цілісності.

Кращий спосіб буде періодично робити резервні копії та робити дійсне відновлення на іншому сервері та виконувати на ньому DBCC CHECKDB.

Це одна з причин, чому я не є великим шанувальником планів технічного обслуговування, оскільки графічний інтерфейс не відкриває багато таких варіантів, backup .. with CHECKSUMякі можна досягти T-SQL.

З блогу Міфа Пола Рандала

24p) за допомогою RESTORE… З VERIFYONLY перевіряє всю резервну копію

Ні. Використання VERIFYONLY лише перевіряє заголовок резервної копії, схожий на заголовок резервної копії. Лише тоді, коли ви берете резервну копію, використовуючи кнопку CHECKSUM і виконайте ЗАВДАННЯ… З ВЕРІФІОНАЛЬНОСТІ та використання CHECKSUM, відновлення робить більш обширні перевірки, включаючи контрольну суму по всій резервній копії.

Ви запускаєте "перевірити" на кожному резервному копії у вашому оточенні? Ви їх на місці перевіряєте?

Я не запускаю ВЕРИФІОННО. Натомість я беру резервну копію з CHECKSUM, а потім відновлюю їх + CHECKDB'ed на іншому сервері. Ви можете дотримуватися статистичної вибірки для перевірки резервного копіювання бази даних, якщо ви хочете проявити творчість.

Це не те саме, що включити параметр "контрольна сума" при резервній копії (що, наскільки я знаю, неможливо зробити у майстра).

Можна включити Traice Flag 3023, щоб CHECKSUMпараметр був автоматично включений для команди BACKUP. Як завжди, перевіряйте поведінку будь-яких прапорів слідів у вашому оточенні!

Суть полягає в - плані технічного обслуговування канави та використання більш розумного рішення щодо резервного копіювання (підказка: рішення резервного копіювання Ola), яке дозволить вам налаштувати його відповідно до ваших потреб.

(Ми створюємо резервну копію по мережі на пристрій резервного копіювання EMC DD-800, якщо це доречно.)

Створіть резервну копію локально на диску, а потім отримайте завдання передачі PowerShell, яке скопіює локальну копію з сервера на мережевий пай (резервний сервер). Це буде швидше, ніж безпосередньо копіювати на загальну мережу.

Крім того, увімкніть миттєву ініціалізацію файлів, що допоможе в автоматичному зростанні файлів даних, а також допоможе скоротити час відновлення (у випадку, якщо вам доведеться відновити бази даних). Завжди добре мати варіанти під рукою.

Добре прочитати буде: Резервне копіювання: Планування стратегії відновлення

Суть полягає в тому, що, якщо ви десь не відновите базу даних, ви не можете бути повністю впевнені, що даний файл резервної копії хороший.

Ідеальний тест для перевірки ваших резервних копій - це налаштування середовища, де резервні копії бази даних та резервні копії журналу бази даних весь час відновлюються як частина вашого щоденного процесу. Це одна з переваг використання журналу доставки ...

Якщо ви все ще хочете дотримуватися verifyonly, ви можете створити середовище саме для цього. Це призведе до завантаження роботи з вашого (імовірно) виробничого сервера та скоротить час роботи.

Нарешті, ви думали про відхід від планів обслуговування? Сценарії, такі як сценарії Ola, крім резервного копіювання та обслуговування: https://ola.hallengren.com/

Технічно відновлення verfyonly - це як виконання відновлення, однак немає кращої перевірки, що насправді відновлює базу даних, щоб перевірити її дійсну резервну копію. У нас був екземпляр, коли верифікація передана лише через те, що база даних не відновиться через корупцію, я не думаю, що це не вважається як перевірка резервної копії. Зараз ми розробили систему, яка відновлює всі наші бази даних в окремому екземплярі, щоб перевірити їх достовірність, очевидно, що це не завжди можливо, тому спробуйте відібрати вибірку певної бази даних на тиждень. Довгі і короткі не довіряють перевіреним лише 100%.