Расположение для logfolderpath находится не на жестком диске
This cmdlet is available only in on-premises Exchange.
Use the Move-DatabasePath cmdlet to set a new path to the location of a database on the specified Mailbox server and to move the related files to that location.
For information about the parameter sets in the Syntax section below, see Exchange cmdlet syntax.
Examples
Перенос базы Exchange 2010, состоявшей в DAG
В том случае, если почтовая база Exchange находится в группе DAG (Database Availability Group) и реплицируется на другие сервера, пункт Move Database Path будет недоступен. В этом случае для осуществления переноса придется удалить все копии за исключением активной, после чего можно будет осуществить перенос и вновь настроить пассивные копии. Не забудьте, что после переноса почтовые базы на всех серверах DAG должны находиться в одинаковых каталогах. Опять же не забудьте про простой почты, и в принципе в этом случае предпочтительнее создать новую базу, настроить ее копии и осуществить перенос ящиков, а не базы целиком.
Иногда появляется необходимость переместить базу данных Exchange сервера на другой диск в другое расположение. Сделать это возможно через Power Shell с помощью командлета Move-Database. Первым параметром передаем имя базы, которую необходимо переместить, вторым путь куда мы ее хотим переместить, а так-же путь к лог файлам.
Move-DatabasePath –Identity MailboxDatabaseName –EdbFilePath E:\DB1\DB1.edb –LogFolderPath G:\Logs\DB1
Обрати внимание на то что база будет отмонтирована и для пользователей будет недоступна пока не закончится ее перемещение в другое расположение!
- Получить ссылку
- Электронная почта
- Другие приложения
Комментарии
Очистка папки Logging в Exchange
Большое количество логов различных служб хранятся в каталоге Logging (например, в Exchange 2013 это C:\Program Files\Microsoft\Exchange Server\V15\Logging). Со временем все эти логи начинают занимать довольно много места.
Особо стоит отметить логи диагностики и производительности в C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics (при включенной диагностике на высоком уровне они могут занимать десятки гигабайт).
Вы можете автоматически очищать старые логи Exchange в этих папках:
gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging’,’C:\inetpub\logs’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-21) | Remove-Item
gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-5) | Remove-Item
Можно добавить эти команды в задание Task Scheduler.
Восстановление баз данных Exchange 2013
БД является конечным местом хранения данных, но в процессе работы может наблюдаться ситуация, когда часть информации занесена только в журналы транзакций, а в базу данных попасть ещё не успела. Все это приводит к тому, что база данных находится в несогласованном состоянии и это абсолютно нормально. Этот процесс очень хорошо показан на иллюстрации 1 :
Зеленым цветом как раз обозначены данных, которые попали в журналы транзакций, но ещё не были применены к базе. Этот механизм работает автоматически, примененные транзакции отслеживаются с помощью файла контрольных точек (checkpoint file). Подробнее читайте в Хранилище Exchange 2013 — Принцип работы.
В процессе корректного отключения базы данных информация в журналах и во временной базе сбросится в основную БД, база размонтируется и будет находиться в состоянии Clean Shutdown:
Журналы транзакций после этого уже не нужны, ведь информация в них по сути будет дублироваться с основной базой. Они могут потребоваться лишь для сценариев восстановления поврежденной БД и вручную удалять их нельзя.
Если же работа сервера была завершена аварийно или произошло некорректное отключение БД, то состояние базы будет Dirty Shutdown:
Как минимум это означает, что база данных находится в несогласованном состоянии и для исправления этой ситуации необходимо применить к ней недостающие транзакции, которые на момент до сбоя были зафиксированы только в журналах транзакций (строчка Log Required явно намекает на это). Этот процесс называется мягкое восстановление (Soft Recovery) и подразумевает следующее:
- Файл базы данных находится в исправном состоянии;
- Существуют и находятся в исправном состоянии все необходимые журналы транзакций.
В противном случае необходимо проводить грубое восстановление (Hard Recovery), в процессе которого неминуемо будет потеря данных. Сколько именно информации не удастся восстановить, зависит от конкретной ситуации. Вполне возможно, что восстановить базу из резервной копии в этом случае будет более правильным решением. В любом случае ниже мы рассмотрим все возможные сценарии.
Перенос почтовой базы Exchange 2010 с помощью Exchange Management Shell
Ту же самую операция можно выполнить и из командной строки Exchange Management Shell, для чего введите следующую команду:
И так же как в графическом мастере появится запрос о необходимости подтвердить отмонтирование почтового хранилища перед его переносом.
Логи базы данных очередей в Exchange 2013/2016/2019
Syntax
Example 1
This example sets a new path for the mailbox database specified by the mailbox database name. To perform the move operation, the database must be temporarily dismounted, making it inaccessible to all users. If the database is currently dismounted, it isn't remounted upon completion.
Мягкое восстановление
Как только вы обнаружили проблемы с базой данных, необходимо действовать в следующем порядке:
- Проверить состояние БД (Если в свойстве State видим Clean Shutdown, то все хорошо. Если Dirty Shutdown, двигаемся дальше);
- Убедиться, что присутствуют все журналы транзакций и что находятся они в исправном виде;
- Попытаться выполнить мягкое восстановление (Soft Recovery).
Для начала перейдем в каталог с базой данных, чтобы постоянно не прописывать полный путь до файлов:
Ротация и удаление IIS логов в Exchange
В логах IIS накапливается информация о подключениях к почтовым ящикам Exchange через OWA и ActiveSync. Со временем логи IIS, генерируемые пользователями при доступе к Exchange, могут занимать довольно много места.
Вы можете автоматически удалять старые логи IIS. Можно сделать автоматическое задание в планировщике Windows, которое запускается каждый день и удаляет логи IIS старше 30 дней:
set-location c:\inetpub\logs\LogFiles\W3SVC1\
foreach ($File in get-childitem) if ($File.LastWriteTime -lt (Get-Date).AddDays(-30)) del $File
>
>
Осталось создать новое задание в планировщике, которое должно запускать ваш PS1 скрипт очистки логов.
Чтобы Windows не блокировало запуск PowerShell скриптов, нужно изменить настройки политики PowerShell Execution, подписать PS1 файл или запускать его в планировщике с аргументами: powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -File c:\ps\clear_iis_logs.ps1
Если вам нужны старые логи IIS для анализа и траблшутинга, вы можете перенести их на другой диск:
Также можно изменить путь к логам IIS через PowerShell:
Import-Module WebAdministration
Set-ItemProperty ‘IIS:\Sites\Default Web Site’ -name logfile.directory "F:\IISLogs"
Outputs
To see the return types, which are also known as output types, that this cmdlet accepts, see Cmdlet Input and Output Types. If the Output Type field is blank, the cmdlet doesn't return data.
27.10.2021
itpro
Exchange, PowerShell
Один комментарий
После развертывания Exchange вы можете заметить, что свободное место на дисках начинает очень быстро уменьшаться. Помимо роста самых почтовых баз данных, в Exchange очень много место съедают различные логи. Особенно сильно проблема большого размера логов актуальна для версий, начиная с Exchange 2013. Если не использовать механизмы очистки логов, очень часто бывают случаи, когда почтовые базы аварийно отмонтируются и почтовый сервис становится недоступным для пользователей (часто сопровождается ошибкой 4.3.1 Insufficient system resources) из-за того, что логи Exchange заняли все свободное место на диске. В этой статье мы рассмотрим несколько стратегий очистки (усечения) и перемещения лог файлов в Exchange Server 2013/2016/2019.
Транзакционные логи в Exchange
Транзакционные логи баз данных это важный элемент в Exchange Server. При отправке/получении любого письма Exchange сначала вносит информацию в транзакционный лог, и только потом сохраняет элемент непосредственно в базу данных. Транзакционные логи содержат все операции, которые выполняются с базой данных и крайне важны для ее восстановления. Размер одного лог файла 1 Мб. Таких файлов может быть очень много, их количество зависит от активности пользователей в базе данных.
Есть несколько способов очистки транзакционных логов:
- Выполняйте регулярное резервное копирование почтовых баз Exchange. При корректном резервном копировании, транзакционные логи, которые более не нужны для восстановления базы данных, автоматически очищаются. Используйте любое современное решение для резервного копирования Exchange (обязательно должно поддерживаться копирование через Volume Shadow Copy – VSC). Можно использовать даже встроенный Windows Server Backup (пример);
- Включите Circular Logging для транзакционных логов. В этом случае файл транзакции автоматически удаляется, после того как данные из него сохранены в базу данных. Вы можете включить Circular Logging из EAC ( Enable Circular logging в свойствах базы) или PowerShell: Set-MailboxDatabase mbxDBname1 -CircularLoggingEnabled $true (для применения изменений нужно перемонтировать базу);
- Переместите базу Exchange с транзакционными логами на новый диск большого размера. По умолчанию при установке Exchange первая почтовая база сохраняется в каталог C:\Program Files\Microsoft\Exchange Server\… Желательно переместить почтовые базы с системного диска C: на другой. Для этого используется командлет Move-DatabasePath. Например, чтобы переместить базу и транзакционные логи на диск F:, выполните команду: Move-Databasepath mbxDBname1 –EdbFilepath “F:\DB\mbxDBname1\mbxDBname1.edb” –LogFolderpath “F:\DB\mbxDBname1\logs\”
Перенос базы Exchange 2010 с помощью EMC
Откройте консоль EMC и перейдите в раздел Organization Configuration->Mailbox. На вкладке со списком почтовых баз (Database Management), щелкните правой кнопкой мыши по базе, которую хотите перенести и выберите пункт меню Move Database Path.
Укажите новое местоположение файла и путь к файлам журнала, затем нажмите кнопку Move.
Перед началом переноса почтовая база будет отмонтирована, что вы и должны далее подтвердить.
После этого начнется перенос фалов, продолжительность которого зависит от размера базы и скорости дисков.
Очистка транспортных логов Exchange
Вы можете проверить включены ли транспортные логи на вашем сервере и пути к ним с помощью следующих команд PowerShell:
Get-TransportService -Identity meskexch1 | fl *logpath*
Get-TransportService -Identity meskexch1| fl *logenabled*
Основные транспортные логи Microsoft Exchange Server по умолчанию хранятся в каталогах:
%ExchangeInstallPath%TransportRoles\Logs\Hub\Connectivity |
%ExchangeInstallPath%TransportRoles\Logs\MessageTracking (используется при отслеживании писем через Get-MessageTrackingLog) |
%ExchangeInstallPath%Logging\IRMLogs |
%ExchangeInstallPath%TransportRoles\Logs\Hub\ActiveUsersStats |
%ExchangeInstallPath%TransportRoles\Logs\Hub\ServerStats |
%ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive |
%ExchangeInstallPath%TransportRoles\Logs\Hub\Routing |
%ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend |
%ExchangeInstallPath%TransportRoles\Logs\Hub\QueueViewer |
%ExchangeInstallPath%TransportRoles\Logs\Hub\AgentLog |
Можно изменить каталог для хранения SMTP логов отправки/получения (Protocollogs) через EAC: Servers -> servers -> выберите сервер -> Transport Logs -> Protocol log.
Если нужно изменить каталог хранения логов отслеживания Message Tracking, измените значение в поле Message Tracking log path в EAC.
Останется только изменить путь к каталогу с логами с помощью командлета:
Set-TransportService meskexch1 –ReceiveProtocolLogPath “D:\ReceiveSMTPLosg”
Таким образом вы можете хранить любые другие транспортные логи в сетевой папке на удаленном сервере.
Description
When you use the Move-DatabasePath cmdlet, consider the following:
- This cmdlet fails if it's run while the database is being backed up.
- If the specified database is mounted when this cmdlet is run, the database is automatically dismounted and then remounted, and is unavailable to users while it's dismounted.
- In Exchange 2013 or earlier, you can only run this cmdlet on the affected Mailbox server. If you include the ConfigurationOnly parameter with the value $true, you can run the cmdlet on an administrator's workstation. This does not apply to Exchange 2016 or later (you can run the cmdlet anywhere).
- This cmdlet can't be run against replicated mailbox databases. To move the path of a replicated database, you must first remove all replicated copies, and then you can perform the move operation. After the move operation is complete, you can add copies of the mailbox database.
You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Восстановление базы данных Exchange Server 2016 средствами Windows Server Backup
Я целенаправленно, в целях демонстрации, через Exchange Admin Centr отмонтировал базу и имитирую ее удаление\повреждение (удалил файл .edb). Для восстановления я запускаю Windows Server Backup и перехожу в режим восстановления. Далее следую подсказкам мастера произвожу востановление базы в то-же расположение где она хранилась до удаления. Для восстановления выберем режим "Приложения" Восстановление базы Exchange Server 2016 прошло успешно. Необходимо проконтролировать состояние базы. Сделать это возможно например через Exchange Admin Centr. Меню "Серверы" - "Базы данных" покажет список баз, которые подключены к серверу. При необходимости восстановленную базу необходимо подключить\подминтировать.
Inputs
To see the input types that this cmdlet accepts, see Cmdlet Input and Output Types. If the Input Type field for a cmdlet is blank, the cmdlet doesn't accept input data.
PowerShell скрипт очистки логов Exchange
Можно объединить все рассмотренные выше команды для очистки старых логов Exchange в один PowerShell скрипт, который нужно запускать по расписанию:
$days = 15
$dirs=@(
"C:\inetpub\logs\LogFiles\",
"C:\Program Files\Microsoft\Exchange Server\V15\Logging\",
"C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\ETLTraces\",
"C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\Logs\",
"C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\"
)
Get-ChildItem $dirs -Recurse -File | Where-Object < $_.Name -like "*.log" -or $_.Name -like "*.blg" -or $_.Name -like "*.etl" >| Where-Object LastWriteTime -lt (Get-Date).AddDays(-$days) | Remove-Item -ErrorAction "SilentlyContinue"
29.08.2012
itpro
Exchange
Один комментарий
В этой статье поговорим о том, как в Exchange 2010 можно перенести базу с почтовыми ящиками в другой каталог. Напомним, что по умолчанию дефолтная база на сервере Exchange с ролью Mailbox создается в каталоге Mailbox в директории, куда установлен сам сервер Exchange (обычно это C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database). Естественно, у большинства администраторов возникает желание перенести почтовую базу и транзакционные логи в другой каталог. Сделать это можно из графической консоли Exchange Management Console (EMC) или же из командной строки Exchange Management Shell
Обычно такой перенос можно осуществить, если база пустая или содержит небольшое количество ящиков пользователей (ведь во время такого переноса база будет размонтирована), в противном случае, если длительный простой критичен, лучше создать новую базу в новом месте и перенести ящики из старой базы в новую (после чего старое хранилище можно удалить).
Восстановление базы Exchange Servera 2016 (сценарий 2)
Моделируем другую ситуацию. База "покараптилась", админ безответственно разместил ее на выделенном диске без резервирования (без RAID-а), появились проблемы доступности диска либо файлов на нем. Пользователи в панике, хотят работать. Шаг 1 ------------------------------------------------------------------------------------------------------------------------ 1. Создаем чистую базу данных (можно через Exchange Admin Centr) и монтируем ее: New-MailboxDatabase –Name “TempDB” –Server Lon-MBX1 -EdbFilePath C:\NewFolder\ TempDB .edb –LogFolderPath C:\NewFolder\ Mount - Database “ TempDB ” Выбираем все почтовые ящики, которые хранятся в битой базе данных и перекидываем их в новую базу (старая база при этом отмонтирована и недоступна). Get-Mailbox –Database MBD | Set-Mailbox –Database “TempDB1” Так-же рекомендуем перезапустить IIS - команда iisreset Пользователи при подключении увидят чистые почтовые ящики! Станут нарабатывать новую
Восстановление баз данных Exchange 2013 может потребоваться в разных ситуациях и в каждой из них сценарий действий может значительно отличаться в зависимости от состояния базы и наличия свежего бэкапа. В статье я рассмотрю порядок действий при некоторых наиболее часто встречающихся задачах.
Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.
Parameters
The ConfigurationOnly switch specifies whether to change the configuration of the database without moving any files. You don't need to specify a value with this switch.
If you don't use this switch, the configuration of the database changes and the files are moved.
Type: | SwitchParameter |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
The Confirm switch specifies whether to show or hide the confirmation prompt. How this switch affects the cmdlet depends on if the cmdlet requires confirmation before proceeding.
- Destructive cmdlets (for example, Remove-* cmdlets) have a built-in pause that forces you to acknowledge the command before proceeding. For these cmdlets, you can skip the confirmation prompt by using this exact syntax: -Confirm:$false .
- Most other cmdlets (for example, New-* and Set-* cmdlets) don't have a built-in pause. For these cmdlets, specifying the Confirm switch without a value introduces a pause that forces you acknowledge the command before proceeding.
Type: | Fqdn |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
The EdbFilePath parameter specifies a new file path for the database. All current database files are moved to this location. The default location is %ExchangeInstallPath%Mailbox\LocalCopies\MBDatabase.edb . This file path can't be the same as the path for the backup copy of the database.
Type: | EdbFilePath |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
The Force switch hides warning or confirmation messages. You don't need to specify a value with this switch.
You can use this switch to run tasks programmatically where prompting for administrative input is inappropriate.
Type: | SwitchParameter |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
The Identity parameter specifies the database that you want to move. You can use any value that uniquely identifies the database. For example:
- Name
- Distinguished name (DN)
- GUID
The LogFolderPath parameter specifies the folder where log files are stored.
Type: | NonRootLocalLongFullPath |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
The WhatIf switch simulates the actions of the command. You can use this switch to view the changes that would occur without actually applying those changes. You don't need to specify a value with this switch.
Type: | SwitchParameter |
Aliases: | wi |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
Читайте также: