Сервер відновлення для Exchange 2000, Windows IT Pro

Використання сервера відновлення

Також можна використовувати сервер відновлення для запуску утиліт обслуговування баз даних на резервних копіях для перевірки цілісності даних та тестування резервних копій. Наприклад, у системному журналі подій додатків фіксується помилка 1018 (JET_errReadVerifyFailure). Зазвичай, така помилка вказує на наявність апаратних проблем з диском, на якому містяться бази. Можна розгорнути резервну копію на сервері відновлення та запустити утиліту Eseutil для перевірки стану бази даних. Якщо база даних у порядку, слід перевірити апаратне забезпечення, щоб знайти причину помилки 1018. Якщо Eseutil показує, що деякі сторінки містять помилки, такі як порушення контрольних сум, це говорить про наявність серйозних проблем у базі даних, і заміни апаратного забезпечення не потрібно . Необхідно використовувати можливості Move Mailbox або утиліти ExMerge для переміщення поштових скриньок та даних на інший сервер, перш ніж база даних перестане працювати.

Сервер відновлення дозволяє визначити, наскільки довго Eseutil обробляє базу (тобто як довго робочий сервер функціонуватиме в автономному режимі, без обслуговування користувачів) і скільки місця займе оброблена база. Також сервер відновлення дозволяє тестувати додаткові програмні продукти, такі як засоби резервного копіювання або антивіруси, без залучення реального сервера. Багато продуктів чудово працюють у демонстраційному середовищі з обмеженими даними та починають давати збій на реальній системі у промисловому середовищі.

Апаратне та програмне середовище

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

Наявність відповідного сервера відновлення – лише частина проблеми. Знати, як відновлювати дані швидко та ефективно, — зовсім інша річ.

Відновлення сховища поштових скриньок

Після інсталяції Exchange 2000 на сервері відновлення, перш ніж виконувати на ньому регулярні процедури відновлення, слід виконати деякі дії. По-перше, потрібно використовувати Exchange System Manager (ESM) для зміни логічних імен груп сховищ та баз даних на сервері відновлення для збігу цих імен з відповідними іменами на вихідному сервері (імена потрібні під час створення груп сховищ та баз даних). Імена повинні збігатися повністю, включаючи ім'я вихідного сервера, якщо воно згадується в імені бази даних, а імена об'єктів на рівень нижче (наприклад, mailbox.edb) можуть бути різними. Використання простих імен для груп сховищ та баз даних в організації зменшує ймовірність помилок. На екрані 1 показана частина вікна ESM з логічними іменами сховищ та фізичними іменами файлів.

сервер
Екран 1. Логічне та фізичне ім'я бази даних.

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

відновлення
Екран 2. Увімкнення перезапису бази даних.

По-третє, перш ніж відновлювати дані, потрібно переконатися, що значення атрибута AD з ім'ям legacyExchangeDN для адміністративної групи та організації збігається зі значенням цього атрибута на вихідному сервері. Exchange 2000 використовує атрибут legacyExchangeDN для ідентифікації об'єктів та гарантованої зворотної сумісності елементів із попередніми версіями, у тому числі з Messaging API (MAPI). У разі сервера відновлення успішність процедури залежить від того, наскільки сховище відповідає AD, оскільки база даних при монтуванні реєструється в AD. Найпростіший спосіб, що гарантує збіги значень для адміністративної групи та організації, - призначити ті самі параметри вихідного сервера під час встановлення Exchange 2000 на сервері відновлення. Однак, якщо в організації вже встановлено сервер Exchange 2000 з іншим значенням legacyExchangeDN, можна використовувати утиліту LegacyDN з папки utils oolsi386 комплекту Exchange 2000 Service Pack 1 (SP1) або старше для визначення потрібного значення перед процедурою відновлення даних. Фактично, створюється копія вихідної системи. Необхідні зміни можна внести за допомогою утиліт Lightweight Directory Access Protocol (LDAP), таких як ADSI Edit абоLdifde, але простіше користуватися LegacyDN.

