Бэкап конфигов WireGuard на Windows Server

MAATRIX

Переустановили Windows Server после сбоя — и туннель WireGuard не поднимается, потому что ключи потеряны, а конфиг существовал только в памяти GUI-приложения. Знакомая ситуация: сервер настраивали один раз, полгода назад, и с тех пор никто не вспоминал, где лежат ключи и остались ли они вообще где-то, кроме самого сервера. Ниже — рабочая схема: что именно нужно сохранять, как это делает WireGuard на Windows «под капотом», скрипт автоматического бэкапа по расписанию и пошаговое восстановление на чистой машине.

Что на самом деле нужно бэкапить

WireGuard на Windows хранит конфигурации туннелей в C:\Program Files\WireGuard\Data\Configurations\ в виде файлов <имя-туннеля>.conf.dpapi. Расширение не случайное: это не обычный текстовый .conf, а файл, зашифрованный через Windows DPAPI (Data Protection API) с привязкой к машине — расшифровать его может только служба WireGuard, запущенная на этом же сервере с теми же машинными ключами DPAPI.

Отсюда главная грабля: если вы скопируете .conf.dpapi на другой сервер или на тот же сервер после переустановки Windows «с нуля», файл не расшифруется — DPAPI-мастер-ключи генерируются заново при установке ОС. То есть бэкап одних только .dpapi-файлов защищает от случайного удаления конфига на живой системе, но не спасает при полной переустановке или миграции на новое железо.

Поэтому реальный бэкап должен включать три вещи:

• Плейнтекст-конфиги (.conf) — тот вид, в котором WireGuard принимает импорт и в котором ключи читаемы человеком. Это единственный формат, который переживает переустановку ОС.
• Приватные и публичные ключи — если конфиг собирался вручную из wg genkey / wg pubkey, ключи стоит хранить отдельным файлом даже вне контекста конкретного .conf.
• Список peer'ов и AllowedIPs — если сервер держит несколько клиентов, потеря этого списка означает ручной пересбор доступа для каждого сотрудника или устройства.

Если вы ещё не разворачивали WireGuard на Windows Server — сначала пройдите установку и настройку туннеля, а к бэкапу возвращайтесь уже после того, как туннель поднялся и стабильно держит соединение.

Экспорт конфигурации через GUI WireGuard

У официального клиента WireGuard для Windows есть встроенная функция экспорта, которая решает проблему DPAPI за вас — она сохраняет туннели в виде обычных .conf-файлов, упакованных в zip.

1. Откройте WireGuard.
2. Нажмите на иконку меню (три полоски) в правом верхнем углу окна.
3. Выберите Export Tunnels to zip...
4. Сохраните архив, например, в C:\WireGuard-Backup\manual-export\wg-export-2026-08-29.zip.

Внутри архива — читаемые .conf-файлы с секцией [Interface] (PrivateKey, Address, ListenPort) и [Peer] (PublicKey, AllowedIPs, Endpoint). Это и есть тот самый переносимый формат: такой архив можно развернуть на любом сервере через Import tunnel(s) from file, включая совершенно новую машину.

Ручной экспорт — рабочий вариант для разовой подстраховки перед плановыми работами (обновление ОС, миграция, смена провайдера). Но полагаться на «не забыть нажать кнопку» на проде не стоит — дальше настроим автоматизацию.

Скрипт автоматического бэкапа на PowerShell

GUI-экспорт нельзя вызвать из командной строки — у WireGuard для Windows нет CLI-флага для экспорта зашифрованных туннелей в plaintext. Поэтому практичная схема — держать «мастер-копию» plaintext-конфигов в отдельной защищённой папке (например, там, куда вы изначально сохранили .conf при первой настройке или куда единоразово выгрузили экспорт из GUI), и бэкапить именно её, вместе с диагностической копией .dpapi-хранилища на случай отката на этом же сервере.

Скрипт ниже собирает оба набора файлов, упаковывает их в зашифрованный 7-Zip архив (потребуется установленный 7-Zip — winget install 7zip.7zip) и копирует результат в облако через rclone и на второй сервер по SCP.

# C:\WireGuard-Backup\backup-wireguard.ps1

$ErrorActionPreference = "Stop"

$date        = Get-Date -Format "yyyy-MM-dd_HHmm"
$workDir     = "C:\WireGuard-Backup\staging\$date"
$archivePath = "C:\WireGuard-Backup\archives\wg-backup-$date.7z"
$logFile     = "C:\WireGuard-Backup\logs\backup.log"
$sevenZip    = "C:\Program Files\7-Zip\7z.exe"

New-Item -ItemType Directory -Path $workDir -Force | Out-Null
New-Item -ItemType Directory -Path "C:\WireGuard-Backup\archives" -Force | Out-Null
New-Item -ItemType Directory -Path "C:\WireGuard-Backup\logs" -Force | Out-Null

function Write-Log($msg) {
    "$(Get-Date -Format o)  $msg" | Out-File -Append -FilePath $logFile
}

