BackupZit

Резервное копирование 3-2-1 с неизменяемыми копиями: защита от шифровальщиков шаг за шагом

Как превратить правило 3-2-1 в работающую схему: быстрая резервная копия на месте, копия за пределами офиса и хотя бы одна копия, которую нельзя удалить или перезаписать, — с S3 Object Lock или защищённым репозиторием на Linux, — а также шифрование, хранение, тесты восстановления и оповещения, когда копирование не удалось.

Что вы настроите

Злоумышленники, проникшие в сеть, обычно сначала пытаются удалить или зашифровать резервные копии и только потом серверы. Поэтому копии, которую может удалить украденная учётная запись администратора, недостаточно. Это руководство строит с BackupZit многоуровневую защиту: основная копия на локальном хранилище, копия в другом месте и хранилище, где копии нельзя уничтожить до окончания заданного срока, даже имея учётные данные хранилища. BackupZit бесплатен и с открытым исходным кодом (AGPLv3); всё описанное здесь входит в бесплатный продукт.

Правило 3-2-1 и 3-2-1-1-0

Правило 3-2-1: 3 копии данных, на 2 разных носителях, 1 из них — за пределами офиса. Расширение 3-2-1-1-0 добавляет 1 неизменяемую или офлайн-копию и 0 ошибок при проверке копий. В BackupZit:

ЧастьВ BackupZit
3 копииРабочие данные, задание резервного копирования и задание копирования копий.
2 носителяДва хранилища, например NAS по SMB или SFTP и бакет S3.
1 вне офисаКопия уходит в облако (S3, Azure Blob Storage) или на защищённый репозиторий в другом здании.
1 неизменяемая или офлайнS3 с Object Lock, защищённый репозиторий или сменные USB-диски.
0 ошибокАвтоматические тесты восстановления и проверка всех сохранённых данных с оповещением при сбое.

Нужна консоль BackupZit с агентами на защищаемых машинах; руководства по Proxmox VE, Hyper-V и образам дисков Windows показывают эти первые шаги.

Шаг 1 — Основное хранилище для быстрого восстановления

В консоли откройте Хранилище → Добавить хранилище. Для первой копии выберите хранилище в локальной сети, чтобы копирование и восстановление шли на полной скорости: общую папку SMB на файловом сервере или NAS либо сервер Linux или NAS по SFTP (ключ хоста закрепляется). Дайте хранилищу отдельную учётную запись, которая может писать только в папку копий, и не включайте хранилище копий в домен Windows.

При сохранении консоль сразу проверяет хранилище — неверный пароль, ключ хоста или общая папка видны сейчас, а не при первом копировании. Проверить подключение в списке хранилищ повторяет проверку.

Шаг 2 — Добавьте неизменяемое хранилище

В BackupZit есть два вида хранилища, где копии нельзя удалить или перезаписать до окончания их срока. В идеале оно ещё и вне офиса — тогда одно хранилище закрывает оба требования.

Вариант A: S3 с Object Lock

  1. Создайте бакет с включённым Object Lock — в AWS, Wasabi и Backblaze B2 это параметр при создании бакета, в MinIO mc mb --with-lock.
  2. Добавьте правило жизненного цикла, которое удаляет неактуальные версии через один день (MinIO: mc ilm rule add --noncurrent-expire-days 1 --expire-delete-marker). Удаление заблокированной копии лишь добавляет маркер удаления; правило освобождает место, когда блокировки истекают.
  3. В консоли добавьте хранилище типа Совместимое с S3 (AWS, Wasabi, Backblaze B2, MinIO, …) с конечной точкой, бакетом и ключом доступа к этому бакету.
  4. Отметьте Неизменяемые копии (S3 Object Lock, режим compliance) на … дн. (по умолчанию 30) и выберите срок не короче хранения, которое нужно защитить.

Каждый файл, записанный агентами, блокируется в режиме compliance на этот срок плюс один день: никто — ни злоумышленник с ключами, ни владелец бакета — не может удалить или перезаписать его раньше. Данным, которые новая копия берёт из старых, блокировка продлевается, поэтому каждая точка восстановления защищена весь срок. На неизменяемом хранилище проверка подключения только входит и получает список, а также проверяет, что у бакета действительно есть Object Lock.

Azure и Google Cloud: для Azure Blob Storage включите в Azure неизменяемость на уровне версий с политикой хранения по времени для контейнера. Google Cloud Storage работает как хранилище S3, но без параметра Object Lock; вместо этого задайте в Google Cloud политику хранения бакета (и заблокируйте её).

