Часть 1. Настройка резервного копирования ms sql. Ошибки и заблуждения

Настройка резервного копирования ms sql, это одна из первых задач которая приходит в голову, когда задумываешься о последствиях утраты рабочих баз данных. Зачастую у многих администраторов именно с решения этой задачи начинается первое знакомство с SQL Server Management Studio (SSMS) и языком Transact SQL (T-SQL). Этой публикацией мы решили начать цикл статей, посвященных типовым ошибкам и заблуждениям. Мы не будем описывать как по шагам выполнить настройку резервного копирования, а остановимся на тех важных моментах, которым обычно не уделяется должного внимания, что в итоге сводит на нет всю настройку резервного копирования ms sql.

Заблуждение: Мне достаточно лишь настроить бэкапы …

Так обычно думают те, кто впервые сталкивается с этим вопросом. Однако, все далеко не так просто, как кажется на первый взгляд. Приведу минимальный перечень вопросов, с которыми придётся разобраться:

1. Какова ваша стратегия резервного копирования?
2. Что такое модель восстановления баз данных и какую модель выбрать?
3. Куда лучше складывать файлы бэкапов и как их проверять?
4. За какой промежуток времени хранить резервные копии?
5. Как настроить регулярную проверку целостности БД на SQL Server?
6. Как настроить email-уведомления об ошибках?

Практически каждому вопросу имеется свой перечень заблуждений и типовых ошибок.

Ошибка: Выбирается неверная стратегия резервного копирования и восстановления

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

Необходимо заметить, что SQL Server позволяет восстанавливать базы данных не только на тот момент, когда была создана её полная резервная копия (бэкап), но и на любой другой момент времени. Для этого в SQL Server есть механизм журнала транзакций. Суть механизма проста – все запросы на изменение данных, которые получает SQL Server, регистрируются в журнале транзакций. При этом журнал должен периодически бэкапиться. Делается это быстро и незаметно для пользователей. В случае сбоя восстанавливается вся цепочка по очереди: вначале полная резервная копия базы данных, а затем резервные копии журнала. В итоге база данных будет восстановлена на момент бэкапа последнего журнала транзакций.

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

Ошибка: Полная модель восстановления без резервной копии журнала транзакций

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

Заблуждение: Полная модель восстановления является менее производительнее чем Простая

Какой-то ощутимой разницы в производительности между Полной и Простой моделью восстановления нет. Нужно сказать, что данные в журнал транзакций записываются при любой модели восстановления. Однако если при Простой модели восстановления файл журнала автоматически усекается.

Ошибка: Не настроены уведомления администратора

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

Нужно отметить один неприятный момент: уведомления, которые отправляет штатный компонент DataBase Mail не содержат информации об ошибке. Поэтому после его получения, для того чтобы понять серьезность ошибки, администратору приходится каждый раз смотреть логи SQL Server. К сожалению, со временем многие администраторы перестают обращать внимания на ошибки и своевременно реагировать на них. По закону жанра именно в такой момент база летит в тартарары.

Продолжение следует…