Чому диференціальне резервне копіювання не може вказати його базу?

Це мій перший пост DBA.SE, тому, будь ласка, повідомте мене про будь-які помилки, дякую!

Я новий DBA (не ІТ-професіонал, просто ніхто інший в компанії цього не робить), тому чим основніше пояснення, тим краще. Я читав про стратегії резервного копіювання бази даних (або, як я навчився їх називати, "стратегії відновлення"). Я розумію, що роблять резервні копії повного, диференціального та транзакційного журналу, але я хочу знати, чому диференціальне резервне копіювання може базуватися лише на останніх повних резервних копіях.

Якщо диференціальне резервне копіювання - це все, що змінилося з моменту останнього повного резервного копіювання, то чому я не можу базуватись на диференціальній резервній копії мого вибору? Для того, щоб бути більш зрозумілим, я прошу вказати базу під час прийняття резервної копії , а не під час відновлення. Я припускаю, що під час відновлення ви б обрали правильну базу та відповідний диференціал, щоб виконати відновлення (не використовуючи диференціала, виготовленого з бази Б для відновлення з бази А).

Яка причина, яка заважає цій функціональності бути можливою? Я вважаю, що повинна бути причина, я просто не знаю, що це.

Примітка. Я розумію, що основу не можна вказати, але моє питання: чому ні ? (Мені також не цікаво обговорювати питання "нащо б ти?")

Аналогія

Ось аналогія того, як я розумію диференціальне резервне копіювання:

У мене є файл Excel з деякими даними в клітинках.

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

2-го дня я переглядаю файл і порівнюю його з резервною копією, яку я зробив в 1-й день, і відзначаю всі комірки, які змінилися, і які їх нові значення ("диференційна резервна копія"). Я не відзначаю кожну зміну, внесену до комірки, лише те, яке її кінцеве значення. Якщо клітинка А1 починалася як "Альфред", змінюється на "Бетті", "Чарлі", то "Дейв", я зазначу лише, що "А1 зараз Дейв".

На 3 день я знову порівнюю поточний файл із файлом резервної копії та відмічаю зміни (інша "диференціальна резервна копія" з тією ж базою, що й день 2). Знову ж таки, відзначаючи лише кінцеві значення на осередок у спостережуваний час, а не всі значення, які осередок був протягом дня.

4-го дня я знову порівнюю і знову зазначу зміни. Продовжуючи клітинку А1, тепер вона говорить "Сара", навіть якщо це було 10 інших імен протягом дня, і все, що я зазначаю, - "Зараз А1 - Сара".

5-го дня мій файл зіпсується; Отже, я дивлюся на резервну копію, яку я зробив 1-го дня, потім остаточні стани відзначали 4-го дня, і я застосовую зміни, відмічені до резервної копії, і тепер у мене файл "відновлений", як це було в 4-й день Отже, я дивлюсь на резервну копію, зроблену в 1-й день, бачу, що 4-го дня клітинка А1 закінчилася як "Сара", і я змінюю комірку резервної копії А1 на "Сару".

Чому це було б важливо, якщо я зробив ще одну резервну копію ("повну") файлу на 2 день? Чому б все-таки не вдалося порівняти (прочитати, "взяти диференціальне резервне копіювання") файлу на 3 або 4 день з копією, зробленою в перший день? Як я це розумію, SQL Server вимагає від мене порівняння (коли знімається інша диференціальна резервна копія) з повною резервною копією, зробленою на 2 день (якщо така була зроблена) - іншого варіанту немає.

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

Виконання повної резервної копії скидає карту змін диференціальних. З цього моменту будь-яка змінена сторінка записується на карту. Якщо потім взяти диференціальну, ця резервна копія містить лише сторінки, які були змінені з моменту останньої повної резервної копії та записані на карті.

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

Коли ви просите SQL Server взяти диференціальну резервну копію, єдиною «базою» для диференціала є єдина карта диференціальних змін, присутня в базі даних під час початку диференціальної резервної копії. Ось чому ви не можете вказати основу для диференціального резервного копіювання.

У відповідь на коментар від @MartinSmith - можливо, ви зможете використовувати COPY_ONLYрезервні копії для відновлення диференціальної резервної копії для кількох повних резервних копій. Розглянемо наступний сценарій:

1. BACKUP DATABASE xyz TO DISK = 'path_to_backup.bak';
2. BACKUP DATABASE xyz TO DISK = 'path_to_backup_2.bak' WITH COPY_ONLY;
3. BACKUP DATABASE xyz TO DISK = 'path_to_backup_3.bak' WITH COPY_ONLY;
4. BACKUP DATABASE xyz TO DISK = 'path_to_backup_4.bak' WITH COPY_ONLY;
5. BACKUP DATABASE xyz TO DISK = 'path_to_backup_diff.bak' WITH DIFFERENTIAL;

Диференціальне резервне копіювання на етапі 5 повинно бути здатне відновити будь-яку з резервних копій, зроблених на кроках 1 - 4, оскільки карта зміни диференціала очищається лише тоді, коли відбувається повне резервне копіювання на етапі 1. Ці COPY_ONLYрезервні копії з кроком 2, 3, і 4, нічого НЕ скинути карту змін. Оскільки карта диференціальних змін накопичує зміни, внесені після повної резервної копії, кожна з послідовних COPY_ONLYрезервних копій містить достатньо інформації для диференціальної резервної копії для роботи з будь-яким з попередніх 4 резервних копій.