Вариант B: защищённый репозиторий на своём сервере Linux

На отдельном сервере Linux работает backupzit-repo (пакеты deb и rpm приложены к каждому выпуску на GitHub):

apt install ./backupzit-repo_*.deb       # или: dnf install ./backupzit-repo-*.rpm
vi /etc/backupzit-repo/repo.env          # BACKUPZIT_REPO_LOCK_DAYS=30
systemctl start backupzit-repo
backupzit-repo add-key office-console    # показывает ключ доступа один раз
backupzit-repo fingerprint               # отпечаток сертификата

В консоли добавьте хранилище типа Защищённый репозиторий (backupzit-repo на Linux, неизменяемый) с адресом сервера (по умолчанию порт 8500), ключом доступа и отпечатком.

  • Агенты и консоль могут только добавлять файлы; существующие файлы никогда не перезаписываются.
  • Каждый файл получает атрибут неизменяемости (chattr +i) на срок, заданный на этом сервере, плюс один день. Даже root не может удалить его, не сняв сначала атрибут.
  • Удаления со стороны клиентов — по правилам хранения или злоумышленником с ключом доступа — лишь скрывают файлы до окончания их срока.
  • Срок задаётся только на сервере репозитория; консоль и агенты не могут его изменить.

После настройки отключите SSH и другой удалённый доступ к этому серверу и защитите его локальную консоль, iDRAC/iLO или доступ через гипервизор: защита сильна ровно настолько, насколько защищена его учётная запись root.

Шаг 3 — Шифрование и ключ восстановления

Оставьте включённым Шифровать копии (AES-256) (по умолчанию). Содержимое файлов, имена, структура папок и списки снимков шифруются AES-256-GCM до того, как покинут агент, и любое изменение данных обнаруживается. Неизменяемость мешает удалению, шифрование — чтению; нужно и то и другое.

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

Шаг 4 — Задание копирования и хранение

Создайте задание в разделе Задания копирования с основным хранилищем из шага 1. В Хранить копии задайте N самых новых плюс ежедневные, еженедельные и ежемесячные точки восстановления — например, 3 последних, 7 ежедневных, 4 еженедельных и 6 ежемесячных хранят около полугода примерно с 20 точками восстановления. Дедупликация сохраняет неизменённые данные только один раз.

Целевая точка восстановления (RPO), часы задаёт, насколько старой может быть последняя успешная копия, например 26 для ежедневного задания. Задание, не уложившееся в неё, отображается на панели и вызывает уведомление; так обнаруживается и агент, который несколько дней не в сети, и случайно удалённое расписание.

Шаг 5 — Внешняя копия с помощью задания копирования копий

Создайте второе задание и выберите Копия резервной копии. В Копировать резервные копии задания выберите задание из шага 4, а в качестве Хранилище — неизменяемое или внешнее хранилище из шага 2.

  • Агент исходного задания копирует существующие копии; защищаемая машина повторно не читается.
  • Передаются только данные, которых ещё нет в месте назначения, заново зашифрованные его ключом.
  • После каждой копии исходного задания (по умолчанию) поддерживает копию актуальной; подходит и обычное расписание, например раз в ночь при медленном канале.
  • У копии своё хранение, например 7 ежедневных на NAS и 12 ежемесячных в облаке. Каждая точка восстановления заблокирована N дней с момента создания, поэтому при блокировке на 30 дней более старые ежемесячные точки уже не защищены. Более длинная блокировка защищает больше из них, но и занимает больше места.

Копии файлов и ВМ (Proxmox VE, Hyper-V, VMware) восстанавливаются из внешней копии так же, как из оригинала; копии образов дисков — агентом командной строки. Копировать сейчас сразу запускает копирование.

Офлайн-копия для небольших офисов: тип хранилища Сменные USB- / съёмные диски (офлайн-копии) находит диски по метке тома (BZBACKUP1, BZBACKUP2 …). Направьте на него задание копирования, меняйте диски, например, раз в неделю и храните отключённый в надёжном месте. Если ни один диск не подключён, запуск завершается ошибкой и оповещением.

Шаг 6 — Тесты восстановления и проверка данных

