Ноу Інти, лекція, відновлення бази даних exchange server 2018 після збоїв

Стратегії резервного копіювання

У разі аварії на сервері Exchange інформація, створена в організації Exchange з моменту останнього резервного копіювання, може бути відновлена ​​з журналів транзакцій.

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

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

Процедура резервного копіювання

Процедура резервного копіювання починається з запуску програми резервного копіювання. Ця програма викликає службу Web Storage System із зазначенням необхідного типу резервного копіювання, після чого починається процес резервування. WSS інформує ESE про те, що вона переходить в режим резервного копіювання, після чого генерується файл коригування (. PAT) для кожної резервованій бази даних (мається на увазі процес повного резервного копіювання). В процесі онлайнового повного резервного копіювання база даних відкрита для роботи, і транзакції як і раніше можуть заноситися в бази даних. Якщо транзакція викликає операцію для вже скопійованого. edb-файлу через кордон резервного копіювання (місце в файлі. edb. яке позначає, що скопійовано, а що - ні), то дана сторінка перед кордоном записується в файл. PAT. Для кожної резервованій бази даних використовується окремий файл PAT. наприклад Privl. pat. Publ. pat або Srs. pat. Ці файли відображаються тільки під час процедур резервування та відновлення. Під час процедури разностного або додаткового резервного копіювання файл коригування не створюється.

Коли ESE переходить в режим резервування, відкривається новий файл журналу. Наприклад, якщо Edb .log відкритий в даний момент, то він закривається і перейменовується для відповідності останнього покоління, після чого відкривається новий файл Edb .log. У цей момент ESE може усікати журнали після завершення резервного копіювання.

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

Ще раз представимо процес резервного копіювання у вигляді послідовності кроків.

Огляд процесу відновлення

Перед тим як почати процес відновлення, необхідно демонтувати базу даних або групу зберігання і зробити їх недоступними для користувачів. Це можна здійснити за допомогою Exchange System Manager (ESM).

Коли починається операція відновлення централізованому сховищі вільно інформує ESE про те, що починає роботу процес відновлення і ESE переходить в режим відновлення. Агент резервного копіювання копіює базу даних з резервного носія безпосередньо в кінцевий шлях для бази даних. Пам'ятайте, що база даних являє собою пару файлів -.EDN і. STM. Відповідні файли журналу і коригувань копіюються на сервер у тимчасове, вказане вами розташування, щоб вони не зберігалися там, де знаходяться файли в функціонуючої середовищі. Якщо вийшло так, що зазначений один і той же робочий і тимчасовий шлях, може статися запис поверх файлів журналів і статися логічне пошкодження поточної робочої бази даних. Тому тимчасовий шлях повинен обов'язково відрізнятися від робочого шляху.

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

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

переходить до наступної транзакції для відтворення її в базу даних.

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

Відновлення двійкових файлів

Різні сценарії відновлення

Іноді не потрібно відновлювати весь сервер або всю базу даних цілком. У цьому розділі ми будемо обговорювати різні варіанти відновлення:

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

Схожі статті