Різниця між Повною резервною копією та Повною копією лише для копіювання

Я бачив у центральній нитці SQL Server Чи повна резервна копія обрізає журнал? що повна резервна копія не скорочує журнал:

Ні. Повна або диференціальна резервна копія не скорочує журнал транзакцій. - Лін Петтіс
Ні - повна резервна копія не врізає журнал. - Чад Крофорд

Тож яка різниця між повною резервною копією та повною копією лише для копіювання?

Для резервного копіювання журналу існує резервна копія лише для копіювання, яка запобігає розриву ланцюга журналу без обрізання журналу. Отже, що таке резервна копія лише для копіювання?

Як мінімум потрібно враховувати диференційовані резервні копії. Якщо не буде використано лише копію в повному обсязі, наступне резервне копіювання буде відключено. Резервні копії лише для копіювання :

Повне резервне копіювання лише для копіювання (усі моделі відновлення) Резервне копіювання лише для копіювання не може служити диференційованою базою або диференціальним резервним копієм і не впливає на диференційовану базу.

Єдина різниця між повною та повною копією полягає в тому, що повна копія не розриває диференціальний ланцюг. Жоден з них не розриває ланцюг журналів, оскільки жоден з них не скорочує файл журналу.

Ключова відмінність резервного копіювання "Повна" та "Копія" лише в тому, чи є LSN (номер послідовності журналу), а саме DatabaseBackupLSNоновлено.

Коли ви берете повну резервну копію, DatabaseBackupLSNоновлення оновлюється. Після взяття повної резервної копії, якщо ви берете диференціальну резервну копію, у цього резервного копію є DatabaseBackupLSNвідповідність повної резервної копії, і тому SQL може з'єднати ці два разом (наприклад, з цих LSN відомо, що diff слідувало за повним).

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

Якщо резервна копія не використовується лише для копіювання, вона не торкається DatabaseBackupLSN, і як така не розриває ланцюг резервних копій.

Існує хороший опис проблеми, а також чому так багато людей неправильно його розуміють у " Розбитті ланцюга резервного копіювання" - REDUX (або їдять ворона) Майкла К. Кемпбелла, який включає в себе хороші наочні посібники, як цей:

Для кращого пояснення чотирьох різних LSN та того, як вони використовуються, ознайомтеся з Поняттям Simon Liew послідовних номерів журналу SQL Server для резервного копіювання .

Спосіб уникнути проблеми полягає в тому, щоб не мати декількох речей, роблячи стандартні резервні копії бази даних. Будь-які adhoc або вторинні резервні копії повинні бути виконані за допомогою параметра "лише копіювання", див. Резервні копії лише для копіювання (SQL Server) для отримання детальної інформації, але по суті ви використовуєте опцію "Копіювати лише резервну копію" в SSMS, через WITH COPY_ONLYкоманду T-SQL, вказану в команді або використовуйте -CopyOnlyпараметр PowerShell .

Припустимо, що у нас є база даних із запланованими резервними копіями. Повне резервне копіювання працює один раз на 24 години о 00:00, також у нас є диференційні резервні копії, які працюють кожні 6 годин, і резервні копії журналу транзакцій, які працюють щогодини. Отже, що робити, якщо нам потрібно зробити додаткову повну резервну копію в середині дня, щоб відновити інший сервер? Що робити в цьому випадку Звичайно, ми можемо зробити повне резервне копіювання.

BACKUP DATABASE Test TO DISK = 'C:/Test.bak'

Але коли ви створюєте резервну копію бази даних, є деякі зміни, які впливають на відновлення наступних резервних копій (диференційні резервні копії та резервні копії журналу транзакцій впливають на те, як буде виконуватися операція відновлення). У цьому випадку всі наступні диференціальні резервні копії залежатимуть від останньої повної резервної копії. Якщо остання повна резервна копія втрачена, відновлення бази даних неможливо.

Але як ми можемо зробити резервну копію, яка не вплине на наступні процеси резервного копіювання чи відновлення для цієї бази даних. Це місце, де створюються резервні копії лише для копіювання.

BACKUP DATABASE Test TO DISK = 'C:\Test.bak' WITH COPY_ONLY

Коли у вас є повна резервна копія та набір резервних копій файлів журналу, ланцюжок журналів підтримується за допомогою LSN (Номер послідовності журналу). Якщо ви хочете зробити резервну копію, не порушуючи ланцюг журналів, тоді робіть резервну копію лише для копіювання.

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

Наприклад: скажіть, що у вас є сценарій створення резервних копій, який займає повні резервні копії кожні 6 годин (опівночі, 6 ранку, полудень, 18 вечора) та створюйте резервні копії кожні 15 хвилин. О 9 годині ранку надходить запит, щоб його копія була розміщена на тестовому сервері. Ви хочете взяти резервну копію, не порушуючи ланцюжок журналів або порушуючи завдання резервного копіювання. Це коли робиться резервна копія лише для копіювання. Резервне копіювання лише для копіювання не порушить ваші звичайні набори резервних копій.

Повне резервне копіювання та копіювання лише резервного копіювання не розривають ланцюг журналів. тільки якщо ви робите резервну копію tlog, буде невідповідність LSN.