В течение нескольких недель у нашего сервера Exchange были проблемы с невыполнением заданий резервного копирования, что привело к тому, что наши обычно пустые диски журналов переполнились до точки, когда Exchange отключил базы данных и зарегистрировал различные ошибки, касающиеся воспроизведения файлов журналов. К сожалению, никто из команды резервного копирования не выполнил свою работу должным образом, поэтому на выходных у нас возникла ситуация сбоя, когда было отключено ~ 40 баз данных из-за наличия ~ 100 ГБ журналов, которые обычно занимают ~ 3 ГБ. Это заставило всех, кто работал в выходные, не смотреть на историю проблемы и вместо того, чтобы обращаться к кому-либо еще, включить циклическое ведение журнала после того, как всем в команде было сказано не делать этого, перемонтировать все базы данных и прекратить работу.
Мы еще не слышали о потере данных от каких-либо пользователей, но тот факт, что все базы данных столкнулись с этим, и что есть жалобы на сбои регистрации, сбои при воспроизведении и неожиданные отключения, я обеспокоен тем, что они могут быть.
Помимо увольнения группы резервного копирования, выходные контролируют и администратор, который решил включить циклическое ведение журнала после значительного промежутка времени между резервными копиями, не сохраняя журналы где-либо в случае необходимости восстановления из резервной копии и получения того, что мы могли вернуть, что такое как лучше всего определить, потеряли ли мы что-нибудь?
Есть ли какие-то особые события, которые могут быть похоронены в 3 000 000 записей журнала, охватывающих шестичасовой отрезок времени, пока это происходило? Рекомендуется ли выполнение проверки целостности? Дефрагментация в автономном режиме или в автономном режиме?
На сервере Exchange обычно происходит следующее: я удалил источник события и идентификатор, потому что все кажется общим и мало помогает определить, действительно ли все пошло на юг или просто испортило мой понедельник:
В момент «TIME» в копии «DATABASE» базы данных Microsoft Exchange на этом сервере произошла серьезная ошибка, из-за которой она прекратила свою функциональную деятельность. Ошибка, возвращаемая попыткой повторного монтирования, была «Есть только одна копия этой базы данных почтовых ящиков (DATABASE). Автоматическое восстановление недоступно.». Обратитесь к журналу событий на сервере для других хранилищ и событий «ExchangeStoreDb» для получения более конкретной информации о сбоях.
Информационное хранилище - DATABASE (9564) DATABASE: попытка записи в файл «F: \ Logs \ DATABASE \ E0Etmp.log» по смещению 1048576 (0x0000000000100000) для 0 (0x00000000) байтов завершилась неудачно через 0,000 секунд с системной ошибкой 112 (0x00000070 ): "На диске недостаточно места. ". Операция записи завершится ошибкой -1808 (0xfffff8f0). Если эта ошибка повторяется, возможно, файл поврежден, и его необходимо восстановить из предыдущей резервной копии.
Информационное хранилище - БАЗА ДАННЫХ (9564) БАЗА ДАННЫХ: невозможно создать новый файл журнала, поскольку база данных не может записывать данные на диск журнала. Привод может быть доступен только для чтения, на нем не хватает места, он неправильно настроен или поврежден. Ошибка -529.
Хранилище информации - DATABASE (9564) DATABASE: последовательность файлов журнала в «F: \ Logs \ DATABASE \» была остановлена из-за фатальной ошибки. Для баз данных, использующих эту последовательность файлов журнала, дальнейшее обновление невозможно. Пожалуйста, устраните проблему и перезапустите или восстановите из резервной копии.
Банк данных - БАЗА ДАННЫХ (9564) БАЗА ДАННЫХ: восстановление / восстановление базы данных завершилось неудачно, возникла непредвиденная ошибка -510.
Службе репликации почтовых ящиков Microsoft Exchange не удалось обработать задания в базе данных почтовых ящиков. База данных: DATABASE Ошибка: MapiExceptionMdbOffline: невозможно открыть хранилище сообщений. (hr = 0x80004005, ec = 1142) Контекст диагностики:
В момент «TIME» копия базы данных «DATABASE» на этом сервере обнаружила ошибку во время операции монтирования. Дополнительные сведения см. В журнале событий на сервере для событий «ExchangeStoreDb» или «MSExchangeRepl». Операция монтирования будет повторена автоматически.
Это автономный сервер, поэтому, похоже, ожидаются только ошибки одного копирования. В то время как это происходило, также регистрируются многочисленные ошибки клиентского доступа, которые я пропустил.
Я склонен думать, что у вас минимальная потеря данных, если таковая имеется. Я понимаю, что это звучит довольно резко, но основанием для моего мнения является то, что новые данные перестали поступать, когда диски заполнялись. Даже если вы действительно потеряете данные, то почти наверняка будут потеряны данные, которые были получены сервером непосредственно перед состоянием заполнения диска.
В момент заполнения диска Extensible Storage Engine (ESE) будет сбрасывать данные журнала в резервные журналы транзакций каждой базы данных перед отключением базы данных.
Обмен демонтировал магазины. Любая почта, поступающая из Интернета, будет помещена в очередь вашим вторичным MX (или отправителем, если у вас его нет) и будет отправлена позже или будет отправлена NDR (в этом случае отправитель будет знать об ошибке) сервером отправителя. Я полагаю есть шанс что отправитель отбросит сообщение из очереди без отчета о недоставке, но это вряд ли ваша проблема.
Клиенты Outlook не смогут подключиться к своим базам данных банка данных, поэтому новая электронная почта от внутренних клиентов вряд ли будет потеряна.
Вы упомянули об ошибках воспроизведения журнала транзакций. Это звучит немного тревожно, но, не зная масштабов этих неудач, трудно сказать. Из-за природы повторов журнала транзакций (то есть фиксации недавно записанных незафиксированных данных в базе данных) вероятность сбоев воспроизведения, влияющих на старые сохраненные данные, довольно низка. Если пользователи не видят проблем с новейшими данными в своих почтовых ящиках, они, вероятно, не собираются этого делать позже.
На самом деле нет проблем, связанных с фрагментацией базы данных, связанных с состоянием заполнения диска. Шаблоны записи в базу данных не изменятся, потому что объем журнала транзакций заполнен. Дефрагментация в Интернете все равно будет выполняться, как обычно. Офлайн-дефрагментация обычно больше не требуется и не рекомендуется Microsoft.
Возможно, если бы базы данных хранились на заполненных томах, файлы EDB могли бы иметь фрагментацию файловой системы, но, вообще говоря, Microsoft не рекомендует дефрагментировать тома, содержащие базы данных Exchange. Вы можете поразить свои файлы .EDB с помощью contig.exe проанализировать их фрагментарность, если вы хотите убедиться.
ESE - это действительно надежный. Думаю, ты в порядке.