Плюсы и минусы стратегий резервного копирования SQL Server и соответствующие сценарии их использования

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

1. Полная резервная копия
2. Дифференциальное резервное копирование
3. Доставка журналов

Каковы плюсы и минусы каждой стратегии и в каких ситуациях их следует использовать?

Доставка журналов не является сценарием резервного копирования. Это сценарий полу высокой доступности.
Для резервных копий предусмотрены полные, дифференциальные и журналы транзакций. Все они должны использоваться вместе. Ваш SLA определяет, как вы их используете. Наиболее типичными сценариями являются полное резервное копирование, скажем, в полночь, разностное резервное копирование в полдень и резервное копирование журнала транзакций каждые 30 или 15 минут.

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

Возможно, такого понятия, как стратегия резервного копирования, не существует: у вас есть стратегия восстановления , поскольку она определяет, как долго вы вернетесь к работе *.

Все стратегии требуют полного резервного копирования для создания любых последующих восстановлений разностных и / или журнальных резервных копий.

На практике вы можете создать полную резервную копию с 6 месяцев назад с 15-минутными резервными копиями журналов: однако вам придется применять каждую резервную копию журнала с момента последнего полного резервного копирования.

В качестве случайного примера, один сценарий может быть полным еженедельно, разностным ежедневно, протоколировать 15 минут.

Интервал резервного копирования определяет, сколько данных вы потеряете в худшем случае: 15-минутное резервное копирование журнала дает вам потерю данных от 1 секунды до 14 минут 59 секунд, в среднем 7,5 минут. Это приемлемо?

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

Не существует единой стратегии, подходящей для любой ситуации. Но важно понимать, что у вас есть в наличии. Полные резервные копии - это именно то, на что они похожи: полная резервная копия вашей базы данных за вычетом журнала транзакций. Разностные резервные копии - это резервные копии изменений в файлах данных с момента последнего полного резервного копирования. Резервные копии журнала транзакций будут резервировать все транзакции, хранящиеся в журнале транзакций с момента последнего резервного копирования журнала транзакций. Резервные копии журнала транзакций позволят вам восстановить данные на определенный момент времени. Если это требование, вам необходимо установить режим восстановления «Полный», и вам потребуется регулярно создавать резервные копии журнала транзакций в зависимости от того, сколько данных вы готовы потерять в случае возникновения ситуации восстановления.

При работе с резервными копиями журнала транзакций важно понимать, что такое цепочка журналов. По моим словам, цепочка журналов - это серия резервных копий, которые необходимо восстановить, чтобы восстановить базу данных до определенного момента времени. Чтобы начать восстановление журналов транзакций, сначала необходимо восстановить полную резервную копию с помощью параметра WITH NORECOVERY. Если вы также выполняете разностное резервное копирование, вам нужно будет восстановить самое последнее разностное резервное копирование до того момента, когда вы хотите восстановить, используя тот же параметр WITH NORECOVERY. На этом этапе вам нужно будет последовательно восстанавливать резервные копии журнала транзакций, используя опцию WITH NORECOVERY для всех резервных копий, кроме последней. Для получения дополнительной информации о восстановлении на определенный момент времени перейдите по этой ссылке. http://msdn.microsoft.com/en-us/library/ms175093.aspx

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

Надеюсь это поможет,

Matt

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

это не стратегии резервного копирования для SQL Server. Полные и разностные резервные копии - это типы резервных копий, которые можно делать с базой данных SQL Server, в то время как доставка журналов является стратегией высокой доступности (путем перемещения резервных копий журналов в запланированное время с сервера на другой и синхронизации этих двух баз данных до предел ваших резервных копий).

Хорошую информацию о Disaster Recovery (резервное копирование и восстановление :-)) вы можете найти на MSDN: здесь и здесь . Короче говоря, вам нужно выбрать, сколько данных вы можете восстановить из резервных копий в случае сбоя. Разумным примером стратегии резервного копирования будет полное резервное копирование каждый день и резервное копирование журнала каждый час (это зависит от ваших потребностей), поэтому в этом случае вы сможете восстановить базу данных из полной резервной копии + все ежедневные резервные копии журнала.

Еще одну хорошую ссылку на DR вы можете найти на Simple_Talk .

Конечно, вам нужно не только восстановить базу данных, но и восстановление в контексте сервера и приложения, частью которого является база данных. Я еще не использовал его сам, но Data Protection Manager надеется сделать более полную работу, если вам это нужно.

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

Например, если ваша база данных быстро растет, вы можете использовать следующую стратегию резервного копирования SQL Server: полное резервное копирование - один раз в день, разностное резервное копирование - каждые два часа и резервное копирование журнала транзакций - каждые 20 минут. В этом случае, если произойдет сбой, вы потеряете не более 19 минут своей работы. Другой пример: если ваша база данных медленно растет, вы можете выполнять полное резервное копирование один раз в день, разностное резервное копирование каждые шесть часов и каждый час делать резервные копии журнала транзакций.

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