Полный – это фундамент, на котором будет держаться вся ваша система резервирования. По большому счету, это копия базы данных, которая включает в себя вообще все — таблицы, данные, индексы, триггеры, статистику, хранимые процедуры и еще много разного добра. Более того — если вы выбираете вариант динамического резервного копирования (то есть во время резервирования данных пользователи могут полноценно работать с сохраняемой БД), то все изменения, которые пользователи сделают за то время, пока создается бэкап, тоже будут сохранены. Вы можете легко вернуть базу данных к тому состоянию, в котором она была в какой-то определенный момент, если у вас есть полный бэкап, сделанный в это время.
Главный вопрос, связанный с полными бэкапами — как часто их стоит делать? Универсального ответа нет. Понятно, что полное резервирование должно выполняться по меньшей мере раз в неделю. Если у вас не слишком большие базы данных и нет особых проблем с местом под бэкапы, возможно, резервирование раз в день будет более подходящим вариантом. С другой стороны, слишком частое полное резервирование будет нагружать ваш сервер и потребует неоправданно много дискового пространства для хранения бэкапов. Точная цифра зависит от размера ваших баз данных, производительности и загруженности сервера.
Лог журнала транзакций - Бэкап лога отличается от полного бэкапа тем, что в него входят исключительно изменения базы данных (то есть операции INSERT, UPDATE и DELETE) с момента последнего бэкапа, будь то полный бэкап, дифференцированный или предыдущий бэкап лога. Поскольку объем сохраняемых данных крайне мал, такой тип резервирования намного быстрее, требует меньше ресурсов и занимает меньше места на диске. Недостатков, увы, тоже хватает. В первую очередь, бэкап лога бесполезен, если у вас нет хотя бы одного полного бэкапа. Объясняется это тем, что в таком логе не сохраняется никакая информация о таблицах, индексах, хранимых процедурах и так далее. Вторым существенным недостатком является то, что если с момента последнего полного бэкапа вы успели сделать сотню бэкапов лога, а потом случилась беда, то прежде, чем вы восстановите заветный сотый, вам потребуется восстановить не только полный бэкап, но и предыдущие девяносто девять бэкапов лога, да к тому же в правильном порядке. Согласитесь, приятного в такой перспективе не очень много. Еще одна немаловажная особенность заключается в том, что бэкап лога доступен только для тех баз данных, у которых указан FULL или BULK LOGGED режим восстановления.
Дифференциальный — это что-то среднее между полным бэкапом и бэкапом лога. В нем сохраняются изменения, сделанные с момента последнего полного бэкапа по настоящее время. Главным его преимуществом по сравнению с бэкапом лога является то, что для полного восстановления базы данных вам достаточно восстановить только лишь полный и последний дифференцированный бэкапы. Недостатком же является то, что вы не можете восстановить промежуточное состояние базы данных на какой-то момент времени — история изменения БД в дифференцированном бэкапе не сохраняется. Как и бэкап лога, такой бэкап бесполезен, если у вас нет полной копии базы данных.
Модели восстановления баз данных ИБ 1С:
Полная – Все изменения в базе полностью журналируются. Это не означает, что каждое изменение имеет отдельную запись в журнале, поскольку некоторые операции пишутся с меньшим количеством записей в журнале, но тем не менее журналируется полный эффект от операции. Журнал транзакций не будет очищаться (т.е. его части не станут доступными для переиспользования) до тех пор, как не будет сделана резервная копия журнала транзакций.
Простая – Некоторые изменения могут минимально журналироваться. Журнал транзакций не будет очищаться до выполнения операции создания контрольной точки (CHECKPOINT) — обычно она выполняется автоматически. Создание резервных копий журнала транзакций невозможно, поэтому у вас остается самое ограниченное число опций по восстановлению. Данные в логе транзакций (файл с расширением ldf) хранятся до тех пор, пока данные не будут записаны в основной файл баз данных (файл с расширением mdf).
Большинство людей использует полную модель восстановления, чтобы иметь возможность создавать резервные копии журнала транзакций и позволить себе все возможные опции восстановления. Главная вещь, которую вы должны помнить, когда ваша база использует полную модель восстановления или модель с неполным протоколированием — вы должны периодически создавать резервные копии журнала транзакций или журнал транзакций будет расти бесконечно.
В некоторых условиях предпочтительнее простая модель восстановления: если вам не нужна возможность восстановления на момент времени и минимальные потери при восстановлении с использованием резервных копий журнала транзакций. Примером может служить используемая для тестов база данных, которая перезаполняется раз в день и любые изменения могут быть потеряны или быстро повторены.
Создание резервной копии ИБ 1С
Нажимаем правой кнопкой мыши на необходимую базу данных и из выпадающего меню выбираем создание резервной копии:
Выбираем необходимый вариант копии (полная, дифференциальная, лог журнала транзакций)
На вкладке “Параметры носителя”, можем поставить галочку проверки копии после создания:
После этого нажимаем “ОК” и дожидаемся завершения резервной копии.
Восстановление базы данных ИБ 1С
Нажимаем правой кнопкой мыши на необходимую базу данных и из выпадающего меню выбираем восстановление:
В открывшемся окне выбираем, откуда будем восстанавливать базу (из списка баз данных и их резервных копий, либо с устройства выберем необходимые копии):
Если у нас есть несколько копий (копии журнала транзакций, дифференциальные или полные копии), по кнопке – временная, мы можем выбрать определенное время, на которое необходимо восстановиться. Так как у нас выбрана всего одна полная копия, мы сможем восстановить базу только лишь на 3 мая 2018 года на 21.50:
На вкладке “Файлы” убедимся, что у нас выбраны верные конечные файлы лога журнала транзакций и файла базы данных:
На вкладке “Параметры” поставим галочку “Перезаписать существующую базу данных”:
После этого нажмем кнопку “ОК” и дождемся завершения процедуры восстановления.
Сжатие файлов лога журнала транзакций
Есть такая особенность, что лог журнала транзакций растет (обычно это происходит при полной модели восстановления базы данных). Если полная модель восстановления, то уменьшение лога практически не произойдет. Связано это из-за того, что подтвержденные транзакции не удаляются из файла лога. Необходимо сделать бэкап лога транзакций. Чтобы уменьшить размер файла лога журнала транзакций, необходимо проделать следующие действия:
Перевести базу данных в режим восстановления – простая (simple).
Правой кнопкой мыши нажать на необходимую базу данных и выбрать сжатие базы данных:
Выбрать файл логов журнала транзакций в списке, посмотреть, насколько уменьшится файл и нажать кнопку “ОК”.
Так же есть возможность скриптом проделать данную операцию:
“TEST” – имя базы данных
“TEST.LDF” – имя файла лога журнала транзакций
100 – уменьшить до 100 мб. файл лога
