Процедуры автономного архивирования и восстановления для Exchange (эта ссылка может указывать на содержимое полностью или частично на английском языке)

Переводы статьи Переводы статьи
Код статьи: 296788 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

В этой статье

Аннотация

В данной статье описаны методы можно использовать для обхода интерактивная программа резервного копирования, программные интерфейсы (API) и вручную архивировать и восстанавливать базы данных хранилища данных Exchange. При наличии нескольких групп хранения на одном сервере Exchange, каждая группа хранения необходимо учитывать независимых, самодостаточных подразделения в целях автономного архивирования и восстановления.Дополнительные сведения о создании автономной и моментальной резервной копии см. в следующей статье базы знаний Майкрософт::
296787XADM: Автономной архивации и восстановления для Exchange Server 4.0, 5.0 и 5.5

Дополнительная информация

Предварительная подготовка

Перед выполнением автономной резервной копии, убедитесь, что имеется следующая информация:
  • Определите, включено ли циклическое ведение журнала для группы хранения. (Циклический журнал отключен по умолчанию в Exchange.) Чтобы определить наличие или отсутствие включено циклическое ведение журнала, откройте окно свойствstorage_groupобъект диспетчера Exchange System Manager, а затем просмотритеОбщиеСтраница. Чтобы отключить циклическое ведение журнала, нажмите кнопку ОчиститьЦиклическое ведение журналаФлажок. Циклическое ведение журнала изменений вступают в силу до остановки каждой базы данных в группе хранения.

    При создании резервных копий в автономном режиме в отключении циклического ведения журнала нет необходимости.. Тем не менее необходимо отключить циклическое ведение журнала, если вы хотите воспроизвести журналы транзакций в восстановленных автономных резервных копий.
  • Определите путь расположения для базы данных Exchange, потоковая передача, журнал транзакций и файлов контрольных точек и префикс файла журнала для группы хранения.

    Чтобы найти эту информацию, откройте окно свойствstorage_groupобъект диспетчера Exchange System Manager, а затем просмотритеОбщиеСтраница. Запишите значения для следующих трех полей:
    • Префикс файла журнала(E0n, где может быть E0n E00, E01, E02 или E03)
    • Расположение журнала транзакций(E0n*.log)
    • Путь расположения системы(E0n.chk)
    Пути к базе данных, перечислены в свойства каждой базы данныхимя_базы_данныхОбъект. Запишите значения для следующих двух полей для каждой базы данных в группе хранения:
    • Базы данных Exchange(.edb)
    • Потоковая передача базы данных Exchange(.stm)
Если диспетчер Exchange System Manager, недоступен, можно найти все предыдущие данные, непосредственно чтения необработанных атрибуты из службы каталогов Active Directory с помощью средства ADSIEDIT или LDIFDE. Следующая команда LDIFDE можно использовать для вывода данных для всех серверов Exchange в лесу Active Directory.

Примечание.: Для удобства чтения, была разбита текст для данной команды.
-F LDIFDE EXPATHS.TXT -D "CN = CONFIGURATION, DC =configuration_container_domain,dc=top_level_domain«-L MSEXCHESEPARAMLOGFILEPATH, MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME MSEXCHESEPARAMCIRCULARLOG, MSEXCHSLVFILE,
MSEXCHEDBFILE - R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
Ниже приведен пример выходных данных из предыдущей команды:
Con -d D:\Exchsrvr\MDBData>LDIFDE -f "cn = configuration, dc = тест, dc = com «-l msexch eseparamlogfilepath, msexcheseparamsystempath, msexcheseparambasename, msexchesepar amcircularlog, msexchslvfile, msexchedbfile - r» (|(msexcheseparamlogfilepath=*) (ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*) (msexchedbfi le=*)(msexcheseparamcircularlog=*))"
Подключение к "dc1.child.test.com"
Вход от имени текущего пользователя с помощью SSPI
Экспорт в файл con каталога
Выполняет поиск элементов...

<output truncated=""></output>

