Модели восстановления SQL баз
Существуют 3 модели восстановления SQL баз:
- Простая (Simple)
- Полная (Full)
- С неполным протоколированием (Bulk logged)
Модель восстановления определяет поведение журнала транзакций, а именно — за какой период будут храниться данные в журнале и какие события в нем будут фиксироваться. От выбранной модели восстановления зависит какие типы операций восстановления доступны.
Обычно в базе данных 1С используется модель полного восстановления или простая модель восстановления.
Модель с неполным протоколированием для баз 1С используется крайне редко.
Базу данных можно в любой момент переключить на использование другой модели восстановления.
Модель восстановления с неполным протоколированием похожа на модель полного восстановления, за исключением того, что протоколирование большинства массовых операций в ней производится в минимальной степени. В случае с базами 1С это не дает каких-либо значимых преимуществ ни перед одной из двух оставшихся моделями.
Рассмотрим две самые используемые для 1С модели восстановления SQL баз.
Простая (Simple)
При выборе простой модели восстановить базу данных можно с момента создания последней разностной или полной резервной копии.
В данном случае в журнале транзакций будет храниться минимальный набор данных. Когда файл журнала транзакций будет заполнен на 70%, система начнет писать данные в начало файла, затирая самые ранние данные. При такой модели восстановления файл журнала транзакций будет занимать минимальный объем на диске, но не будет хранить никакой истории транзакций. Так как история транзакций не хранится, то нет смысла делать бэкапы логов.
Полная (Full)
При полной модели восстановления журнал транзакций хранит максимальную информацию обо всех транзакциях. При этом хранятся не только текущие активные транзакции, но и все изменения всех предыдущих транзакций.
При выборе полной модели восстановления мы можем восстанавливать базу до минуты, создав полную резервную копию, и в течение какого-то времени, создавать только копии журнала транзакции.
Если, например, бэкап журнала не выполнялся в течение месяца, тогда файл журнала транзакций содержит информацию обо всех изменениях в базе, которые произошли за этот месяц. Поэтому, при полной модели восстановления файл журнала постоянно увеличивается до тех пор, пока не будет сделан бэкап лога.
Если не делать бэкап лога длительное время, файл журнала может расти неограниченно и со временем занять все свободное место на диске (если не установлено ограничение на размер журнала).
В момент создания копии журнала он усекается и в нем остаются только данные об активных на текущий момент транзакциях. Усечение журнала не означает уменьшение размера файла журнала на диске, просто место внутри этого файла будет освобождено.
При выполнении полного или разностного бэкапа усечение журнала не происходит.
Чтобы сократить объем, занимаемый файлом журнала на диске, необходимо выполнить сжатие журнала командой DBCC SHRINKFILE.
Усечение журнала – это освобождение места внутри физического файла (размер файла не уменьшается).
Сжатие файла журнала – это уменьшение размера файла журнала на диске
Краткий итог
Если для вас некритична потеря изменений в базе данных, которые произошли между полной или разностной копией, то вам следует выбрать вариант простой модели восстановления. Частоту полных и разностных копий нужно определить из стоящих перед вами задач по резервному копированию и восстановлению.
Если вам нужно иметь копию базы данных на любое затребованное время, вплоть до минут, то вам следует выбрать полную модель восстановления.