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

Question

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

В конечном счете, у каждого разработчика была проблема с db и вы хотите откат db. Мы не делаем что-то, чтобы защитить db, поскольку мы считаем его работой DBA, но потом у нас возникли проблемы ...

Каковы ваши лучшие рекомендации по резервному копированию?

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

И это не весь список, вы можете найти больше советов в моей статье https://sqlbak.com/blog/backup-and-recovery-best-practices/