.DN: CN первая группа хранилищ, CN = InformationStore, CN = Exchange1, CN = серверы, CN = Первая административная группа, CN = административные группы, CN = организация, CN = nge Excha корпорации Майкрософт, CN = службы, CN = Configuration, DC = = Test, DC = com
ChangeType: Добавление
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.DN: CN банк общих (EXCHANGE1), CN = первая группа хранилищ, CN = onStore Informati, CN = Exchange1, CN = серверы, CN = Первая административная группа, CN = административные группы, CN = организация, CN = Microsoft Exchange, CN = службы, CN = Configuration, DC = t проверки, DC = = com
ChangeType: Добавление
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.DN: CN банка личных (Exchange1), CN = первая группа хранилищ, CN = ionStore Informat, CN = Exchange1, CN = серверы, CN = Первая административная группа, CN = административные группы, CN = организация, CN = Microsoft Exchange, CN = службы, CN = Configuration, DC = st разработчиков, DC = = com
ChangeType: Добавление
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Для успешного воспроизведения журналов транзакций, для одного и того же пути расположения, из которого создавались резервные файлы необходимо восстановить файлы базы данных (.edb и .stm). Например если резервное копирование файла базы данных и потокового файла базы данных из папки F:\Mdbdata папок E:\Mdbdata, необходимо восстановить файлы E:\Mdbdata и F:\Mdbdata, соответственно. Это ограничение применяется, даже если вы хотите восстановить базу данных на совершенно другой сервер (например, в случае восстановление отдельного почтового ящика).

При изменении пути к базе данных после создания последней резервной копии, частично повторное воспроизведение журналов транзакций, и можно выполнить частичное воспроизведение только при изменении пути обратно в исходное местоположение. Если вернуться к старому пути, можно воспроизводить журналов до точки, с которой был изменен путь.

Восстановление журналов транзакций (E0n*.log) путь отличается от исходного расположения резервной копии. Это происходит потому, что журнал транзакций запись расположения базы данных, журналы транзакций, присоединенные к, но баз данных не записана расположение файлов журналов транзакций. Во время воспроизведения журналы «найти» базы данных, используя сведения о пути, который хранится в заголовках журналов транзакций. (Сети интерфейс API для архивирования внутренне компенсирует изменения в путь к базе данных и так это ограничение не применяется).

Вы не архивировать или восстанавливать файл контрольных точек (E0n.chk), но необходимо знать текущее расположение файла контрольных точек, поскольку необходимо проверить его или удалить во время восстановления.

Как связать файлы баз данных Exchange к друг

Файлы .edb и .stm, конечного хранилища для всех сведений из базы данных. Для большинства целей рассматривать эти два файла, как будто они находятся в один файл; резервного копирования и восстановления этих файлов в тандеме. Эти файлы должны оставаться синхронизированные хронологически друг с другом; файл .edb резервного копирования на один день не совпадает ни с файлом потокового резервного копирования на другой день.

Exchange 2000 или сервер Exchange 2003 поддерживает до четырех групп хранения, и каждая группа хранения может поддерживать до пяти баз данных. Группа хранения является набор баз данных, которые совместно используют общий набор файлов журнала транзакций. Microsoft Exchange Server 5.5 поддерживает не более одной группы хранения, которая поддерживает до двух баз данных (сведения о личных и общих хранилищ).

При внесении изменений в базу данных, изменения сначала записываются в текущий файл журнала транзакций, а затем в кэш в памяти. По мере изменения присутствуют в кэше, эти изменения становятся видимыми для пользователей. Страницы переносятся из кэша в файл базы данных при первой же подходящей возможности.. Контрольными точками отмечаются точки в последовательности файла журнала, соответствующие моментам, перед которыми все транзакции были физически перенесены в файл базы данных.. Это нормально для контрольной точки для запаздывания три или более файлов журнала за текущий файл журнала.

Во избежание путаницы, о том, какие файлы журналов к каждой группе хранения журналов Exchange, которые принадлежат к группе хранения, заданного присваиваются имена с префиксом уникальный журнал, что первые три символа в имени файла. Valid log prefixes for the four storage groups that are supported on an Exchange 2000 or Exchange 2003 server are E00, E01, E02, and E03. Throughout this article, the log prefix for a storage group is designated as E0n. The current log file for a storage group is always E0n.log.

Transaction logs are a uniform 5 megabytes (MBs) in size. When the current log file is full, it is renamed with a hexadecimal sequence number, called the log generation number, and a new current log file is generated. Log files are numbered as E0n00001.log, E0n00002.log, and so on. Throughout this article, numbered log files are designated generically as E0nxxxxx.log.

Аварийно остановки базы данных для восстановления целостности базы данных воспроизведение записей (E0n.chk) файл контрольной точки журнал транзакций, из которого должно начинаться восстановление. Этот процесс называется «мягким» восстановлением. Мягкое восстановление может быть от с «принудительное восстановление", который представляет собой процесс, с которой выполнен вход воспроизведение файлов после восстановления оперативной резервной копии. Самым важным различием между «мягким» и «жестким» восстановлением является интерполяция данных файла исправления в процесс воспроизведения файла журнала при «жестком» восстановлении..

