Назад | Перейти на главную страницу

Почему важно делать резервную копию журналов SQL?

Я новичок в SQL. Что такого важного в резервном копировании файлов журнала SQL?

Абсолютно Нет для ответа AEP. Это может очень плохо сказаться на его бизнесе.

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

Во-вторых, дифференциальные резервные копии, также известные как инкрементные, содержат все изменения, сделанные на страницах данных с момента последнего полного резервного копирования. Чтобы понять политику резервного копирования, вам нужно сначала прочитать о трех моделях восстановления (простая, полная, с массовым протоколированием) и посмотреть, в чем ваш случай и какой вариант восстановления подходит вам лучше всего. Вы можете прочитать msdn и здесь больше об этом.

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

SQL Server использует журналы транзакций для записи всех изменений, примененных к основному файлу (файлам) базы данных, чтобы: A) обеспечить возможность фиксации / отката tansaction и B) обеспечить возможность воспроизведения этих изменений, если / когда предыдущая резервная копия была восстановлена ​​и базу данных необходимо обновить до того, что произошло с момента создания этой резервной копии.

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

Еще одна очень важная причина для их резервного копирования заключается в том, что это способ «инкрементного» резервного копирования в SQL Server; т.е. после полной резервной копии базы данных вы можете сделать резервную копию журнала транзакций (или более одной резервной копии последовательно), которая не только усекает старые файлы журналов и освобождает дисковое пространство, но и действует как «что изменилось с момента последнего резервного копирования» резервное копирование, позволяющее выполнять инкрементное восстановление, если они вам понадобятся.

Журналы транзакций играют очень важную роль в SQL Server и очень важны при резервном копировании / восстановлении.

(*) Все вышеперечисленное относится к базам данных, которые используют модель восстановления с полным или неполным протоколированием; если база данных настроена на простую модель восстановления, журналы транзакций не используются таким образом: некоторые из них используются для обработки транзакций, но они сведены к минимуму и автоматически перерабатываются, не увеличиваясь до бесконечности; инкрементные резервные копии / восстановления, конечно, теряются в этом сценарии.

Помните, что резервное копирование журналов стоит выполнять только в том случае, если в базе данных используется модель ПОЛНОГО или МАССОВОГО восстановления. Если ваша база данных находится в режиме ПРОСТОЙ, то резервное копирование файлов журнала не принесет никакой пользы.

Модель восстановления можно найти в свойствах базы данных и на странице параметров.

Предполагая, что вы используете ПОЛНУЮ модель восстановления. Затем вам также нужно будет подумать, как часто вы хотите выполнять резервное копирование файлов журнала транзакций. Это будет бизнес-решение, основанное на том, сколько транзакционных данных вы готовы использовать и, следовательно, повторить в случае аварии.

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