Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.
MSSQL_BACKUP_VERIFY_CHECKSUM 1С:Предприятие и СУБД

Проверка целостности бэкапов MSSQL: RESTORE VERIFYONLY и CHECKSUM

Обновлено: 26.08.2026  ·  Официальная база знаний

Классическая катастрофа администратора — обнаружение повреждения файла бэкапа в момент аварии:

  • Ошибка RESTORE detected an error on page (0:0) in file... (Error 3183 / 3013) при попытке восстановить продакшн;
  • Бэкап завершился без ошибок ОС, но внутри содержит битые страницы, прочитанные с деградировавшего диска;
  • Отсутствие уверенности в непрерывности цепочки LSN в архивах журналов транзакций.

1. Создание бэкапа с вычислением контрольных сумм страниц

Параметр CHECKSUM заставляет SQL Server проверять контрольные суммы каждой страницы перед записью в файл архива:

BACKUP DATABASE [ERP_1C]
TO DISK = N'E:\Backup\ERP_1C_Validated.bak'
WITH CHECKSUM, STOP_ON_ERROR, STATS = 10;

2. Проверка валидности файла резервной копии через RESTORE VERIFYONLY

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

RESTORE VERIFYONLY
FROM DISK = N'E:\Backup\ERP_1C_Validated.bak'
WITH CHECKSUM;

Если бэкап валиден, команда вернет: 'The backup set on file 1 is valid.'

3. Чтение заголовка и списка файлов без восстановления

-- Просмотр общей информации о бэкапе (Lsn, тип, дата)
RESTORE HEADERONLY FROM DISK = N'E:\Backup\ERP_1C_Validated.bak';

-- Просмотр логических и физических имен файлов данных внутри архива
RESTORE FILELISTONLY FROM DISK = N'E:\Backup\ERP_1C_Validated.bak';

4. Автоматизация тестового восстановления (Best Practice)

Единственная 100% гарантия надежности бэкапа — регулярное тестовое восстановление на резервный сервер по расписанию:

RESTORE DATABASE [ERP_1C_TEST]
FROM DISK = N'E:\Backup\ERP_1C_Validated.bak'
WITH MOVE N'ERP_1C_Data' TO N'T:\TestData\ERP_1C_Test.mdf',
MOVE N'ERP_1C_Log' TO N'T:\TestData\ERP_1C_Test.ldf',
REPLACE;

-- Проверка целостности восстановленной копии
DBCC CHECKDB ([ERP_1C_TEST]) WITH NO_INFOMSGS;

-- Удаление тестовой базы
DROP DATABASE [ERP_1C_TEST];
Практический опыт инженера: Включите опцию CHECKSUM во всех планах обслуживания резервного копирования. Затраты CPU составляют менее 2-3%, но это гарантирует, что поврежденные на диске данные не попадут в бэкап незамеченными.

Частые вопросы (FAQ)

Гарантирует ли успешный RESTORE VERIFYONLY, что в базе нет логических ошибок?

Нет. RESTORE VERIFYONLY проверяет только то, что архив физически прочитан и контрольные суммы страниц сходятся. Логическую целостность индексов и бизнес-таблиц может проверить только DBCC CHECKDB на реально развернутой базе.

Что делает параметр CONTINUE_AFTER_ERROR при создании бэкапа?

Он принуждает SQL Server продолжить создание бэкапа, даже если обнаружена битая страница с ошибкой Checksum. Это позволяет спасти уцелевшие 99% данных при аварии, пометив испорченные страницы в заголовке архива.

Почему RESTORE VERIFYONLY занимает столько же времени, сколько реальное восстановление?

Потому что утилита вычитывает весь файл архива с диска в память целиком, чтобы пересчитать контрольные суммы каждого 8KB блока. Нагружается дисковое чтение и CPU.

Как проверить валидность пароля или шифрования в бэкапе?

RESTORE VERIFYONLY с опцией CHECKSUM проверит доступность сертификата шифрования. Если сертификат отсутствует на целевом сервере, команда немедленно вернет ошибку дешифрации.