Несовместимость файл базы данных Exchange представляет собой файл, все невыполненные транзакции не будет записано еще. Во время обычной работы файлы баз данных Exchange не согласованы, так как данные в кэше, который имеет не еще были записаны физического файла. Как правило файл базы данных Exchange может считаться согласованным только после обычного выключения службы базы данных. Тем не менее базы данных, сделанные в целом (считается как сумма информацию в файлы базы данных и журналов транзакций) всегда является согласованной, если необходимых журналов преждевременно удаляются.

Резервное копирование базы данных Exchange автономно

Резервное копирование базы данных Exchange автономной работы.
  1. Отключите базу данных, которые требуется архивировать. Необязательно для отключения всех баз данных в группе хранения базы данных или баз данных, которые требуется архивировать.
  2. Убедитесь, что файлы базы данных (файл .edb и .stm) согласованный и соответствующих друг другу. Для этого выполните следующую команду для каждого файла.
    файл базы данных Eseutil /mh | find /i "DB подписи"
    Примечание.: Exchange 2000 пакет обновления 2 или более поздней версии не отчет состояния базы данных как «Согласованность» или «Согласовано», а в качестве "Очистить Shutdown" или "Неправильное отключение". Понятие «Очистить завершение работы» совпадает с "Согласованность" и значение "Неправильное отключение" такой же, как «Согласовано». Exchange 2000 с пакетом обновления 2 (SP2) или более поздней версии запустите это дополнительные команды для определения состояния каждой базы данных:
    Eseutil /mh имя_базы_данных | find /i "Завершение"
    Ниже приведен пример выходных данных из предыдущей команды:
    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    							
    В предыдущем примере DB подписи совпадают, которая подтверждает, что файлы .edb и .stm принадлежат тот же набор. (Обе строки подписи должны соответствовать символ для знака в шифрованном считается соответствие подписи).

    Не только должны соответствовать подписи DB, но файлы также должны быть синхронизации друг с другом и согласованности. Для каждого файла, выполните следующую команду:
    файл базы данных Eseutil /mh | find /i "согласованный"
    Ниже приведен пример выходных данных, полученного в результате предыдущей команды.
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  04/04/2001 18:07:14
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  00/00/1900 00:00:00
    							
    В предыдущем примере, обоих файлов отчета "состояние: совместимости.» Шестнадцатеричные числа в скобки, для каждого файла (0x2CC7, 1F14, 1F7), также должны совпадать. Соответствует Last Consistent штамп времени не требуется. Эти файлы являются согласованность и соответствующих друг другу.

    Либо файл отчеты "состояние: недопустимые» или Last Consistent расположение журнала не синхронизированы, база данных не была полностью отключена. Присоединение и отсоединение базы данных еще раз. Если файлы по-прежнему не соответствуют неправильно или не согласованы, обратитесь в службу технической поддержки Майкрософт (PSS) для получения дополнительных сведений.
  3. Скопируйте каждый файл базы данных .edb и ее соответствующего .stm потокового файла базы данных, местоположение для резервного копирования.
  4. Подключение резервной копии базы данных.
  5. Если включено циклическое ведение журнала, пропустите этот шаг. Если циклическое ведение журнала отключено и требуется «накат» более поздней версии, необходимо создать резервные копии всех пронумерованных журнала транзакций (E0nxxxxxфайлы .log). Резервное копирование не E0n.log Res1.log и Res2.log файлов.

    Можно создать резервные копии пронумерованных файлов журнала в любое удобное время, даже непосредственно после создания, так как после файл журнала был переименован с E0n.log E0nxxxxx.log, Exchange не изменяет его снова. Тем не менее очистить резервную копию файлов журнала только в соответствии с инструкциями на шаге 6.

    Резервные копии файлов журнала нет однозначного соответствия с резервных копий базы данных. Каждая резервная копия файла журнала является ссылкой на последовательность файлов журналов, которую можно применить к любой из нескольких резервных копий базы данных.. Можно выполнить восстановление базы данных с повтором всех завершенных транзакций с определенной резервной копии базы данных, если существует непрерывная последовательность журналов, начиная с журнала, указанного в строке «Last Consistent» заголовка базы данных.. В этой статье последнего согласованного журнала называется «журналом привязки».

    При обращении в предыдущем примере последняя запись, согласованные является (0x2CC7, 1F14, 1F7). Первое число относится к файлу журнала, второе – к странице в этом файле журнала, а третье – смещение в байтах на этой странице.. Каждый файл журнала содержит приблизительно 10 000 страниц по 512 байт каждая.. Смещение страницы предоставляет хороший способ закрытия файла журнала является being полностью (файл журнала в предыдущем примере — около 80 процентов, поскольку эквивалентное десятичное 7956 0x1F14), но не имеет значения для восстановления. Восстановление всегда начинается с начала файла журнала..

    В этом примере файл журнала привязки — E0n02cc7.log.

    Не всегда виден последнего согласованного журнала на диске как нумерация журналов, поскольку последний журнал согласованности может по-прежнему имя E0n.log. Можно просмотреть последовательность номеров E0n.log со временем будет предоставлена, изучив заголовок файла журнала во время остановки базы данных (доступ запрещен для заголовка E0n.log во время работы базы данных).

    Для просмотра последовательного номера генерации журнала выполните следующую команду::
    Eseutil /ml [журнал] | find /i «lGeneration»
    Ниже приведен пример выходных данных из предыдущей команды:
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    Во многих случаях это более важно, чтобы убедиться, что хорошо, чем именно хорошей резервной копии каждой базы данных, резервные копии файла журнала. Это происходит потому, что каждая резервная копия базы данных может предоставить резервирование для других пользователей, но полное восстановление любой резервной копии базы данных зависит от сохранения каждого файла журнала после этой резервной копии.
  6. Этот шаг можно пропустите, если включено циклическое ведение журнала. Проверьте заголовок файла контрольных точек для определения наибольшим номером файл журнала, который может быть безопасно извлечено. Контрольная точка отслеживает минимальный номером файла журнала, необходимые для автоматического восстановления, если база данных аварийно остановлена. Чтобы проверить файл контрольной точки, выполните следующую команду:
    Eseutil /mk E0n.chk
    Ниже приведен пример выходных данных из предыдущей команды:
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    Третья строка строки контрольных точек содержит необходимую информацию (LastFullBackupCheckpoint запись используется оперативной резервной копии, но остается все нули, если оперативное резервное копирование не выполняется в базе данных). Формат положения журнала контрольной точки совпадает с последней операции согласованность в заголовке базы данных. В данном примере контрольная точка находится в E0002cc7.log.

    Если функция циклического ведения журнала отключена, файлы журнала накапливаются до тех пор, пока не будут удалены вручную или автоматически при создании резервной копии в оперативном режиме.. Если циклическое ведение журнала включено, нет особых управление старых файлов журнала необходим, так как служба базы данных автоматически удаляет старые файлы журнала, после контрольной точки проходит через их.

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

    Существенный:: Не удаляйте журнала контрольной точки.

    В этом примере можно удалить все журналы до E0002cc6.log.
  7. This step is optional. You can use the Esefile utility to verify the page-level integrity of the copied databases.

    The Esefile.exe file is available in the Support folder on the Exchange Server 5.5 Service Pack 3 CD-ROM, the Exchange 2000 Server installation CD-ROM, or the Exchange Server 2003 installation CD-ROM. You can also obtain the Esefile.exe file from Microsoft PSS. The Esefile utility works for .edb files from Exchange Server 5.0 and 5.5, Exchange 2000, and Exchange 2003.

    There is currently no method other than online backup to verify the checksums for each page of an .stm file. The .stm file contains raw data. All of the indexes and pointers that organize that data are in the .edb file. A problem in the .stm file causes some specific client data loss, but does not compromise the structural or logical integrity of the database as a whole.

    To verify the page checksums for an Exchange database, run the following Esefile utility command:
    esefile /sимя_базы_данных
    Ниже приведен пример выходных данных из предыдущей команды:
    E:\mdbdata>esefile /s priv.edb
    
    Checksumming
    0    10   20   30   40   50   60   70   80   90  100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................
    
    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers
    
    esefile completes successfully after 10 seconds
    							
    Uninitialized pages are acceptable, but in a database with no problems, there are 0 bad checksums and 0 wrong page numbers.

    If a database does not pass the Esefile utility integrity check, your best option is to restore an earlier backup that you know to be good, and to roll the database forward. If such a backup is not available, consult PSS for advice about how to repair or salvage the database.
  8. This step is optional. You can use the following command to verify the integrity of backed up log files:
    eseutil /ml E0n
    Ниже приведен пример выходных данных из предыдущей команды:
    k:\backups>eseutil /ml E00
    							
    Эту команду необходимо запустить из папки, содержащей резервной копии файлов журнала. Можно также запустить эту команду для выполнения текущей папки журнала, но если Eseutil пытается прочитать заголовок E0n.log во время выполнения любой базы данных в группе хранения, то сообщение об ошибке-1032 (JET_errFileAccessDenied).

    Эта команда обнаруживает повреждение файлов журнала, а также предупреждает, если файл журнала отсутствует в середине последовательности, или если существует несоответствие подписи между любой из файлов журнала.

