Резервные копии транзакций SQL Server и журналы

Я унаследовал среднюю по размеру критическую для бизнеса базу данных SQL Server 2008 и пытаюсь обдумать планирование резервного копирования. (Я разработчик, а не администратор баз данных.)

То, как наша система настроена сейчас, есть две системы резервного копирования:

1. Еженедельные полные резервные копии ( .bak) и ежечасные .trnрезервные копии журнала транзакций ( ). Мы храним несколько комплектов этих резервных копий, и они регулярно отправляются за границу.
2. Журналы SQL Server ( .ldf) с моделью восстановления, установленной на Full. Этот файл находится на отдельном диске от основного .mdfфайла, но в противном случае резервное копирование не производится.

В случае аварийного восстановления (или при восстановлении резервных копий на компьютере разработчика) моя процедура состоит в том, чтобы использовать .bakфайлы и затем применять файлы .trn. У нас есть скрипт, который делает эту процедуру относительно простой.

Мои вопросы:

1. Возможно ли восстановить базу данных из .ldfфайла? Для чего это вообще?
2. Не нужно ли излишне иметь оба этих журнала транзакций?
3. Это важно сделать резервную копию .ldfфайла?

Нет, восстановить базу данных из файла ldf невозможно. Файл ldf будет восстановлен вместе с файлами mdf.

Нет, это не избыточно, поскольку у них две разные цели.

Важно создавать полные резервные копии и резервные копии журнала транзакций. Только наличие копии файла PDF не поможет вам восстановить базу данных.

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

Если сервер вышел из строя или произошел сбой питания, при запуске SQL он считывает файл ldf и повторно применяет (REDO) эти изменения.

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

Я упоминал выше, что файл ldf является круглым. При резервном копировании журнала транзакций (.trn) копируется часть файла ldf. После безопасного создания trn-файла sql может повторно использовать эту часть ldf-файла. Серия резервных копий trn создает цепочку, в которой записываются все изменения, внесенные в базу данных. Конечно, если вы никогда не делали резервную копию журнала транзакций, файл ldf будет расти, расти и расти.

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

Я закрываю некоторые важные детали, но суть в том, что ldf - это рабочий файл, в котором записываются последние изменения в базе данных. Файлы trn являются копиями частей ldf, созданными в предположении, что вы сохраните их в безопасности, чтобы sql мог повторно использовать пространство в ldf, и в случае бедствия они будут храниться в другом месте.