Понимание влияния / риска отключения «проверки целостности резервной копии» на резервную копию SQL

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

Некоторые из резервных копий выполняются очень долго, поэтому я рекомендовал отключить эту опцию, но руководству необходимо, чтобы я документировал влияние и риски этого изменения.

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

Я ошибаюсь? Это минимальный риск выключить это, если я делаю резервную копию на диск, а не на потоковую ленту или что-то? (Мы выполняем резервное копирование по сети на устройство резервного копирования EMC DD-800, если это необходимо.)

Существуют ли официальные рекомендации MS для случаев, когда это безопасно отключить?

Вы запускаете «проверять» на каждой резервной копии в вашей среде? Вы их проверяете?

РЕДАКТИРОВАТЬ : Чтобы уточнить, когда вы проверяете «проверить целостность резервной копии» в плане обслуживания, SQL будет выполнять полное ВОССТАНОВЛЕНИЕ ПРОВЕРЕНО для каждой базы данных сразу после каждого резервного копирования. Это так же интенсивно использует данные / ввод-вывод, как и исходное резервное копирование, и (в основном) удваивает общее время задания резервного копирования. Это не то же самое, что включение опции «контрольной суммы» для резервного копирования (насколько я знаю, этого нельзя сделать в мастере).

Я ошибаюсь? Это минимальный риск выключить это, если я делаю резервную копию на диск, а не на потоковую ленту или что-то?

Нет, вы правы :-)

RESTORE VERIFYONLYТолько не гарантирует, что вы сможете восстановить свою базу данных в случае повреждения. По своей природе он не будет выполнять никаких проверок целостности.

Лучшим способом будет периодически создавать резервные копии, выполнять правильное восстановление на другом сервере и выполнять на нем DBCC CHECKDB.

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

Из блога Мифа Пола Рэндала

24p) с помощью RESTORE… WITH VERIFYONLY проверяет всю резервную копию

Нет. Использование VERIFYONLY только проверяет, что резервный заголовок выглядит как резервный заголовок. Только когда вы берете резервную копию с помощью WITH CHECKSUM и выполняете RESTORE… WITH VERIFYONLY и с помощью CHECKSUM, восстановление выполняет более обширные проверки, включая контрольную сумму всей резервной копии.

Вы запускаете «проверять» на каждой резервной копии в вашей среде? Вы их проверяете?

Я не управляю VERIFYONLY. Вместо этого я беру резервную копию с CHECKSUM, а затем восстанавливаю их + CHECKDB на другом сервере. Вы можете использовать подход статистической выборки для проверки резервных копий базы данных, если хотите проявить творческий подход.

Это не то же самое, что включение опции «контрольной суммы» для резервного копирования (насколько я знаю, этого нельзя сделать в мастере).

Вы можете включить Trace Flag 3023, чтобы CHECKSUMопция автоматически включалась для команды BACKUP. Как всегда, проверьте поведение любых флагов трассировки в вашей среде!

Суть в том, чтобы отказаться от планов обслуживания и использовать более разумное решение для резервного копирования (подсказка: решение для резервного копирования Ola) , которое позволит вам настроить его в соответствии с вашими потребностями.

(Мы выполняем резервное копирование по сети на устройство резервного копирования EMC DD-800, если это необходимо.)

Выполните локальное резервное копирование на диск, а затем выполните задание передачи PowerShell, которое скопирует резервную копию локально с сервера на сетевой ресурс (сервер резервного копирования). Это будет быстрее, чем прямое копирование в сетевой ресурс.

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

Хорошее чтение будет: Резервные копии: планирование стратегии восстановления

Суть в том, что если вы не выполните восстановление базы данных где-либо, вы не можете быть полностью уверены, что данный файл резервной копии хорош.

Идеальный тест для проверки ваших резервных копий - это создание среды, в которой резервные копии базы данных и резервные копии журналов базы данных будут постоянно восстанавливаться как часть вашего повседневного процесса. Это одно из преимуществ использования log-shipping ...

Если вы все еще хотите придерживаться только проверки, вы можете настроить среду специально для этого. Это позволит снять нагрузку с вашего (предположительно) рабочего сервера и сократить время работы.

Наконец, вы рассматривали возможность отказа от планов обслуживания? Сценарии, подобные сценариям Олы, за исключением резервного копирования и обслуживания: https://ola.hallengren.com/

Технически восстановление, по сути, похоже на выполнение восстановления, однако нет лучшей проверки, чтобы фактически восстановить базу данных, чтобы проверить ее действительную резервную копию. У нас был случай, когда проверка только прошла, но база данных не восстановилась бы из-за повреждения, я хочу сказать, что в качестве подтверждения резервное копирование не стоит. Сейчас мы разработали систему, которая восстанавливает все наши базы данных в отдельном экземпляре для проверки их достоверности, очевидно, что это не всегда возможно, поэтому попробуйте выполнить выборку определенной базы данных в неделю. Длинные и короткие не доверяют только на 100%.