Восстановление автономной резервной копии базы данных Exchange

В этом разделе описаны два способа восстановления автономной резервной копии.
  • Восстановление на заданный момент времени.. Воспроизведение файлов журнала не выполняется.. Теряются все данные, созданные после резервного копирования.
  • Восстановление базы данных с повтором завершенных транзакций.. Файлы журналов, созданные после резервного копирования воспроизводятся в базе данных. Если доступны все файлы журналов, могут быть сохранены все данные, созданный после резервного копирования. Если включено циклическое ведение журнала, необходимо выполнить восстановление из автономной резервной копии «момент времени», нельзя выбрать восстановление «накат».
Набор файлов, которые можно восстановить должен соответствовать следующим минимальным критериям:
  • Для точки восстановления на момент все остановки базы данных в группе хранения должны быть согласованы и должен быть файл действительным контрольной точки. Не следует удалять текущий файл контрольной точки или существующие файлы журнала.
  • Все базы данных в группе хранения должна быть остановлена и согласованным рулон прямого восстановления, и все файлы журналов, созданные после времени, которая была создана резервная копия должна существовать (включая текущий E0n.log). Файл контрольных точек должен быть удален.
If the file set does not meet the preceding conditions, restoration and replay might not necessarily fail, but you are likely to receive a -1216 error message (JET_errAttachedDatabaseMismatch) during soft recovery.

