Какое хорошее расписание резервного копирования SQL Server?

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

• Полные резервные копии базы данных
• Дифференциальные резервные копии базы данных
• Резервные копии журнала транзакций

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

• 1-е число каждого месяца - делайте полную резервную копию базы данных.
• Каждый день в полночь - делать разностное резервное копирование базы данных.
• Каждые 15 минут - Делайтерезервную копию журнала транзакций .

Таким образом, если моя база данных выйдет из строя, скажем, 12-го числа, я просто восстановлю полную резервную копию базы данных с 1-го числа, сделаю 12 разностных резервных копий с 1-го по 12-е, а затем, наконец, восстановлю самый последний журнал транзакций ( журналы транзакций дифференциальные?).

Наконец, является ли полная резервная копия базы данных автономной? т.е. когда я сделаю полное резервное копирование базы данных 1 февраля, могу ли я удалить все файлы с января? Конечно, я бы оставил пару наборов предыдущих месяцев на всякий случай, но вопрос концептуален.

Как и все вещи в SQL Server, это зависит.

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

В «Books Online» есть все подробности , но вот мое резюме.

Полная резервная копия содержит все в базе данных. ДИФФЕРЕНЦИАЛЬНАЯ резервная копия является кумулятивной, НЕ добавочной. В вашем примере, если ваша база данных вышла из строя 12-го числа, вам нужно будет только восстановить полную резервную копию с 1-го, а затем самый последний дифференциал 12-го числа, а затем все резервные копии журнала транзакций вплоть до сбоя. Резервное копирование журнала транзакций требуется только для баз данных, использующих модель полного или массового восстановления. Если вы используете простую модель восстановления, резервное копирование журнала транзакций не требуется.

Теперь, когда мы это выяснили ... Разработка расписания резервного копирования действительно зависит от того, сколько данных вам нужно восстановить и как быстро вам нужно восстановить их в случае аварийного восстановления. Я бы рекомендовал начинать с полной резервной копии каждый день. Вы всегда можете уменьшить частоту позже. Помните, что разностное резервное копирование является накопительным с момента последнего полного заполнения, поэтому в зависимости от изменения объема, происходящего в вашей базе данных, разность может быть больше, чем полное резервное копирование через несколько дней. Если вы делаете полное резервное копирование каждый день, то вам может не понадобиться использовать дифференциалы вообще; однако вы все равно можете делать это один раз в день и запланировать это на 12 часов дня. Резервное копирование журнала транзакций только создает резервную копию журнала. Частота резервного копирования журнала будет определять, сколько данных вы готовы потерять в случае сбоя. Если вы запускаете резервное копирование журнала каждые 15 минут, тогда вы ожидаете потерять до последних 15 минут данные, которые изменились. 15 минут - это хорошая частота, но каждые 30 минут отлично подходят для моей среды.

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

В Books Online есть полезная информация, если вы планируете использовать планы обслуживания, но если вам действительно нужна гибкость, ознакомьтесь со сценариями резервного копирования Ola Hallengren .