Резервная копия, которая лежит на том же сервере, защищает от случайно удалённого файла, но не от сгоревшего диска, шифровальщика или ошибки администратора. Правило 3-2-1 простое: три копии данных, на двух разных носителях, одна из них за пределами сервера и офиса. Посмотрим, как выполнить его встроенными средствами Windows Server 2019/2022/2025, без покупки отдельного ПО.
Коротко: системный образ и файлы делаем через «Систему архивации данных Windows Server» (wbadmin), теневые копии включаем для быстрого отката отдельных файлов, базы 1С и SQL копируем отдельно их собственными средствами, а готовые копии регулярно уносим с сервера. И раз в какое-то время проверяем, что из копии действительно можно восстановиться.
Как правило 3-2-1 выглядит на одном сервере
| Что копируем | Чем | Куда | Зачем |
|---|---|---|---|
| Предыдущие версии файлов | Теневые копии (VSS) | Тот же том | Быстро вернуть файл, который испортили час назад |
| Образ системы и данные | Windows Server Backup | Отдельный диск или сетевая папка | Восстановить сервер целиком |
| Базы MS SQL, PostgreSQL, 1С | Средства СУБД, выгрузка .dt |
Отдельная папка, затем вне сервера | Согласованная копия базы на нужный момент |
| Копия всего перечисленного | Копирование по расписанию, сменные диски | Вне сервера и вне офиса | Пожар, кража, шифровальщик |
Теневые копии сами по себе резервной копией не считаются: они лежат на том же диске и погибнут вместе с ним. Это удобный дополнительный слой, а не одна из трёх копий.
Установка и первая копия через wbadmin
Компонент ставится через «Диспетчер серверов» → «Добавить роли и компоненты» → «Система архивации данных Windows Server» или одной командой PowerShell:
Install-WindowsFeature Windows-Server-BackupРазовая копия всех критических томов (нужна для восстановления «на голое железо») и диска с данными на отдельный диск E::
wbadmin start backup -backupTarget:E: -allCritical -include:D: -quietДиск назначения не может входить в число копируемых томов. По умолчанию wbadmin start backup делает копирующую резервную копию (-vssCopy), которая не трогает историю файлов приложений. Параметр -vssFull отмечает файлы как скопированные и может обрезать журналы приложений. Документация Microsoft прямо предупреждает: не используйте -vssFull, если приложения на этих томах копирует другая программа (справка по wbadmin start backup). Если SQL Server у вас копируется своими заданиями, оставьте режим по умолчанию, иначе можно сломать цепочку его разностных копий.
Расписание
Ежедневную копию удобнее настроить в оснастке wbadmin.msc («Расписание архивации»), но можно и командой:
wbadmin get disks
wbadmin enable backup -addtarget:{идентификатор диска} -schedule:23:00 -allCritical -include:D: -quietДве важные особенности:
- Если в
-addtargetуказан отдельный диск, он будет отформатирован, все данные на нём пропадут. Зато Windows сама управляет местом на нём и хранит несколько версий. - Если указана сетевая папка, в ней хранится только одна копия: следующая архивация перезаписывает предыдущую. Если новая копия не удалась, можно остаться вообще без копии. Microsoft советует раскладывать копии по подпапкам, но тогда места нужно вдвое больше.
Поэтому я предпочитаю выделенный диск для ежедневных копий и отдельно уношу копии с сервера.
Список имеющихся копий и их содержимое:
wbadmin get versions
wbadmin get items -version:10/15/2026-23:00Результаты архивации пишутся в журнал «Журналы приложений и служб» → Microsoft → Windows → Backup. Если никто не смотрит в этот журнал, о неудачных копиях вы узнаете в самый неподходящий момент. Настройте хотя бы письмо или уведомление по событию ошибки архивации.
Теневые копии общих папок
Включаются в свойствах тома: вкладка «Теневые копии» → выбрать том → «Включить». По умолчанию расписание — 7:00 и 12:00 по будним дням. Хранится не больше 64 теневых копий на том, при достижении лимита самые старые удаляются. Пользователи потом сами восстанавливают файлы через «Свойства» → «Предыдущие версии».
Проверить, какие копии есть и сколько места они занимают:
vssadmin list shadows
vssadmin list shadowstorageМесто под теневые копии лучше выделить на другом томе или хотя бы ограничить, чтобы они не съели диск с данными.
Базы 1С и SQL — отдельно
Образ системы содержит файлы баз, но восстанавливать базу 1С из образа сервера — долго и неудобно. Для баз нужны собственные копии.
MS SQL Server
В редакциях с SQL Server Agent настраивается план обслуживания. В Express агента нет, поэтому задание создаётся в «Планировщике заданий» Windows с вызовом sqlcmd:
sqlcmd -S .SQLEXPRESS -E -Q "BACKUP DATABASE [buh] TO DISK = N'D:SQLBackupbuh_full.bak' WITH CHECKSUM, INIT"В Standard и Enterprise можно добавить COMPRESSION, в Express сжатие резервных копий не поддерживается. Если база в полной модели восстановления, нужны ещё и копии журнала, иначе файл журнала будет расти. Подробнее про копирование баз 1С в SQL я писал в статье «Базы 1С в SQL, резервное копирование».
PostgreSQL
pg_dump -U postgres -Fc -f D:PGBackupbuh.dump buhФормат -Fc (custom) сжимается и восстанавливается через pg_restore, в том числе выборочно.
Файловые базы 1С
Файл 1Cv8.1CD, скопированный в момент работы пользователей, может оказаться несогласованным. Надёжнее делать выгрузку в .dt или копировать каталог базы, когда в ней никого нет, например ночью по расписанию.
Копия вне сервера
Это та самая «единица» в правиле 3-2-1, и именно её чаще всего нет. Варианты:
- Сменные USB-диски. Два диска, один подключён, второй лежит дома у ответственного сотрудника, раз в неделю их меняют. Отключённый диск шифровальщик не достанет.
- NAS или другой сервер. Копии забираются туда по расписанию, например
robocopy. Важно, чтобы учётная запись для записи на NAS не была администратором домена, а на самом NAS были снимки или версии. Иначе шифровальщик с правами администратора зашифрует и сетевую копию. - Удалённое хранилище в дата-центре. Лучшая защита от пожара и кражи: копии физически находятся в другом месте. Своё оборудование для этого держать не обязательно, можно арендовать хранилище резервных копий в дата-центре. Способ передачи копий заранее согласуйте с поставщиком.
robocopy D:SQLBackup \nasbackupsql *.bak /Z /R:3 /W:30 /LOG+:D:Logsrobocopy.logС ключом /MIR будьте осторожны: он удаляет на приёмнике всё, чего нет в источнике, включая старые копии.
Проверка восстановления
Копия, из которой ни разу не восстанавливались, остаётся предположением. Я проверяю по такому порядку:
- Раз в месяц восстанавливаю несколько файлов из Windows Server Backup в отдельную папку, а не поверх оригинала:
wbadmin start recovery -version:10/15/2026-23:00 -itemType:File -items:D:DocsОтчеты -recoveryTarget:D:RestoreTest -recursive - Проверяю файлы копий SQL:
RESTORE VERIFYONLY FROM DISK = N'D:SQLBackupbuh_full.bak' WITH CHECKSUM. Это проверка файла, а не полноценное восстановление. - Периодически восстанавливаю базу под другим именем (
RESTORE DATABASE ... WITH MOVEилиpg_restoreв новую базу), подключаю её к 1С и открываю пару отчётов. - Хотя бы раз восстанавливаю образ системы в виртуальную машину: загрузка с установочного носителя → «Восстановление системы» → «Поиск и устранение неисправностей» → «Восстановление образа системы». Так становится понятно, сколько времени займёт настоящее восстановление.
Результаты проверок стоит записывать: дату, что восстанавливали и сколько это заняло. Если не хочется выстраивать всё это самостоятельно, можно заказать резервное копирование под ключ.
Частые вопросы
Чем теневые копии отличаются от резервной копии?
Теневые копии хранятся на том же томе и зависят от него. Если диск вышел из строя или том зашифрован, они пропадут вместе с данными. Это удобный способ откатить файл, но не замена резервной копии.
Можно ли хранить копии Windows Server Backup в сетевой папке?
Можно, но в папке будет храниться только последняя копия, каждая новая перезаписывает предыдущую. Для нескольких версий лучше выделенный диск, а сетевую папку использовать как дополнительное место.
Нужно ли отдельно копировать базы, если делается образ всего сервера?
Да. Восстановить одну базу на нужный момент из копии СУБД гораздо быстрее, чем доставать файлы из образа. Кроме того, копия средствами СУБД согласована и проверяется командами самой СУБД.
Как часто проверять восстановление?
Выборочное восстановление файлов и баз — регулярно, например ежемесячно. Полное восстановление сервера в виртуальную машину — хотя бы после серьёзных изменений на сервере. Главное, чтобы проверка была в календаре, а не «когда будет время».