Dealing with a -1216 Error

Additional soft recovery safeguards in Exchange 2000 and later cause the -1216 error when Exchange detects data files that have been tampered with manually, and determines that running recovery with the current data set would result in the loss of previously existing data.

In earlier versions of Exchange, if the file set is incomplete, but is valid for a successful replay, soft recovery starts without further warning to the administrator. In Exchange 2000 and later, the administrator must specifically override the -1216 error by using Eseutil.

Point in Time Restoration of an Offline Backup

To perform a point in time restoration of an offline backup:
  1. If the database that you want to restore is currently mounted, dismount it. If any other databases in the storage group are dismounted, those databases' database and streaming files (.edb and .stm) must each be consistent and matched. (To verify consistency and matching, see step 2 in the "Backing Up an Exchange Database Offline" section of this article.)

    If all of the databases in the storage group are dismounted, all of the databases must be consistent, and a valid checkpoint file must also exist. A valid checkpoint file is a checkpoint file that was in use the last time that any of the databases in the storage group were running, that has a header that lists E0n.log as the checkpoint. If any database in the storage group is still mounted, the valid checkpoint file is the checkpoint file currently being used by the system. If any database in the storage group is running, a valid checkpoint exists.

    To verify the checkpoint file when all of the databases are stopped, run the following commands:
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    The following is an example of the output from the preceding commands:
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2cc7,1B59,1A)
    
    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
          lGeneration: 11463 (0x2cc7)
    							
    In the preceding example, the checkpoint is in the log with the lGeneration of 0x2cc7, which is e00.log. Therefore, the checkpoint can be considered valid.

    If the checkpoint is not valid, you might receive a -1216 error message (JET_errAttachedDatabaseMismatch) when you attempt to mount any database in the storage group. This issue can occur even if all of the databases in the storage group are consistent.
  2. Copy the backed up .edb and .stm files to the appropriate database and streaming file locations. (To find these locations, refer to the "Before You Begin" section of this article.) Verify that the restored files are consistent and matched.

    Примечание.: If copies of the database files that you want to restore already exist on the server, back these files up before you restore the database, even if the existing files are not startable. They might be repairable, and you might be able to salvage data from them by using the Exmerge utility.
  3. Mount the restored database. The database attaches itself to the end of the E0n.log file. After the database has been successfully started, no previously existing log files can ever be replayed into the database. Public folder databases that contain thousands of folders in the hierarchy may take a long time to start. Allow for at least one minute for every 1,000 folders in the hierarchy.

    In earlier versions of Exchange Server, you usually needed to run theISINTEG -patchcommand after you restored an offline backup of an information store database, to synchronize the information store database with the directory. When patching for an Exchange database is necessary, that patching is done automatically by the system, unless the database is restored to a different server, storage group, or logical database object, or the Active Directory object for the database has been deleted and re-created in Active Directory. In these cases, the following error message is logged in the Application event log.
    Тип события: ошибка
    Источник события: Хранилище почтовых ящиков MSExchangeIS
    Категория события: Общие
    КОД события: 1087
    Date: 5/4/2001
    Time: 8:33:42 PM
    Пользователь: н/Д
    Компьютер: EXCHANGE1
    Description: The information store was restored from an offline backup. In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched.
    To resolve this problem, you must click to select theЭта база данных может быть перезаписана при восстановленииcheck box in Exchange System Manager, in the Database properties of the database object.