Хоча здається, що це має спрацювати, на практиці відновлення диференціалу поверх резервної копії copy_only призводить до наступної помилки:

Msg 3136, рівень 16, стан 1, рядок 1
Цю диференціальну резервну копію неможливо відновити, оскільки база даних не була відновлена ​​до правильного попереднього стану.
Повідомлення 3013, рівень 16, стан 1, рядок 1
ПОНЯТТЯ ДАТАБАЗА закінчується аномально.

Я створив репро-платформу платформи SQL Server 2012 для тестування диференціалу та відновлення copy_only та зберег файл на gist.github.com - ПОПЕРЕДЖЕННЯ сценарій видалить будь-яку базу даних, названу RestoreTestяк її перший крок.

Функція, яку ви хочете, може існувати в принципі. Це не було б ефективно з поточними структурами баз даних (див. Відповідь Макса Вернона). SQL Server повинен був або підтримувати набір різних карт, або порівнювати поточний вміст БД з повною резервною копією, яку ви вказали як базу.

Є програми, які дедублюють великі файли. Можна зробити дві повні резервні копії, і фактично зберігатимуться лише змінені дані. Це як розбіжність зі спеціальною базою. exdupeнаприклад, це можна зробити.

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

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

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

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

Мета резервного копіювання журналу транзакцій - дозволити вам відтворювати транзакції до довільного моменту часу - часто, але точно не обов'язково, щоб "найсвіжіше щось сталося".

Те, про що ви говорите, насправді можливо - але вам потрібно відновити повну резервну копію, а потім відновити журнали транзакцій.

Якщо у вас є повне резервне копіювання за перший день, і всі резервні копії журналу транзакцій між 1-м і 5-м днем, це ніщо не перешкоджає відновленню резервного копіювання першого дня та відновленню журналу транзакцій, поки ви не отримаєте дані, як це було на 4 день. також можна почати з 2-го дня резервного копіювання, яке відновити було б трохи швидше, оскільки ви б відтворювали менше транзакцій. Ви також можете відновити повну резервну копію першого дня, 3-го дня диференціального резервного копіювання, а потім відновити журнали транзакцій до 4-го дня.

Редагувати: Добре, ваша редагована аналогія має трохи більше сенсу. Відповідь тоді "тому що ви вже можете досягти того, що хочете за допомогою резервного копіювання журналу транзакцій". Диференціальне резервне копіювання - це лише дешевий і зручний спосіб запису всієї маси журналів транзакцій. Він не пропонує деталізації відновлення даних, яку не пропонує резервна копія журналу транзакцій. Є лише стільки функцій, які пропонують "просту зручність", що перетворюють її на продукт.

Аналогія з Excel - це порівняння яблук і апельсинів. Чому? Excel - це не база даних, оскільки їй не вистачає цілісності даних. Excel - це приємна програма для роботи з електронними таблицями і може бути доповненням до бази даних.

SQL Server - це система реляційних баз даних, яка дозволяє зберігати всі ваші дані та забезпечує механізм запиту до них. Важлива частина - "Реляційна", оскільки відносини даних важливі разом із цілісністю даних (властивості ACID).

Основи:

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

• База даних містить сторінку, яка є основною одиницею зберігання даних, яка використовується для зберігання записів .
• Сторінка бази даних - це 8192-байтний (8 КБ) фрагмент файлу даних БД.
• 8 фізично суміжних сторінок (8 * 8 КБ = 64 КБ) у файлі бази даних утворюють обсяг .
• Сторінка IAM (Map Allocation Map) відстежує приблизно 4 Гб місця в одному файлі, вирівняному на межі 4 Гб. Ці фрагменти об'ємом 4 Гб називаються інтервалами GAM .

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

Виходячи з вашої аналогії щодо excel, те, що ви робите, застосовує те, що змінилося на попереднє. Це застосовується до всіх здійснених транзакцій з журналу транзакцій with STOP AT(зверніть увагу: 5-го дня файл заплутається, і ви зупиняєтесь на 4-й день)

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

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

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

Інформація про диференційовану основу зберігається в masterбазі даних - sys.database_fileабо ( sys.master_files- корисно, коли база даних читається лише або в режимі офлайн).

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

• differential_base_lsnЄ основою для диференціальних резервних копій. Розширення даних, які будуть змінені після, differential_base_lsnбудуть включені в диференціальне резервне копіювання.
• differential_base_guidЦе унікальний ідентифікатор базової резервної копії на якому засновано диференціальне резервне копіювання.
• differential_base_timeЦе час, відповіднеdifferential_base_lsn

Диференціальне резервне копіювання корисно для прискорення RTO (мета відновлення часу = час, необхідний для відновлення вашої бази даних), на відміну від частіших повних резервних копій, що буде проблемою для великих баз даних або відновлення обсягу резервних копій журналу транзакцій, оскільки вони можуть зростати великими з часом.

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

Список літератури:

• Анатомія сторінки
• Анатомія запису
• Розуміння резервних копій SQL Server