Мы продолжаем цикл статей, посвященный типовым ошибкам и заблуждениям при настройке резервного копирования баз данных на Microsoft SQL Server. Начало см. Часть 1. Часть 1
У любой базы данных MS SQL есть как минимум два файла – данные, файл с расширением mdf, и журнал транзакций, файл с расширением log. Обрабатывая транзакции SQL Server постоянно синхронизирует информацию в этих файлах, поэтому они всегда находятся в заблокированном состоянии. Нет штатной возможности скопировать эти файлы у подключенной базы данных, даже если в ней никто не работает. Сторонние программы для бэкапирования файлов и образов также не могут скопировать эти файлы привычным образом, а фактически делают резервную копию инструкцией BACKUP DATABASE (обычно через VDI интерфейс). Часто это делается без ведома администратора, что нарушает цепочку резервных копий и является большим, неприятным, "сюрпризом" при попытке восстановления БД.
Размещение резервных копий на одном диске вместе с файлами данных чревато тем, что при выходе жёсткого диска из строя у вас не будет ни файлов баз данных, ни их резервных копий. В независимости на сколько надежный у вас используется RAID, никогда не следует размещать резервные копии на одном физическом диске с файлами баз данных.
Командой RESTORE VERIFYONLY можно проверить полноту резервной копии и возможность её считывания с диска. Обычно инструкция выполняется сразу после создания резервной копии. Однако необходимо знать, что команда RESTORE VERIFYONLY не проверяет структуру данных. Другими словами, успешное выполнение инструкции RESTORE VERIFYONLY не гарантирует, что реальное восстановление из резервной копии будет выполнено без ошибок. Есть только один 100% способ проверить резервные копии – попробовать восстановить из них. Поэтому рекомендуется периодически проверять резервные копии восстанавливая из них.
QMB позволяет автоматизировать процесс регулярной проверки резервных копий через восстановление. Причем такое восстановление может выполняться как на SQL Server источнике (во временную базу данных), так и на любом другом тестовом SQL Server.
Довольно часто приходится сталкиваться с ситуацией, когда администратор создает свежую полную резервную копию (без параметра COPY_ONLY), чтобы передать её на сторону. При этом после передачи файл резервной копии удаляется, несмотря на то, что для базы данных используется полная модель восстановления и создаются резервные копии журнала транзакций. Таким образом, восстановление на актуальный момент времени становится не возможным. Необходимо помнить простое правило: Если у базы данных используется Полная модель восстановления, то создание полной резервной копии без параметра COPY_ONLY, начнет новую цепочку резервных копий. Этот файл нельзя удалять, до того момента пока не будет создана новая полная резервная копия. Если вы хотите создать полную резервную копию и удалить её после передачи, то создавайте её с параметром COPY_ONLY. В QMB для этого следует установить признак «Только для копирования» см. рис.
При создании XML плана восстановления QMB автоматически выполняет проверку физического наличия файлов резервных копий, необходимых для восстановления. Это позволяет превентивно выявлять подобные ошибки нехватки нужного файла.