Roll Forward Restoration of an Offline Backup

For the best chance of complete success replaying log files into a restored database:
  • Preserve a copy of all of the transaction logs that were created after the time of your oldest full backup.
  • Do not change a database path without making a new full backup immediately afterward.
  • Do not runESEUTIL /p-или-ESEUTIL /dwithout taking a new full backup immediately afterward.
  • Do not add or remove a database in a storage group without immediately making a full backup of all of the databases in the storage group.
To begin the restoration process:
  1. If the database that you want to restore is mounted, dismount it, and then copy the database files that you want to restore to the appropriate paths on the server. If copies of the database files that you want to restore already exist on the server, back these copies up before you restore the database, even if the existing files are not startable. The files may be repairable, and you may be able to use the Exmerge utility to salvage data from them.
  2. Dismount all of the databases in the storage group, and then run the following command against each database in the current storage group, and against each restored database file:
    ESEUTIL /MHdatabase_file_name| find /i "согласованный"
    Примечание.: Exchange 2000 пакет обновления 2 или более поздней версии не отчет состояния базы данных как «Согласованность» или «Согласовано», но как "Очистить Shutdown" или "Неправильное отключение". Понятие «Очистить завершение работы» совпадает с "Согласованность" и значение "Неправильное отключение" такой же, как «Согласовано». Exchange 2000 с пакетом обновления 2 (SP2) или более поздней версии запустите это дополнительные команды для определения состояния каждой базы данных:
    Eseutil /mh имя_базы_данных | find /i "Завершение"
    Ниже приведен пример выходных данных из предыдущей команды:
    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  04/12/2001 20:07:46
    
    
    I:\mdbdata<eseutil /mh PRIV.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  00/00/1900 00:00:00
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  04/12/2001 20:07:41
    
    J:\mdbdata>eseutil /mh PRIV2.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  00/00/1900 00:00:00
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  04/12/2001 20:05:04
    
    K:\mdbdata>eseutil /mh PRIV3.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  00/00/1900 00:00:00
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  04/12/2001 20:07:43
    
    L:\mdbdata>eseutil /mh PRIV4.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  00/00/1900 00:00:00
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  04/12/2001 20:07:46
    
    M:\mdbdata>eseutil /mh PUB.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  00/00/1900 00:00:00
    							
    This command has three purposes:
    • To verify that the database files are each consistent.
    • To verify that the .edb and .stm files for each database are a matched pair.
    • To identify the low and high anchor log files, which are the first and last log files that are required to successfully recover all data without generating a -1216 error. The lowest last consistent value across all databases is the low anchor log and the highest last consistent value is the high anchor log.
    В предыдущем примере файл журнала привязки является E0002ac8.log и файл журнала привязки, высокая — E0002cc7.log.
  3. Убедитесь, что подпись журнала, которые записываются в каждом заголовке базы данных подписи журнала привязки. Выполните следующую команду::
    ESEUTIL /MHимя_базы_данных| find /i «Подпись журнала»
    Eseutil /mllow_anchor_log| find /i "Подпись"
    Ниже приведен пример выходных данных из предыдущей команды:
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    
    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
          Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
          Signature: Create time:12/29/2000 21:6:40 Rand:67798 Computer:
          Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:
    							
    Файл журнала может сообщить несколько подписей. Первая подпись всегда подписи файла для журнала; остальные являются базы данных, которые были запущены во время создания файла журнала. В предыдущем примере подписи, записываются в файлы базы данных соответствует подписи журнала в журнал привязки.

    Не удается найти журнала привязки, не удается воспроизвести журналы вперед в этой базе данных. Не удается найти файл журнала привязки, не воспроизведении файлов журнала в любой базы данных. Существует два метода, который можно использовать для работы с журнала привязки отсутствует.
    • Можно удалить все файлы журнала. За все согласованность базы данных, их можно запустить без наличия файлов журнала, но будут потеряны все шансы на восстановление данных, которые еще не находится в файлы базы данных.
    • Для удаления базы данных с наименьшими значениями последнего согласованного до создания серии непрерывной журнала с низкой к высокой привязки и затем выполнить восстановление на остальные базы данных. При удаленной базы данных обратно в группу хранения, в них не воспроизведении дополнительные данные.
  4. Убедитесь, что текущий путь расположения базы данных таким же, как они были в то время, произведенных в резервной копии.

    Несмотря на то, что путь к журналу транзакций или рабочий путь можно изменить после создания резервной, можно выполнить только воспроизведение файлов журнала Если одного и того же места, которые они создавались резервные копии из файлов базы данных. Если вы не знаете из исходного расположения, выполните следующую команду:
    Eseutil /ml_Log "Last_Consistent"| find /i "Имя базы данных или узор"
    Ниже приведен пример выходных данных из предыдущей команды:
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
          1 f:\MDBDATA\PRIV3.edb
          2 g:\MDBDATA\PRIV4.edb
          3 d:\MDBDATA\PRIV.EDB
          4 e:\MDBDATA\PRIV2.edb
          5 h:\MDBDATA\PUB.EDB
    
    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
            streaming file: k:\MDBDATA\PRIV3.stm
            streaming file: l:\MDBDATA\PRIV4.stm
            streaming file: i:\MDBDATA\PRIV.stm
            streaming file: j:\MDBDATA\PRIV2.stm
            streaming file: m:\MDBDATA\PUB.stm
    							
    Примечание.: Если в журнал привязки E0n00001.log, он не будет иметь сведения о пути в его заголовке, так как заголовок для первого журнала в серии генерируется до первой базы данных никогда не подключен в журнал. В таком случае для получения сведений о пути к базе данных необходимо воспользоваться заголовком следующего журнала.. В редких случаях это также может быть верно и для журналов в более поздней версии первый из них, так как был создан или к последовательности журналов после создания журнала базы данных.
  5. Соберите все журналы, из количества привязки, как далеко вперед, насколько это возможно в непрерывной последовательности и скопировать эти журналы в текущем пути журналов транзакций. Не заменяйте журналы, которые уже находятся в месте на сервере без резервного этих журналов первым. Для этого необходимо восстановить файлы журнала из более чем один тип носителя резервной копии.

    В предыдущем примере привязки является E0002ac8.log и высокой привязки является E0002cc7.log. При проверке доступные журналы наибольшим номером журнала, можно найти может быть одно число меньше, чем необходимо (например, E0002cc6.log, вместо 2cc7). Обычно это происходит потому, что E0n.log еще не был заполнен и переименовать его номер в последовательности. Чтобы определить, является ли E0n.log фактически журнала высокой привязки, необходимо использовать следующую команду для проверкиlGenerationзначение в заголовке файла журнала:
    Eseutil /ml E0n.log | find /i «lGeneration»
    Ниже приведен пример выходных данных из предыдущей команды:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    Примечание.: Для просмотра заголовка файла журнала с помощью служебной программы Eseutil используйте/MLПереключение; для просмотра заголовка файла базы данных следует использовать/mhПараметр. Если перепутать параметры, выходные данные команды неверно.

    Как правило, журнал высокой привязки также максимально журнала доступны, но это не так если:
    • Файлы журнала были уничтожены в аварийной ситуации.

      -ИЛИ-
    • При восстановлении все базы данных за один раз в группе хранения.
    В первом случае которые часто возникают ошибки-1216 во время восстановления; во втором случае можно воспроизводить журнал пересылки файлов, даже за пределами журнала привязки, высокий, до тех пор, пока они продолжают последовательность lGeneration.
  6. Убедитесь, что все журналы совместно используют такую же подпись журнала и в непрерывной последовательности. Выполните следующую команду::
    Eseutil /ml E0n > filename.txt
    Ниже приведен пример выходных данных из предыдущей команды:
    d:\mdbdata>eseutil /ml E00 > logverify.txt
    
    d:\mdbdata>type logverify.txt
    
    Microsoft(R) Exchange Server(TM) Database Utilities
    Version 6.0
    Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved.
    
    Initiating FILE DUMP mode...
    
    Verifying log files...
          Base name: e00
    
          Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
          Log file: D:\exchsrvr\mdbdata\save1\E00.log
    
    No damaged log files were found.
    
    Operation completed successfully in 3.305 seconds.
    							
    Эта команда Eseutil выполняет три действия: проверяет каждый файл журнала на наличие повреждений, сообщает о любых пробелов в последовательности файла журнала и обнаруживает несоответствие подписи журнала.

    Все подписи должны совпадать на всех файлов журнала, которые могут использоваться для воспроизведения. Необходимо удалить все журналы, которые не имеют соответствующих подписи до начала воспроизведения.

    На этом этапе после удаления файлов, которые не прошли тесты проверки только файлы в папке журналов транзакций, журнал транзакций, файлы:
    • Это lGeneration непрерывной последовательности, начиная с файла журнала привязки и продолжая до по крайней мере файл журнала привязки, высокий и Кроме того, если это возможно.
    • имеют одинаковые подписи..
  7. Если журнал высокой привязки называется уже E0n.log, переименуйте его.
  8. Удалите файл E0n.chk путь К системной папке.

    В случае отсутствия файла контрольной точки Exchange Server начинает воспроизведение журналов из наименьшим номером файла журнала, доступные в папке журналов транзакций: журнала привязки. Если существует файл E0n.chk, Exchange Server начинает воспроизведение с контрольной точки, которые записываются в файл. Если E0n.chk указывает за пределы журнала привязки, воспроизведение не полностью для набора восстановленного файла. Во многих случаях Если допущена ошибка в файле контрольных точек, необходимо запустить на восстановление из резервной копии файлов базы данных.
  9. Последней проверки перед подключить группу хранения, убедитесь, что:
    • Все файлы базы данных присутствуют путей выполнения.
    • Только файлы журнала выполнения путь к журналу транзакций файлы, начинающиеся с журнала привязки и продолжить по крайней мере в журнал высокой привязки с наивысшим доступны журнала с именем E0n.log.
    • В путь К системной папке отсутствует файл E0n.chk.
    You should now be able to successfully mount the storage group and begin to replay transaction logs with this file set. Even after recovery finishes and the database starts, all of the data in all of the log files might not actually be recovered because of DB signature and path issues that are encountered during replay. The "Dealing with Database Signature and Path Mismatches" section of this article provides additional information about these issues.
  10. If the information store is not already running, start it, and then mount at least one database in the storage group. This causes soft recovery to run against all of the databases in the storage group.

    In earlier versions of Exchange Server, you usually need to run theISINTEG -patchcommand after you restore an offline backup of an information store database, to synchronize the database with the directory. When patching for an Exchange database is necessary, that patching is done automatically by the system, unless the database is restored to a different server, storage group, or logical database object, or the Active Directory object for the database has been deleted and re-created in Active Directory. In these cases, the following error message is logged in the Application event log.
    Тип события: ошибка
    Источник события: Хранилище почтовых ящиков MSExchangeIS
    Категория события: Общие
    КОД события: 1087
    Date: 5/4/2001
    Time: 8:33:42 PM
    Пользователь: н/Д
    Компьютер: EXCHANGE1
    Description: The information store was restored from an offline backup. In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched.
    To resolve this issue, you must click to select theЭта база данных может быть перезаписана при восстановленииcheck box in Exchange System Manager, in the Database properties of the database object.
