Рекомендации по резервному копированию SQL Server 2008

Question

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

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

Каковы ваши лучшие практики резервного копирования?

Answer 1

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

ОЧЕНЬ первое, что я делаю (еще до того, как я настрою какие-либо базы данных), - это создание планов ночного обслуживания, которые включают полное резервное копирование, и направляют эти резервные копии в общую сетевую папку на другом компьютере (нашем NAS). По крайней мере, ради вашей работы, не размещайте резервные копии в том же физическом хранилище, где находятся файлы вашей базы данных. Что хорошего в резервных копиях, если вы теряете их одновременно с потерей диска?

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

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

Answer 2

Вот некоторые моменты из моего собственного опыта:

• Храните ваши резервные копии и файлы базы данных SQL Server в разных физических хранилищах. В противном случае при сбое физического хранилища вы потеряете как резервные копии, так и файлы базы данных.
• Создайте собственное расписание резервного копирования базы данных SQL Server.
• Проверьте вашу резервную копию SQL Server. Если вы никогда не проверяли свои резервные копии, я сомневаюсь, что вы сможете восстановить свою базу данных в случае сбоя. Время от времени вам нужно практиковаться в восстановлении резервной копии на тестовом сервере.
• Проверьте свою стратегию восстановления - вот еще один совет. Если происходит сбой, сколько времени вам нужно, чтобы восстановить базу данных в рабочее состояние?
• Резервное копирование системных баз данных SQL Server.

И это еще не весь список, другие советы вы можете найти в моей статье https://sqlbak.com/blog/backup-and-recovery-best-practices/

Answer 3

Выбор правильной стратегии резервного копирования является одним из наиболее важных факторов, которые администратор БД должен учитывать при разработке БД.

Однако выбранная вами стратегия резервного копирования зависит от ряда факторов:

1. Как часто транзакции выполняются в БД: выполняются ли тысячи транзакций каждую минуту или, может быть, несколько транзакций в день? Для очень загруженной базы данных, я бы сказал, делайте полное ночное резервное копирование и резервное копирование журнала транзакций каждые 10 минут или даже меньше.
2. Насколько важен контент данных: это могут быть данные о заработной плате сотрудников? Тогда у вас не будет подходящего оправдания, или у вас может быть несколько сердитых лиц вокруг вашей машины, когда вы хотите ехать домой! Для очень важной базы данных делайте ночные резервные копии, возможно, в двух местах, а резервные копии журнала транзакций каждые 5 минут. (Также подумайте о реализации зеркалирования).
3. Местоположение вашего хранилища резервных копий: если ваше хранилище резервных копий близко к расположению БД, то вы можете позволить себе делать более частое резервное копирование, чем когда оно находится в нескольких прыжках, с не очень хорошей пропускной способностью между ними.

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