Очистка журнала событий Windows выглядит обманчиво безобидно. Правый клик по журналу, пункт "Очистить", и тысячи накопленных записей исчезают за долю секунды. Кнопка нажата - история стёрта. Проблема в том, что вместе с ненужным шумом из журнала уходят и записи, которые завтра могли бы объяснить сбой, подтвердить факт входа или восстановить картину инцидента. Журнал не хранит черновики и не отправляет удалённое в корзину. Очистка необратима, и единственная страховка от неё - архив, сделанный заранее.

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

Что именно теряется при очистке и почему это важно

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

Цена потери зависит от ситуации. Для журнала безопасности это записи о входах, о смене прав, о создании учётных записей - всё то, что нужно при расследовании. Для системного журнала это история ошибок драйверов и служб, по которой ищут причину нестабильности. Стоит представить, что через неделю всплывёт жалоба на странное поведение системы, а журнал за нужный период уже обнулён. Архив снимает этот риск целиком: события физически лежат в файле, и к ним можно вернуться в любой момент.

Есть и формальная сторона. Во многих организациях хранение журналов - требование политики безопасности или регламента, и просто стереть их нельзя. Архив в формате evtx с понятным именем и датой закрывает это требование, оставаясь при этом полноценным журналом, который открывается тем же просмотрщиком событий.

Графический способ сохранить журнал прямо из просмотрщика событий

Самый наглядный путь не требует командной строки вовсе. В оснастке eventvwr.msc нужно щёлкнуть правой кнопкой по интересующему журналу в дереве слева и выбрать пункт сохранения всех событий в файл. Откроется обычное окно сохранения, где задаётся имя и путь. Если выбрать тип файла evtx, появится дополнительное окно с предложением сохранить сведения о локали - языковые данные, которые позволят корректно прочитать описания событий на другой машине.

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

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

Команда wevtutil как основной инструмент экспорта и архивации

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

Экспорт выполняется командой export-log, у которой есть короткий псевдоним epl. Она забирает события из указанного журнала и кладёт их в отдельный файл evtx, не трогая сам журнал. Пример ниже выгружает системный журнал в архив с датой в имени.

wevtutil epl System C:\backup\system_0607.evtx

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

wevtutil epl System C:\backup\system.evtx /ow:true

Отдельно стоит режим archive-log с псевдонимом al. Он превращает уже сохранённый файл в самодостаточный архив: рядом создаётся подкаталог LocaleMetaData, куда складываются все сведения, относящиеся к языковому стандарту. Это нужно, чтобы файл корректно читался на машине с другим языком интерфейса, где иначе описания событий превратились бы в нечитаемые заглушки.

wevtutil al "C:\backup\Application.evtx" /locale:ru-ru

Очистка с одновременным резервным копированием в одну команду

Самый изящный приём объединяет сохранение и очистку. Команда очистки cl принимает ключ резервного копирования, и тогда журнал сначала сохраняется в указанный файл, а уже потом обнуляется. Получается атомарное действие: данные гарантированно уходят в архив прежде, чем журнал освобождается.

wevtutil cl Application /bu:C:\admin\backups\app_0607.evtx

Здесь сначала все события журнала приложений сохраняются в файл, и только затем журнал очищается. Такой подход исключает человеческую ошибку, при которой администратор очищает журнал, забыв сделать копию. Один вызов - и история и сохранена, и место освобождено.

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

Get-WinEvent -ListLog * -Force | ForEach-Object {
    wevtutil epl $_.LogName "C:\backup\$($_.LogName -replace '/','_').evtx" /ow:true
    wevtutil cl $_.LogName
}

Сначала цикл выгружает каждый журнал в отдельный файл, заменяя в имени недопустимый символ слеша подчёркиванием, а затем очищает журнал. Часть журналов может не очиститься из-за ошибки доступа - такие журналы придётся обработать вручную из консоли просмотрщика событий с правами администратора.

Массовое обслуживание журналов и правила хранения архивов

Размах задачи становится понятен, когда видишь полное число журналов. Начиная с Windows Vista система использует не пару журналов, а несколько десятков, и каждый компонент ведёт свой канал. На современной Windows 10 их насчитывается порядка тысячи с лишним - подсчитать точное количество можно командой перечисления журналов с последующим измерением длины списка.

(wevtutil el | Measure-Object).Count

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

Перед массовой операцией полезно посмотреть, что вообще лежит в конкретном журнале и сколько там записей. Режим get-loginfo показывает сведения о журнале, включая число событий и дату самой старой записи, что помогает решить, стоит ли вообще его архивировать.

wevtutil gli System

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

Архив ценен ровно настолько, насколько легко его потом найти. Свалка из файлов с именами вроде backup1 и backup_new через месяц превращается в загадку. Поэтому имя архива стоит строить по предсказуемому шаблону, в котором сразу читаются имя журнала и дата. Например, system_2026-06-07 говорит сам за себя, и в папке из сотни таких файлов нужный находится мгновенно.

Хранилище лучше выносить с системного диска. Если архивы лежат на том же томе, что и сама Windows, то при отказе диска вместе с системой пропадут и копии, ради которых всё затевалось. Отдельный диск, сетевая папка или внешнее хранилище защищают архив от той же беды, что грозит оригиналу. Это общий принцип резервного копирования, и журналы не исключение.

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

Проверка архива и автоматизация по расписанию

Самая коварная ошибка - считать архив надёжным, ни разу его не открыв. Файл может оказаться повреждённым, неполным или сохранённым без локали, и узнать об этом в момент, когда архив реально понадобился, особенно обидно. Поэтому свежесозданный архив стоит сразу проверить, прочитав из него хотя бы несколько событий.

Get-WinEvent -Path "C:\backup\system_0607.evtx" -MaxEvents 5

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

Ручная архивация хороша для разовых случаев, но регулярное обслуживание разумнее доверить расписанию. Планировщик задач Windows умеет запускать скрипт по таймеру - например, каждую ночь или раз в неделю, - и тогда архивация перестаёт зависеть от того, вспомнил о ней человек или нет. Скрипт сам выгружает нужные журналы, складывает их в хранилище с датой в имени и при необходимости очищает исходные журналы.

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

$date = Get-Date -Format 'yyyy-MM-dd'
$dest = "D:\EventBackup\Security_$date.evtx"
wevtutil epl Security $dest /ow:true
Get-WinEvent -Path $dest -MaxEvents 1

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

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

Главное правило обращения с журналами перед очисткой

Если свести всё к одному принципу, он прозвучит так: очистка журнала - это последний шаг, а не первый. Сначала архив, потом проверка архива, и только затем освобождение журнала. Нарушение этого порядка однажды обернётся потерей именно тех данных, которые оказались бы нужнее всего.

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

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