Не варто запускати LegacyDN у робочому середовищі. У цьому випадку легко припуститися помилки, яка може вплинути на організацію Exchange, після чого доведеться відновлювати AD і всі сервери Exchange 2000.

На екрані 3 показано, як працює утиліта LegacyDN. У прикладі сервер відновлення - restoreserver в домені restoredomain.com. Під час запуску LegacyDN на сервері утиліта сканує AD та шукає існуючі адміністративні групи. Можна вибрати адміністративну групу та змінити атрибут на те значення, яке потрібно для відновлення бази даних. Можна відновити базу зі стрічки без зміни цих значень, але процес Store не монтуватиме відновлену базу, оскільки в неї legacyExchangeDN з поточним значенням не співпаде.

У прикладі на екрані 3 показано, що база даних відновлюється з адміністративної групи NSIS European Messaging Team в організації Compaq. Для застосування цих значень після введення їх у відповідні поля слід натиснути на Change Leg. Після цього треба перезапустити процес Store, щоб ці зміни подіяли. Атрибут legacyExchangeDN буде змінено з

/O=Compaq/OU=First Administrative Group

/O=Compaq/OU=NSIS European Messaging Team.

сервер
Екран 3. Використання утиліти LegacyDN.

/O=Compaq/OU=NSIS European Messaging Team

Можна побачити, що атрибути Exchange 2000 зберігають сумісність із Exchange Server 5.5, де за іменем організації також слідує ім'я вузла.

Після призначення відповідного legacyExchangeDN можна розпочинати відновлення бази даних. Спочатку слід розмонтувати базу даних на сервері відновлення та відтворити резервну копію вихідного сервера,перезаписав файли баз даних на диску.

Далі необхідно перевірити журнал Application і переконатися, що утиліта відновлення або Extensible Storage Engine (ESE) впоралася зі своїм завданням і відновлена ​​база була змонтована. Часто відбувається збій, коли ім'я бази з резервної копії відрізняється від імені цільової бази або коли Store не може змонтувати базу даних після успішного відновлення через розбіжність значення legacyExchangeDN у відновленій та цільовій базах.

У цьому випадку Store реєструє у журналі Application подію з >

Відповідність облікових записів та поштових скриньок

Необхідно виконати й ряд кроків щодо зв'язку поштових скриньок та облікових записів. По-перше, треба створити обліковий запис AD (ім'я може не збігатися з оригінальним).

По-друге, слід підключити новий обліковий запис до поштової скриньки у відновленій базі. Найпростіший спосіб асоціації поштової скриньки – використовувати Mailbox Cleanup Agent в ESM. Для виклику агента потрібно відкрити сховище поштових скриньок, вибрати Mailboxes, викликати контекстне меню та вказати Run Cleanup Agent. Mailbox Cleanup Agent сканує сховище поштових скриньок, знаходить поштові скриньки, які не мають зв'язку з обліковим записом, і відзначає їх червоним кружком з хрестиком.

На екрані 5 показаний результат роботи агента. Всі поштові скриньки видно, але деякі позначені як такі, що не мають відповідності з обліковим записом, що відображено в колонці Last Logged on By. В результаті роботи Mailbox Cleanup Agent можна побачити SID, відповідний облікового запису AD, з яким останній раз зверталися до поштової скриньки і якої немає в базі AD.

Правою кнопкою можна клацнути на скриньці та вибрати Reconnect для зв'язку з обліковим записом AD. Якщо потрібно підключити декілька поштовихящиків, можна використовувати утиліту Mbconn з каталогу supportutilsi386 диска Exchange 2000 (додаткова інформація про Mbconn наведена в статті Microsoft «XADM: Як використовувати Mbconn Utility для створення Active Directory Accounts for Information Store Mailboxes», http://support.microsoft).

com/?kb >Відновлення бази даних на іншому сервері — складне завдання, яке вимагає наявності відповідного апаратного та програмного забезпечення.

Поділіться матеріалом з колегами та друзями