Оглавление
Ошибка базы
[PS] C:\Windows\system32>Mount-Database DB_TEMP_2011_2006
Confirm
At least one committed transaction log file is missing. Mounting this database will result in data loss. If you can
locate the missing log files, don't continue. Are you sure you want to continue?
[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): A
Failed to mount database "DB_TEMP_2011_2006". Error: An Active Manager operation failed. Error: The database action
failed. Error: Operation failed with message: MapiExceptionJetErrorRequiredLogFilesMissing: Unable to mount database.
(hr=0x80004005, ec=-543)
Diagnostic context:
Lid: 65256
Lid: 10722 StoreEc: 0xFFFFFDE1
Lid: 1494 ---- Remote Context Beg ----
Lid: 1238 Remote Context Overflow
Lid: 34760 StoreEc: 0xFFFFFDE1
Lid: 41344 Guid: 680b5538-3fad-49fa-8d95-f7c8b47a6ca6
Lid: 35200 dwParam: 0x6DE0
Lid: 59596 dwParam: 0x2271F6AE Msg: JI20
Lid: 43212 dwParam: 0x2271F6AE Msg: JT05
Lid: 43212 dwParam: 0x2271F6AE Msg: JT08
Lid: 59596 dwParam: 0x2271F6AE Msg: WM19
Lid: 59596 dwParam: 0x2271F6AE Msg: WM20
Lid: 59596 dwParam: 0x2271F6AE Msg: WM21
Lid: 56264 StoreEc: 0x980
Lid: 46280 StoreEc: 0xFFFFFDE1
Lid: 10786 dwParam: 0x0 Msg: 15.02.1544.004:V19MBX1:680b5538-3fad-49fa-8d95-f7c8b47a6ca6
Lid: 51578 Guid: 680b5538-3fad-49fa-8d95-f7c8b47a6ca6
Lid: 1750 ---- Remote Context End ----
Lid: 1047 StoreEc: 0xFFFFFDE1 [Database: DB_TEMP_2011_2006, Server: V19MBX2.CTDRUS.loc]
+ CategoryInfo : InvalidOperation: (DB_TEMP_2011_2006:ADObjectId) [Mount-Database], InvalidOperationExcep
tion
+ FullyQualifiedErrorId : [Server=V19MBX1,RequestId=7f1dfc8b-f98e-426e-9ecc-5bc364e7a127,TimeStamp=12/16/2024 2:32
:27 PM] [FailureCategory=Cmdlet-InvalidOperationException] 2D27BA9D,Microsoft.Exchange.Management.SystemConfigurat
ionTasks.MountDatabase
+ PSComputerName : v19mbx1.ctdrus.loc
Проверим состояние базы
[PS] C:\Windows\system32>Eseutil /mh E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.02
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Database: E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb
DATABASE HEADER:
Checksum Information:
Expected Checksum: 0xb1fc8819
Actual Checksum: 0xb1fc8819
Fields:
File Type: Database
Checksum: 0xb1fc8819
Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,20,0 (attached by 0)
Engine ulVersion: 0x620,60,140 (efvCurrent = 9060)
Created ulVersion: 0x620,20
DB Signature: Create time:11/02/2022 13:42:05.242 Rand:3548611131 Computer:
cbDbPage: 32768
dbtime: 170213332 (0xa253fd4)
State: Dirty Shutdown
Log Required: 547808-547910 (0x85be0-0x85c46)
Log Committed: 0-547911 (0x0-0x85c47)
Log Recovering: 543317 (0x84a55)
Log Consistent: 547808 (0x85be0)
GenMax Creation: 12/16/2024 13:50:09.007 UTC
Shadowed: Yes
Last Objid: 10507
Scrub Dbtime: 0 (0x0)
Scrub Date: 00/00/1900 00:00:00.000 LOC
Repair Count: 0
Repair Date: 00/00/1900 00:00:00.000 LOC
Old Repair Count: 0
Last Consistent: (0x76DA6,D8,B0) 02/23/2024 12:14:05.386 UTC
Last Attach: (0x76DA7,2,268) 02/23/2024 13:16:25.908 UTC
Last Detach: (0x0,0,0) 00/00/1900 00:00:00.000 LOC
Last ReAttach: (0x844BD,2,268) 12/09/2024 22:02:13.610 UTC
Dbid: 1
Log Signature: Create time:11/02/2022 13:42:05.195 Rand:2981120043 Computer:
OS Version: (6.2.9200 SP 0 NLS ffffffff.ffffffff)
Previous Full Backup:
Log Gen: 494404-494533 (0x78b44-0x78bc5) - OSSnapshot
Mark: (0x78BC6,1,0)
Mark: 05/05/2024 11:02:18.055 UTC
Previous Incremental Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Previous Copy Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Previous Differential Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Current Full Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Current Shadow copy backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
cpgUpgrade55Format: 0
cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0
ECC Fix Success Count: none
Old ECC Fix Success Count: none
ECC Fix Error Count: none
Old ECC Fix Error Count: none
Bad Checksum Error Count: none
Old bad Checksum Error Count: none
Last Database Maintenance Finish Date: 00/00/1900 00:00:00.000 LOC
Current Database Maintenance Start Date: 10/17/2024 19:58:48.023 UTC
Highest Continuous Database Maintenance Page: 0
Highest Database Maintenance Page: 0
Database Header Flush Signature: Create time:12/16/2024 14:37:12.211 Rand:3345693962 Computer:
Flush Map Header Flush Signature: Create time:00/00/1900 00:00:00.000 Rand:0 Computer:
Проверяем путь до базы
[PS] C:\Windows\system32>Get-MailboxDatabase -identity DB_TEMP_2011_2006 | fl Name,EdbFilePath,LogFolderPath
Name : DB_TEMP_2011_2006
EdbFilePath : E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb
LogFolderPath : F:\DB_TEMP_2011_2006
Восстановите файл базы данных с помощью файлов журнала:
Сначала проверьте состояние файлов журнала, используя следующую команду.
eseutil /ml "F:\DB_TEMP_2011_2006\E00″
[PS] C:\Windows\system32>eseutil /ml "F:\DB_TEMP_2011_2006\E00"
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.02
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Verifying log files...
Base name: E00
Log file: F:\DB_TEMP_2011_2006\E0000078B44.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B45.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B46.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B47.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B48.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B49.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4A.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4B.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4C.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4D.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4E.log - OK
Log file: F:\DB_TEMP_2011_2006\E0000078B4F.log - OK
Запускаем восстановление базы . При колличестве 80к логов и размера базы в 380гб , восстановление длилось 61 минуту.
Eseutil /r E00 /l F:\DB_TEMP_2011_2006 /d E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb /i
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.02
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating RECOVERY mode...
Logfile base name: E00
Log files: F:\DB_TEMP_2011_2006
System files: <current directory>
Database Directory: E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb
Performing soft recovery...
Restore Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................
Operation completed successfully in 4274.250 seconds.
Проверяем еще раз
[PS] C:\Windows\system32>Eseutil /mh E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.02
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Database: E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb
DATABASE HEADER:
Checksum Information:
Expected Checksum: 0x6caaad10
Actual Checksum: 0x6caaad10
Fields:
File Type: Database
Checksum: 0x6caaad10
Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,20,0 (attached by 0)
Engine ulVersion: 0x620,60,140 (efvCurrent = 9060)
Created ulVersion: 0x620,20
DB Signature: Create time:11/02/2022 13:42:05.242 Rand:3548611131 Computer:
cbDbPage: 32768
dbtime: 193843538 (0xb8dd152)
State: Dirty Shutdown
Log Required: 543320-543320 (0x84a58-0x84a58)
Log Committed: 0-543321 (0x0-0x84a59)
Log Recovering: 0 (0x0)
Log Consistent: 543320 (0x84a58)
GenMax Creation: 12/16/2024 16:07:21.497 UTC
Shadowed: Yes
Last Objid: 11127
Scrub Dbtime: 0 (0x0)
Scrub Date: 00/00/1900 00:00:00.000 LOC
Repair Count: 0
Repair Date: 00/00/1900 00:00:00.000 LOC
Old Repair Count: 0
Last Consistent: (0x84A56,1,31) 12/16/2024 16:07:13.858 UTC
Last Attach: (0x84A56,5,268) 12/16/2024 16:07:21.400 UTC
Last Detach: (0x0,0,0) 00/00/1900 00:00:00.000 LOC
Last ReAttach: (0x84A59,2,268) 12/16/2024 17:45:21.674 UTC
Dbid: 1
Log Signature: Create time:11/02/2022 13:42:05.195 Rand:2981120043 Computer:
OS Version: (6.2.9200 SP 0 NLS ffffffff.ffffffff)
Previous Full Backup:
Log Gen: 494404-494533 (0x78b44-0x78bc5) - OSSnapshot
Mark: (0x78BC6,1,0)
Mark: 05/05/2024 11:02:18.055 UTC
Previous Incremental Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Previous Copy Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Previous Differential Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Current Full Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Current Shadow copy backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
cpgUpgrade55Format: 0
cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0
ECC Fix Success Count: none
Old ECC Fix Success Count: none
ECC Fix Error Count: none
Old ECC Fix Error Count: none
Bad Checksum Error Count: none
Old bad Checksum Error Count: none
Last Database Maintenance Finish Date: 00/00/1900 00:00:00.000 LOC
Current Database Maintenance Start Date: 10/17/2024 19:58:48.023 UTC
Highest Continuous Database Maintenance Page: 0
Highest Database Maintenance Page: 0
Database Header Flush Signature: Create time:12/16/2024 17:45:21.674 Rand:205634769 Computer:
Flush Map Header Flush Signature: Create time:00/00/1900 00:00:00.000 Rand:0 Computer:
Operation completed successfully in 0.110 seconds.
[PS] C:\Windows\system32>
В логах указано, что для восстановления необходим только один лог: 543320-543320. Убедитесь, что файл лога с именем E00543320.log
находится в директории F:\DB_TEMP_2011_2006
.
Лога нет придется восстановится хардом и так что мы имеем
Состояние базы данных:
State: Dirty Shutdown
База данных не была корректно закрыта. Это значит, что есть изменения, которые хранятся в логах, но ещё не применены к базе .edb
.
Требуемые логи (Log Required):
Log Required: 543320-543320 (0x84a58-0x84a58)
База данных ожидает применения транзакционного лога с номером 543320
. Этот лог содержит незавершённые транзакции, которые не были записаны в файл базы данных .edb
.
Последний зафиксированный лог (Log Committed):
Log Committed: 0-543321 (0x0-0x84a59)
Это значит, что все операции до лога с номером 543320
(и включая его) были зафиксированы в логах, но не все из них перенесены в .edb
. Лог 543321
является первым логом, который был полностью завершён.
Последнее согласованное состояние базы (Last Consistent):
Last Consistent: (0x84A56,1,31) 12/16/2024 16:07:13.858 UTC
Это последний момент времени, до которого база данных была полностью согласованной. Изменения, произошедшие после этого времени, ещё не записаны в файл .edb
— они находятся в логах.
Последний присоединённый лог (Last Attach):
Last Attach: (0x84A56,5,268) 12/16/2024 16:07:21.400 UTC
Это время последней попытки работы базы данных с логами. Здесь видно, что база данных пыталась обработать изменения, записанные в логах, но операция не была завершена.
Что произойдет при Hard Repair (eseutil /p
)
На какой момент вы откатитесь?
Hard Repair удалит из базы данных .edb все ссылки на транзакции, которые хранятся в логах и ещё не были применены. База данных будет восстановлена на момент времени, указанного в Last Consistent
Last Consistent: 12/16/2024 16:07:13.858 UTC
Все данные и изменения, которые произошли после 16:07:13 16 декабря 2024 года, будут утеряны. Это включает все письма, созданные, отправленные, удалённые или изменённые после этого времени.
Поскольку Hard Repair игнорирует логи (Log Required), любые данные, находящиеся в этих логах, не будут применены. Даже если эти логи физически присутствуют на диске, они больше не будут связаны с базой после Hard Repair.
Всё, что было зафиксировано в базе до Last Consistent (12/16/2024 16:07:13), сохранится. Если логи 543320 и 543321 важны, попробуйте сначала сохранить их копии если такова есть. Если это невозможно, то Hard Repair — ваш последний вариант.
Hard Repair просто отбрасывает все незавершённые транзакции из логов, потому что цель этой операции — «починить» базу .edb
, даже если для этого приходится терять часть данных.
Hard Repair базы данных с помощью утилиты Eseutil
еред жестким восстановлением сделайте резервную копию базы данных и убедитесь, что на диске достаточно свободного места (эквивалентно размеру базы данных). Обязательно нужно столько места сводобного сколько весит база +10%
eseutil /p "E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb"

Большие базы данных (>100 ГБ): Восстановление может занять несколько часов или даже дней, в зависимости от состояния базы и логов.

3 часа процесс

Конечный результат. 419 минут = 7 часов
После завершения eseutil /p
, обязательно выполните проверку базы данных с помощью команды /mh
:
eseutil /mh "E:\Database\DB_TEMP_2011_2006\DB_TEMP_2011_2006.edb"
Проверьте, чтобы состояние изменилось на Clean Shutdown. Если база данных успешно восстановлена и находится в состоянии Clean Shutdown, она может быть смонтирована в Exchange.
После восстановления пользователи имели доступ к почтовым ящикам , но отправить и получить ничего не могли. Outlook писал что подключено, отключено . Множетсво почтовых ящиков падали в карантин.
Выход миграция в PST или миграция в другую базу.