Копия доказана, только когда её восстановили. В разделе Настройки → Тесты восстановления:

  • Автоматически проверять самую новую копию каждого задания (по умолчанию раз в неделю): случайная выборка файлов из самой новой копии восстанавливается во временную папку, проверяется побайтно по сохранённым контрольным суммам и удаляется; для образов дисков проверяются случайные блоки. Так проверяются доступ к хранилищу, учётные данные, ключ и сами данные.
  • Проверять сохранённые данные (по умолчанию ежемесячно): каждый фрагмент данных в каждом репозитории читается и проверяется, что заранее выявляет отказывающий диск в NAS или тихую порчу данных. На S3 и Azure проверка выполняется только с включённым Также в облачных хранилищах (S3, Azure) — она скачивает всё, учитывайте плату за скачивание.
  • Задания ВМ Proxmox могут добавить тест загрузки, который запускает каждую ВМ из копии с отключённой сетью.

Проверить восстановление и Проверить данные на странице задания запускают их сразу. Результаты видны в Активность и Отчёты; неудачный тест присылает оповещение, как любая ошибка.

Шаг 7 — Оповещения и обнаружение шифровальщиков

Внешняя копия, которая неделями не создаётся, — не копия. Настройте Настройки → Уведомления по почте (проверьте кнопкой Отправить тестовое письмо) и оставьте включённым Ошибки: одно письмо на каждый неудачный запуск с причиной — копирование, внешние копии, восстановление и тесты восстановления — и при желании ежедневный отчёт. Настройки → Чаты и вебхуки отправляет то же в Slack, Microsoft Teams или на любой HTTP-адрес. На панели Требует внимания перечисляет неудачные задания, пропущенные расписания и RPO, агенты не в сети и хранилища, заполненные на 90 % или которые заполнятся в течение 30 дней.

Кроме того, каждая копия сравнивается с недавней историей своего задания. Она помечается как подозрительная, если изменилось намного больше файлов, чем обычно, новые данные перестали сжиматься (зашифрованные файлы выглядят случайными), число файлов упало на треть или больше либо резко вырос объём новых данных. Тогда BackupZit отправляет оповещение, показывает её в подозрительных копий для проверки и приостанавливает хранение задания (Хранение приостановлено), так что последние чистые копии не удаляются, даже если повреждённые продолжают поступать. Проверив машину, нажмите Проверено — возобновить хранение.

Шаг 8 — Защита консоли

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

После атаки

Если копии были удалены или перезаписаны, прочитайте хранилище в состоянии до атаки — только чтение, на S3 с Object Lock и на защищённом репозитории:

backupzit-agent snapshots --repo <репозиторий> --as-of 2026-10-01T14:30
backupzit-agent restore   --repo <репозиторий> --as-of 2026-10-01T14:30 --target D:\Restore latest

На защищённом репозитории администратор может также вернуть скрытые файлы, чтобы копирование продолжилось в обычном режиме:

backupzit-repo status
backupzit-repo undelete --since 2026-10-01T14:00

Ограничения

  • Неизменяемость действует только в течение срока блокировки. Удалённая копия действительно исчезает по его окончании, поэтому выбирайте срок с учётом того, как долго атака может оставаться незамеченной.
  • Защищённый репозиторий безопасен настолько, насколько защищены его учётная запись root и доступ к его консоли, iDRAC/iLO или гипервизору.
  • У SMB, SFTP и локальных дисков нет собственной неизменяемости; сочетайте их с неизменяемой или офлайн-копией.
  • Заблокированные данные занимают место до конца блокировки, даже после удаления; без правила жизненного цикла место в S3 не освобождается.
  • Неизменяемость не очищает данные: файлы, зашифрованные до копирования, попадают в копию зашифрованными. Восстанавливайте точку до атаки — обнаружение сохраняет такие точки, приостанавливая хранение.
  • Без ключа восстановления зашифрованные копии не прочитает никто.
  • Принцип четырёх глаз действует в консоли; группы администраторов в Active Directory или Entra ID нужно защищать там.

Что дальше

Скачайте BackupZit, посмотрите защиту от шифровальщиков и все хранилища или прочитайте главы о хранилищах и защите от шифровальщиков во встроенном в консоль руководстве. Как разрабатывается и выпускается сам BackupZit, описано на странице безопасности. Настройка заданий описана в руководствах по Proxmox VE, Hyper-V, Microsoft 365 и восстановлению Windows на «голое железо». Вопросы можно задать в GitHub Discussions. Компании могут получить коммерческую поддержку от MaxZit (только на английском).