Я в первую очередь разработчик, но для одной небольшой внутренней системы я также отвечаю за некоторую конфигурацию сервера, на котором работает SQL Server Enterprise Edition.
Сама база данных видит активность из двух источников:
Я достаточно доволен использованием встроенных утилит резервного копирования SQL-сервера, я установил план обслуживания, который создает резервную копию всей базы данных каждые 6 часов, а журналы транзакций - каждые 6 часов между резервными копиями базы данных (например, 6 утра, база данных резервное копирование, резервное копирование журнала транзакций в 9 утра, резервное копирование базы данных в 12 часов, резервное копирование журнала транзакций в 3 часа дня). Каждую неделю мы делаем снимок всего сервера на магнитной ленте (данные не являются критически важными, это скорее проект НИОКР).
До того, как это было установлено, база данных начала резко расти, теперь все полные резервные копии базы данных занимают очень удобные 15 МБ (и медленно растут), а журналы транзакций - от 9 до 12 МБ.
Правильно ли я делаю? Есть ли у вас какие-либо другие сведения о частоте резервного копирования журнала транзакций?
Если в другом вопросе, который я пропустил, есть что-то полезное, пожалуйста, укажите мне на это.
Честно говоря, нет причин НЕ запускать резервные копии журнала транзакций с гораздо большей частотой. Резервное копирование журнала транзакций ничего не ВРЕДА. (В БОЛЬШИНСТВЕ сценариев это просто потребует немного активности процессора и диска, но обычно это почти незначительно.)
Более того, вы можете как увеличить охват, так и повысить производительность, переместив резервные копии файлов журнала на менее производительный диск: SQL Server Magazing: максимальная производительность хранилища
Увеличивая частоту резервного копирования, вы уменьшаете окно потенциально потерянных данных. (Технически, если SQL Server выходит из строя, вы иногда можете восстановить потерянные транзакции с момента последнего ПОЛНОГО / ДИФФЕРНЦИАЛЬНОГО резервного копирования, ЕСЛИ ваш файл журнала все еще не поврежден. Но обычно, если что-то пошло не так, чтобы вы могли выполнить резервное копирование, ДОСТОЙНЫЙ шанс, что ваш файл журнала исчез / тост.)
Не стесняйтесь смотреть следующие видео, чтобы получить немного больше информации и информации о том, что происходит с точки зрения резервного копирования, журналов и передовых методов:
Раскрытие тайны резервных копий SQL Server
Основы ведения журнала SQL Server
Пока звучит хорошо. Не забудьте также проверить свои резервные копии!
Если ваша система становится критической, вы также можете рассмотреть возможность доставки журналов транзакций или более частые интервалы, чем 3 часа.
Оптимальная стратегия резервного копирования SQL Server зависит только от доступности вашей базы данных и требований согласованности данных ...
Если вы готовы потерять данные на 6 часов (период между последовательными копиями журнала транзакций / базы данных) - ничего страшного. Если нет - подумайте больше об оптимизации стратегии резервного копирования (например, с более частым резервным копированием журнала транзакций / инкрементным резервным копированием, даже зеркальным отображением базы данных).
Энди,
вы также можете настроить обслуживание индексов в базе данных. Вы можете настроить отдельный план обслуживания для этих действий, возможно, запускать их ночью или еженедельно, когда пользователи не подключены.
Как у вас есть стратегия резервного копирования, если все в порядке, ваше окно восстановления - каждые три часа. Пока вы можете жить с потерей трех часов данных в самое худшее время, все в порядке.