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

Я успадкував базу даних, що має найважливіший для бізнесу розмір SQL Server 2008, і намагаюся обернути голову навколо планування резервного копіювання. (Я розробник, а не DBA.)

У налаштуваннях нашої системи зараз є дві резервні системи:

1. Щотижневі повні резервні копії ( .bak) та погодинні .trnрезервні копії журналу транзакцій . Ми зберігаємо кілька наборів цих резервних копій, і вони регулярно відправляються за межами місця.
2. Журнали SQL Server ( .ldf) із встановленою моделлю відновлення Full. Цей файл знаходиться на окремому диску від основного .mdfфайлу, але в іншому випадку не створюється резервна копія.

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

Мої запитання:

1. Чи можливо відновити базу даних з .ldfфайлу? Для чого це навіть?
2. Чи зайве мати обидва ці журнали транзакцій?
3. Чи важливо створити резервну копію .ldfфайлу?

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

Ні, це не зайве, оскільки вони мають дві різні цілі.

Важливо здійснити повні резервні копії та резервні копії журналу транзакцій. Тільки наявність копії файлу ldf не допомагає відновити базу даних.

Що стосується файлу ldf, то ldf - це журнал транзакцій. Подумайте про це як круговий буфер, який записує зміни до вашої бази даних. Коли ви оновлюєте рядок, зміна негайно записується до ldf. У якийсь момент у майбутньому (як правило, менше п’яти хвилин) змінені дані записуються у файл mdf.

Якщо сервер вийшов з ладу або стався збій живлення, при запуску SQL він зчитує ldf і повторно застосовує (REDO) ці зміни.

Крім того, якщо у вас є транзакція, яку не було здійснено, і серйозні збої, всі зміни, внесені цією транзакцією, повинні бути скасовані, щоб зробити базу даних послідовною. Файл ldf також має це завдання. (UNDO)

Я вже згадував, що файл ldf - круговий. Беручи резервну копію журналу транзакцій (.trn), копіюється частина файлу ldf. Після безпечного створення trn-файлу sql може повторно використовувати цю частину файлу ldf. Серія резервних копій trn створює ланцюг, який разом записує всі зміни, внесені до бази даних. Звичайно, якщо ви ніколи не брали резервну копію журналу tranaction, файл ldf буде рости та рости та рости.

У випадку катастрофи відновлення повної резервної копії отримує копію бази даних на момент завершення повної резервної копії. Потім ви можете відновити файли trn в порядку та привести базу даних поточною до будь-якого моменту часу, включаючи до останнього резервного копіювання trn.

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