try {
    # 1. Мастер-копия plaintext-конфигов (обновляйте её при каждом изменении туннеля)
    Copy-Item -Path "C:\WireGuard-Backup\configs\*" -Destination $workDir -Recurse -Force

    # 2. Диагностическая копия DPAPI-хранилища (для быстрого отката на этом же сервере)
    Copy-Item -Path "C:\Program Files\WireGuard\Data\Configurations\*.dpapi" `
              -Destination "$workDir\dpapi-store" -Force -ErrorAction SilentlyContinue

    # 3. Пароль для шифрования архива читаем из отдельного файла с ограниченным доступом
    $password = Get-Content "C:\WireGuard-Backup\secrets\archive.key" -Raw

    & $sevenZip a -t7z -mhe=on -p"$password" $archivePath "$workDir\*" | Out-Null

    Remove-Item -Path $workDir -Recurse -Force
    Write-Log "OK: архив создан — $archivePath"

    # 4. Выгрузка в облако (пример — Backblaze B2 / S3-совместимое хранилище через rclone)
    & rclone copy $archivePath "wg-backup-remote:wireguard-configs/" --log-file $logFile --log-level INFO

    # 5. Дублирующая копия на втором сервере по SCP (нужен установленный OpenSSH Client)
    & scp -i "C:\WireGuard-Backup\secrets\backup_id_ed25519" $archivePath `
          backupuser@second-server.example.com:/home/backupuser/wg-backups/

    Write-Log "OK: архив выгружен в облако и на второй сервер"

    # 6. Ротация — храним последние 14 локальных архивов
    Get-ChildItem "C:\WireGuard-Backup\archives" -Filter "wg-backup-*.7z" |
        Sort-Object LastWriteTime -Descending |
        Select-Object -Skip 14 |
        Remove-Item -Force

} catch {
    Write-Log "ERROR: $($_.Exception.Message)"
    exit 1
}

Нюансы: пароль от архива не хардкодьте в теле скрипта — держите его в отдельном файле с ACL на чтение только для SYSTEM (или забирайте из Windows Credential Manager). SSH-ключ для SCP должен быть без пароля (или пароль отдан через ssh-agent) — задача выполняется без интерактивного пользователя. Если отдельного облака нет — rclone умеет работать и с Google Drive, и с Яндекс.Диском, и с любым S3-совместимым провайдером, настраивается один раз командой rclone config.

Настройка Task Scheduler

Регистрируем задачу через schtasks, чтобы она запускалась под SYSTEM, с максимальными правами, независимо от того, залогинен ли администратор:

schtasks /create /tn "WireGuard-ConfigBackup" `
  /tr "powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\WireGuard-Backup\backup-wireguard.ps1" `
  /sc daily /st 03:30 /ru SYSTEM /rl HIGHEST /f

Проверить, что задача создана и когда она сработает в следующий раз:

schtasks /query /tn "WireGuard-ConfigBackup" /v /fo LIST

Запустить вручную, не дожидаясь 03:30, чтобы проверить, что всё действительно работает:

schtasks /run /tn "WireGuard-ConfigBackup"

Если хотите настроить задачу через графический Task Scheduler (taskschd.msc), логика та же: триггер — Daily, действие — запуск powershell.exe с аргументами из скрипта выше, «Run whether user is logged on or not», «Run with highest privileges». В свойствах задачи на вкладке Settings имеет смысл включить «Run task as soon as possible after a scheduled start is missed» — если сервер был выключен или перезагружался в момент бэкапа, задача досоздастся при следующем старте, а не будет пропущена на сутки.

Куда складывать бэкапы: облако или второй сервер

Правило «3-2-1» здесь работает буквально: минимум две независимые копии, кроме исходной, и хотя бы одна — вне этого физического сервера. Для конфигов WireGuard, которые весят считаные килобайты, это дёшево реализовать буквально любым способом:

Практичный минимум для одного сервера с WireGuard — облако плюс второй сервер в другом регионе. Если у вас уже есть VPS для бэкапов в принципе, логика организации хранилища такая же, как в статье про настройку VPS под бэкапы и архив с нуля — тот же сервер спокойно примет и SCP-копии конфигов WireGuard. И даже при паролe на архиве (-mhe=on шифрует и содержимое, и имена файлов) стоит убедиться, что сам бакет не настроен на публичный доступ по умолчанию.

Восстановление конфигурации с нуля

Сценарий: новый (или переустановленный) Windows Server, WireGuard ещё не установлен, из активов есть только последний архив бэкапа.

Шаг 1. Установите WireGuard. Официальный MSI с wireguard.com — процесс идентичен первой установке, отдельно описан в статье про установку WireGuard на Windows Server.

Шаг 2. Распакуйте архив бэкапа.

& "C:\Program Files\7-Zip\7z.exe" x "wg-backup-2026-08-29_0330.7z" `
  -o"C:\WireGuard-Restore" -p"ВАШ_ПАРОЛЬ"

Шаг 3. Импортируйте туннели через GUI. Нажмите Import tunnel(s) from file..., укажите папку с .conf-файлами (или исходный zip-экспорт) и подтвердите импорт. WireGuard сам создаст новые .dpapi-файлы под DPAPI-ключи нового сервера.

Шаг 4. Проверьте адреса и порт. Если сервер получил новый публичный IP, поправьте Endpoint в конфигах клиентов — это единственное поле, которое почти всегда нужно обновить руками после восстановления на новой машине.

Шаг 5. Откройте порт в брандмауэре. Свежая установка Windows Server не пропустит UDP-трафик на порт WireGuard, пока правило не создано заново — контрольный список см. в статье про настройку файрвола под туннель на Windows Server.

Шаг 6. Запустите туннель и проверьте соединение. Активируйте туннель в GUI (или wireguard.exe /installtunnelservice C:\WireGuard-Restore\wg0.conf) и с клиента проверьте ping до внутреннего адреса сервера в туннеле.

Если после восстановления туннель поднимается, но трафик не идёт — это чаще всего не проблема бэкапа, а типичные post-restore нюансы вроде правил маршрутизации или NAT; разбор частых причин есть в статье «WireGuard не работает после перезагрузки» — многие пункты оттуда применимы и к восстановлению после переустановки.

Частые вопросы