Тема 5.5 Резервное копирование базы данных и последующее восстановление Резервное копирование базы данных и последующее восстановление

Резервное копирование — один из самых надежных способов сохранить данные от потери или порчи и обеспечить достоверность информации в процессе хранения. Процесс резервного копирования также делается в профилактических целях для увеличения производительности БД — это достигается за счет того, что в момент копирования происходит считывание последних версий всех записей, старые же версии в копию никогда не попадают. Отметим, что одного лишь резервного копирования недостаточно — надо иногда проверять восстанавливаемость БД из резервной копии.

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

• при случайном или злоумышленном использовании оператора DELETE;

• при случайном или злоумышленном использовании оператора UPDATE — например, без использования WHERE оператора вместе с оператором UPDATE (все записи будут обновлены вместо одной строки определенной таблицы);

• с деструктивными вирусами;

• при стихийном бедствии, таком как пожар, наводнение и т. д.;

• с воровством.

Если существует стратегия резервного копирования, то можно восстановить данные с минимальными потерями рабочего времени и минимизировать вероятность безвозвратной потери данных Стратегия резервного копирования должна вернуть систему обратно в то состояние, которое было до наступления проблемы.

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

Частота резервирования данных зависит от количества данных, которые можно потерять, и величины активности базы данных. Когда резервируется пользовательская БД, рассматривается следующие факты и рекомендации:

• резервировать БД чаще, если система работает в окружении OLTP;

• резервировать данные реже, если система имеет маленькую активность или используется для принятия решений;

• запланировать резервное копирование, когда SQL Server бездействует или сильно обновлен;

• автоматизировать процесс, используя Database Maintenance Plan Wizard.

Модели восстановления базы данных

Изменить модель восстановления БД можно в любое время, не нужно планировать модель восстановления при создании БД.

Сервер SQL имеет три модели восстановления БД; каждая из них сохраняет данные в момент ошибки сервера, различие только в том, как SQL Server восстанавливает данные, как хранит и сколько требуется затрат производительности в момент ошибки диска.

Full Recovery Model— полная модель восстановления. Модель полного восстановления следует использовать, когда необходимо полное восстановление с поврежденного носителя. Эта модель использует копию БД и всей информации журнала для восстановления БД. Сервер SQL журнализирует все изменения в БД, включая массивные операции и создание индексов. Если журнал транзакций не испорчен, то можно восстановить все данные, источая транзакции, которые были активны в момент ошибки.

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

Bulk Logged - модель восстановления. Подобно полной модели восстановления, Bulk Logged - модель использует одновременно зарезервированную БД и журнал для воссоздания БД, при этом требуется гораздо меньшее пространство журнала для следующих операций: CREATE INDEX, операции массовой загрузки, SELECT INTO, WRITETEXT и UPDATATEXT. Журнал записывает только факт происшествия операции без записи детальной информации.

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

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

Простая модель восстановления применяется для небольших БД и в тех базах, где изменения происходят редко. Эта модель использует полную или дифференцированную копию БД и восстановление ограничено только восстановлением БД на момент последнего резервного копирования. Все изменения, внесенные после резервного копирования, теряются и требуют повторного создания. Главное преимущество этой модели — меньший раз мер носителя и простота внедрения этой модели.

Создание модели восстановления базы данных. По умолчанию SQL Server Standard Edition SQL Server и Enterprise Edition используют полную модель восстановления. Можно изменить модель в любой момент времени, но необходимо произвести дополнительное резервное копирование на момент изменения. Для определения того, какую модель использует БД, применяется функция DATABASEPROPERTYEX.