Володіння знаннями про шляхи відновлення істотно важливо, якщо використовуються різницеві резервні копії або резервні копії журналів, а відновлення бази даних на більш ранній момент часу виконується одним з таких методів:
Відновлення на момент часу
Відновлення без попереднього відновлення з усіх резервних копій журналів та останніх різницевих резервних копій.
При відновленні бази даних до більш раннього моменту часу з подальшим використанням бази даних з цієї точки створюється новий шлях відновлення. Шлях відновлення вдає із себе послідовність резервних копій даних і журналів, за допомогою яких можливе відновлення бази даних до певного моменту часу або при звичайному використанні бази даних, або в процесі спеціальної послідовності відновлення даних і журналів. Шлях відновлення складається з унікального набору спеціальних перетворень, що відображають розвиток бази даних протягом часу й кількості прихильників узгодженість даних в ній. На наступному малюнку показано зв'язок між точкою відновлення і кінцевими шляхами відновлення.
Наступні ситуації призводять до створення нового шляху відновлення, так як база даних не відновлюється «до кінця часів». Відповідно, існують резервні копії, які реалізують один або кілька шляхів відновлення, кожен з яких використовує один і той же діапазон номерів LSN.
Відновлення повної резервної копії та відновлення бази даних по журналу без використання будь-яких інших типів резервних копій.
Відновлення бази даних з кінця разностной резервної копії, відмінною від самої останньої разностной резервної копії.
Відновлення повної резервної копії та різницевої резервної копії та відновлення бази даних без застосування існуючих резервних копій журналу транзакцій.
Відновлення бази даних з кінця резервної копії журналу транзакцій, відмінною від самої останньої резервної копії журналу транзакцій.
Відновлення бази даних з певного моменту часу або з позначкою транзакції усередині резервної копії журналу транзакцій.
У загальному випадку, точка відновлення створює новий шлях відновлення, якщо вона призводить до відкоту транзакцій. Інститути, які раніше резервні копії тепер можуть мати номера LSN великі, ніж номер LSN цієї точки відновлення. У таких резервних копіях вони існують в різних гілках відновлення, які створюються в поточній операції відновлення.
Спочатку всі резервні копії бази даних утворюють один шлях відновлення, як показано на наступному малюнку. На цьому малюнку шлях відновлення включає резервну копію бази даних, створену в момент t1, і три резервних копії журналу, створені в моменти t2, t3 і t4.
Резервна копія t5 містить метадані про вилці відновлення, які пов'язують цю резервну копію з резервною копією журналу t3 в галузі відновлення 1. Додаткові відомості про метаданих про вилці відновлення см. В розділі «Управління вилками відновлення» нижче.
У прикладі, представленому на попередній ілюстрації, створюється новий шлях відновлення, показаний на наступному малюнку. Новий шлях відновлення включає деякі резервні копії з гілки відновлення 1 (t1-t3) і всі резервні копії журналу з гілки відновлення 2 (t5-t9). Для цієї гілки відновлення резервна копія журналу t4 є застарілою.
Після відновлення на певний момент часу створення наступної резервної копії завжди призводить до виникнення вилки відновлення. На наступному малюнку відновлення на момент часу виконується наполовину за допомогою резервної копії журналу t4. Відновлення бази даних на цей момент часу призводить до створення вилки відновлення. Потім в момент t5 в відновленої базі даних створюється резервна копія журналу, яка задає гілка відновлення 2 і породжує новий шлях відновлення. Перша резервна копія журналу в новій гілці t5 містить такий же номер LSN, що і у резервної копії t3, і замінює її. Тому обидві резервні копії, t3 і t4, є застарілими для нової гілки відновлення.
Для відновлення резервних копій в цій новій галузі відновлення послідовність відновлення буде t1, t2 і t5. При створенні нових резервних копій в галузі відновлення 2 вони будуть включатися в новий шлях відновлення.
Відновлення і накат уздовж старого шляху
Як правило, при наявності декількох шляхів відновлення кращим для відновлення бази даних є найостанніший з них. Рекомендується уникати використання старих шляхів відновлення. Однак при необхідності можна виконати накат по старому шляху відновлення, використовуючи послідовність резервних копій, зроблених перед створенням поточного шляху відновлення. Наприклад, можна використовувати резервні копії, створені перед відновленням на певний момент часу, щоб досягти більш пізніх точок на старому шляху.
Наприклад, на основі резервних копій, створених в попередньому прикладі, після створення резервної копії журналу t5 залишається можливість провести відновлення повної резервної копії бази даних, створеної в момент t1, до кінця резервної копії журналу t4. Це виконується на старому шляху відновлення.
Відновлення і накат від старого шляху до нового
Компонент SQL Server Database Engine запобігає використання в одній послідовності відновлення декількох резервних копій, накат в яких відбувається за різними шляхами відновлення. Це обмеження забезпечує узгодженість бази даних після відновлення.
Для відновлення і накату по новому шляху відновлення створіть різні послідовності відновлення для резервних копій перед точкою відновлення і для резервного копіювання після точки відновлення:
Відновіть резервні копії, які були створені до відновлення, відповідного новому шляху відновлення. Виключіть резервну копію, яка містить точку відновлення.
Проведіть накат по новому шляху відновлення, відновивши резервні копії, створені з моменту створення шляху відновлення.
Гілка відновлення є діапазоном номерів LSN, для яких встановлено однаковий ідентифікатор GUID. Шлях відновлення описує діапазон номерів LSN від точки запуску (LSN, GUID) до кінцевої точки (LSN, GUID). Діапазон номерів LSN в шляху відновлення може перетинати одну або більше гілок від початку до кінця. Нова гілка відновлення виникає при створенні бази даних, а також якщо інструкція RESTORE WITH RECOVERY формує вилку відновлення.
Вилка відновлення є точкою (LSN, GUID), на якій нова гілка відновлення запускається кожного разу, коли виконується інструкція RESTORE WITH RECOVERY. Кожна вилка відновлення визначає зв'язок типу батьки-нащадки між гілками відновлення.
Відновлення бази даних призводить стан всієї бази даних, включаючи наступний номер LSN, до контрольної точки відновлення. Потім номера LSN використовуються повторно, починаючи з fork_point_lsn. Таким чином, при створенні послідовності відновлення резервні копії повинні бути пов'язані гілкою відновлення і номерами LSN, так як один і той же номер LSN може бути присутнім більш ніж на одній гілці. На наступному малюнку показано повторне використання номера LSN. На ньому видно, як номери LSN повторно використовуються в різних гілках відновлення. Зелені прямокутники на ілюстрації вказують дві резервні копії, для яких використовується один номер LSN.
Якщо в послідовності відновлення необхідно використовувати резервні копії, які перетинають вилку відновлення, то послідовність відновлення повинна бути створена так, щоб використовувані резервні копії слідували до контрольної точки відновлення по правильному шляху відновлення. Для цього резервні копії містять ідентифікатор GUID першої і останньої вилки відновлення.
Ці ідентифікатори разом з іншими метаданими, пов'язаними з відстеженням шляхів відновлення, зберігаються в таблиці журналу backupset і повертаються інструкцією RESTORE HEADERONLY. У наступній таблиці наводиться зведення значень метаданих, релевантних для створення послідовностей відновлення, які перетинають вилку відновлення. Зверніть увагу, що імена стовпців для цих значень відрізняються в таблиці журналу і результуючому наборі інструкції RESTORE HEADERONLY.