Check the Application event log in the Microsoft Windows NT Event Viewer for any errors or anomalies that might occur when the database starts. An event 301 is displayed for each log file that is replayed. Watch carefully for errors and warnings during the recovery process.

Dealing with Database Signature and Path Mismatches

Databases, like log files, have their own signatures. But although log signatures do not change after the time that the E0n000001.log file is created, database signatures change whenever the physical topology of the database is altered, without the changes being tracked through the log files. Offline defragmentation or repair of a database with Eseutil changes the DB signature. After such an event, the database can be attached to the same log stream as before, but the database does not accept replay of any transactions that were performed while the database had its earlier signature. An earlier copy of the database does not accept replay of any transaction that was performed after the database's signature changed.

Так подписи базы данных таким образом, настоятельно рекомендуется осуществлять непосредственный полные резервные копии после автономной дефрагментации или восстановления базы данных. Если восстановить копию базы данных с более поздней версии старую подпись успешного воспроизведения до момента изменения подписи, но при потере всех изменений после этой точки.

Если пути к базе данных изменяются в середине последовательности журналов, эффект похож на изменения подписей: воспроизведение прерывается в момент от изменений. (Сети интерфейс API для резервного копирования предоставляет средства для повторного сопоставления пути при восстановлении; таким образом, Интернет интерфейс API для архивирования можно воспроизвести журналы полностью, даже если путь был изменен с момента создания резервной).

Подпись DB или DB путь проблемы, возникающие при воспроизведения, эти подписи DB или DB путь проблемы фиксируются в журнале событий приложений с событиями 301 воспроизведения для каждого файла журнала. Файлы журнала, которые после копии проблема может появиться успешного воспроизведения, но это только потому, что для одного и того же предупреждения несоответствия не регистрируется несколько раз. Как правило воспроизведение в конкретной базы данных усекается от точки, в которой первый DB подписи или путь ссылки на базы данных произошла ошибка.

Свойства

Код статьи: 296788 - Последний отзыв: 21 ноября 2010 г. - Revision: 3.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Ключевые слова: 
kbproductlink kberrmsg kbhowto kbmt KB296788 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:296788

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com