Инфраструктура 17 апреля 2026 · 14 мин чтения

Резервное копирование 3-2-1 для малого офиса: настройка с нуля

За 15 лет в аутсорсинге я видел десятки случаев, когда компания «потеряла всё» из-за одной невнимательной минуты. Шифровальщик, упавший RAID, ошибка администратора при чистке — сценариев много, а итог один: остановка бизнеса. Расскажу, как мы в АйТи Фреш разворачиваем стратегию 3-2-1 в офисах от 10 до 50 рабочих мест за два дня и без покупки коммерческих лицензий.

Почему именно 3-2-1, а не «бэкап на соседний диск»

Правило 3-2-1 родилось в начале 2000-х в среде фотографов, которые хотели гарантированно сохранить негативы. Формула простая: три копии данных, на двух разных типах носителей, одна — за пределами офиса. За полтора десятилетия я не встретил схемы, которая давала бы лучшее соотношение цены и надёжности для бизнеса до 50 рабочих мест.

Разберём логику. Одна копия — это исходные данные на сервере. Вторая — локальный бэкап на NAS или внешнем диске, который защищает от удаления, поломки железа и логических ошибок. Третья — офсайт-копия, нужная на случай пожара, кражи, шифровальщика или затопления серверной (видел и такое — труба отопления над стойкой).

Два разных носителя нужны, потому что технологии умирают синхронно. Если у вас весь массив собран на одной партии WD Red 4 ТБ, то с вероятностью 30% они посыпятся в течение полугода друг за другом. Лично сталкивался с двумя такими случаями в 2024 году. Поэтому второй уровень должен жить либо на других дисках, либо вообще на другой среде — в облаке, на ленте, на отдельном NAS.

Аудит данных перед настройкой

Главная ошибка большинства IT-отделов — бэкапить всё подряд. Это убивает дисковое пространство, удлиняет окно копирования и затрудняет восстановление. Перед настройкой я всегда провожу инвентаризацию и делю данные на три категории.

Критичные: базы 1С, файловые шары бухгалтерии и юристов, базы CRM, конфигурации сетевого оборудования, состояние Active Directory. Потеря — остановка бизнеса. RPO до 1 часа, RTO до 2 часов.

Важные: рабочие документы маркетинга, проектная документация, архивы переписки. Потеря — болезненная, но не фатальная. RPO 24 часа, RTO 1 рабочий день.

Холодные: архивы старых проектов, дистрибутивы, видеозаписи совещаний. Хранятся для соответствия регуляторам или истории. RPO 7 дней, RTO 3 дня.

На основе этой классификации строится расписание и распределение копий. Критичные данные — все три уровня плюс ежечасный snapshot. Холодные — одна копия в облаке с дешёвым тарифом холодного хранения.

Уровень 1: rsync для файловых данных

Для первого локального уровня я по-прежнему использую старый добрый rsync, несмотря на наличие красивых GUI-решений. Причина простая: предсказуемость, скорость, возможность точно понять, что и куда копируется. Особенно ценно для файловых шар Samba или общих папок Windows-сервера.

Базовый шаблон команды, который у меня в каждой инсталляции:

rsync -aHAXxv --numeric-ids --delete \
      --exclude='*.tmp' \
      --exclude='Thumbs.db' \
      --exclude='~$*' \
      --link-dest=/mnt/backup/share/daily.1 \
      /srv/samba/share/ \
      /mnt/backup/share/daily.0/ \
      2>&1 | tee -a /var/log/backup/rsync-$(date +%F).log

Ключ --link-dest делает магию: файлы, которые не изменились с прошлого бэкапа, не копируются заново, а создаются жёсткими ссылками на предыдущую версию. На клиентских данных это даёт выигрыш в 10-20 раз по месту. Папка daily.0 выглядит как полная копия, но физически занимает только дельту.

Ротацию я делаю отдельным скриптом, который двигает каталоги: daily.6 удаляется, daily.5 переименовывается в daily.6, и так далее. Получается 7 ежедневных снимков, которые занимают примерно столько же места, сколько одна полная копия плюс изменения.

Запускается через systemd timer, не через cron — мне важна точная отчётность об ошибках в journalctl. Пример unit-файла:

[Unit]
Description=Daily rsync backup of file shares
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup-shares.sh
StandardOutput=journal
StandardError=journal
Nice=15
IOSchedulingClass=best-effort
IOSchedulingPriority=7

[Install]
WantedBy=multi-user.target

Важный момент — я всегда задаю Nice=15 и IOSchedulingPriority=7. Иначе rsync с ключом -H на больших шарах с миллионами хардлинков может на полчаса парализовать дисковую подсистему сервера.

Уровень 2: Borg или Restic для дедуплицированных снимков

Rsync — отличный инструмент, но у него нет встроенного шифрования и сжатия. Для второй копии — той, что хранится на NAS отдельно от продакшена, — я беру Borg или Restic. Выбор зависит от инфраструктуры.

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

Инициализация репозитория и первый бэкап:

# Инициализация с шифрованием repokey-blake2
borg init --encryption=repokey-blake2 \
  borg@nas01.local:/mnt/storage/borg/srv-1c

# Первый полный бэкап базы 1С
borg create --stats --progress \
  --compression zstd,9 \
  --exclude '*.log' \
  --exclude '*.tmp' \
  borg@nas01.local:/mnt/storage/borg/srv-1c::srv-1c-{now:%Y-%m-%d_%H-%M} \
  /var/1c/srvinfo \
  /etc \
  /home/1cv8

Прунинг настраиваю по схеме GFS — Grandfather-Father-Son. Это золотой стандарт для офисов: всегда есть свежая история, при этом старые данные не пухнут.

borg prune --list --stats \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --keep-yearly 2 \
  borg@nas01.local:/mnt/storage/borg/srv-1c

В переводе: храним последние 7 ежедневных, 4 еженедельных, 6 ежемесячных и 2 ежегодных снимка. Этого достаточно, чтобы откатиться к состоянию полугодовой давности при инциденте, который заметили не сразу.

Restic я выбираю, когда вторая копия должна жить в S3-совместимом хранилище (Selectel, Yandex Cloud, MinIO в офисе). Restic нативно умеет в десяток бэкендов и не требует SSH-доступа.

export RESTIC_REPOSITORY="s3:https://s3.selectel.ru/itfresh-backups-acme"
export RESTIC_PASSWORD_FILE="/root/.restic-password"
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

# Инициализация
restic init

# Бэкап с тегом для отчётности
restic backup \
  --tag srv-fileshare \
  --tag daily \
  --exclude-file=/etc/restic/exclude.list \
  /srv/samba/share

# Прунинг и проверка
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

Опция --read-data-subset=10% важна. Каждый запуск проверяется случайные 10% данных репозитория. За 10 дней проверится весь архив, при этом без серьёзной нагрузки на сеть и диск. Это страховка от того, что бэкап на самом деле «битый», но об этом узнают только при попытке восстановления.

Уровень 3: офсайт в облако

Третий уровень — самый недооценённый. Многие IT-отделы ставят NAS в соседнем кабинете и считают, что это уже офсайт. Это не так. Если в здании пожар или прорыв трубы — оба сервера сгорят или зальются. Реальный офсайт находится в другом здании, лучше — в другом городе.

Для российских клиентов мы используем три варианта в порядке предпочтения:

Selectel Object Storage — холодный класс хранения, ~1 ₽/ГБ/месяц, S3-совместимый API, российская юрисдикция.
Yandex Object Storage — аналогичные тарифы, удобная интеграция с другими сервисами Yandex Cloud, если клиент уже там.
Собственный сервер у дружественного хостера — VPS в Москве, Питере или регионе со своим MinIO. Дороже, но даёт полный контроль.

Третий уровень всегда строится через Restic. Никаких прямых rsync на облачные диски — это и медленно, и небезопасно. Шифрование на стороне клиента обязательно: ключ хранится в офисе и в зашифрованном виде у меня в KeePassXC. Если хостер скомпрометирован — данные останутся защищены.

Расписание для офсайт-копии я делаю реже, чем локальное. Раз в сутки в 03:00 для критичных данных, раз в неделю для важных, раз в месяц для холодных. Канал в офисе обычно 100-300 Мбит, и забить его дневным трафиком бэкапа — плохая идея.

Защита от шифровальщиков: immutability

За последние два года шифровальщики изменили правила игры. Они научились находить и удалять бэкапы. Если ваш бэкап-сервер доступен по SMB/CIFS из доменной сети с правами на запись — считайте, что бэкапа у вас нет. Зашифруют и его.

В моих инсталляциях три уровня защиты:

Уровень репозитория Borg. Сервер NAS принимает подключения только по SSH с ограниченной командой borg serve --append-only. Это значит, что клиент может только добавлять новые архивы, но не удалять старые. Команда удаления выполняется отдельно — с другого сервера и под отдельным ключом.

# В ~/.ssh/authorized_keys на NAS
command="borg serve --restrict-to-path /mnt/storage/borg --append-only",no-port-forwarding,no-X11-forwarding,no-pty,no-agent-forwarding ssh-ed25519 AAAA...

Уровень S3. На облачном бакете включаем Object Lock в режиме governance или compliance. Объекты невозможно удалить или перезаписать в течение заданного срока, даже с правами root. Это критическая защита — после внедрения Object Lock у двух наших клиентов шифровальщик не смог уничтожить облачные копии.

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

Расписание и мониторинг

Я не верю в сложные планировщики типа Bacula или Bareos для офисов до 50 РМ. Слишком много лишнего, слишком сложная отладка. Хватает systemd timers и интеграции с Zabbix.

Базовая раскладка во времени, которой я придерживаюсь:

00:00 — выгрузка баз 1С через v8run в *.dt с компрессией.
00:30 — rsync файловых шар на NAS (snapshot daily.0).
02:00 — Borg-бэкап выгруженных *.dt и системных каталогов.
03:00 — Restic в S3 для критичных данных за день.
04:30 — прунинг и проверка целостности (раз в неделю).
09:00 — отправка отчёта на корпоративную почту с результатами всех заданий.

Мониторинг — обязательно через Zabbix. У каждого сервера свой шаблон с тремя ключевыми триггерами: время с момента последнего успешного бэкапа, размер последнего архива (защита от пустых бэкапов), результат последнего restic check или borg check.

Простейший элемент данных в zabbix_agent2 для контроля свежести:

UserParameter=backup.last.borg[*],stat -c %Y /var/log/backup/borg-$1.success 2>/dev/null || echo 0
UserParameter=backup.size.borg[*],borg info --json borg@nas01:/mnt/storage/borg/$1 | jq '.cache.stats.unique_csize'

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

Восстановление: то, ради чего всё затевалось

Бэкап, который ни разу не восстанавливали, — это шрёдингеровская копия данных. Существует и не существует одновременно. Я ввёл правило: каждый месяц инженер дежурной смены проводит test restore по случайно выбранному клиенту и заводит протокол.

Что именно тестируется:

Восстановление одного файла с правами и временем изменения (типичный кейс «пользователь случайно удалил договор»).
Восстановление структуры каталога целиком на тестовый сервер.
Развёртывание базы 1С из *.dt в чистый кластер и проверка работоспособности.
Полное восстановление системы из Borg-репозитория на запасной хост (раз в квартал).

Команды для типичных сценариев. Восстановить один файл из конкретного снапшота Restic:

restic snapshots --tag srv-fileshare
restic restore latest --target /tmp/restore --include "/srv/samba/share/buh/dogovor-2026.docx"

Развернуть Borg-архив целиком на новый сервер:

cd /
borg extract --progress --list \
  borg@nas01.local:/mnt/storage/borg/srv-1c::srv-1c-2026-04-15_02-15

Если канал медленный, а нужно срочно вытащить большой архив из облака — Selectel и Yandex поддерживают физический вывоз данных на дисках. Звонок в техподдержку, через сутки курьер привозит зашифрованный диск с вашим бэкапом. Использовали один раз в 2025 году — спасло клиенту месяц работы.

Типовая стоимость и сроки внедрения

Чтобы у читателя был ориентир. Возьмём типичный офис: 30 РМ, два сервера (контроллер домена и файловый сервер с базой 1С), общий объём данных 2 ТБ, прирост 5 ГБ в день.

Компонент	Решение	Стоимость
NAS для локального уровня	Synology DS923+ или QNAP TS-464	55-75 тыс. ₽
Диски	4 × WD Red Plus 8 ТБ в RAID 5	40-50 тыс. ₽
Облачный объект-сторейдж	Selectel, ~600 ₽/мес за 600 ГБ	7 тыс. ₽/год
Настройка под ключ	АйТи Фреш, разовая работа	45 тыс. ₽
Сопровождение	В рамках абонентского договора	включено

Итого первый год — около 150-180 тысяч рублей. Второй и далее — 7-10 тысяч в год за облако плюс замена дисков по мере выработки ресурса (обычно через 3-4 года). Сравните с ценой одной успешной атаки шифровальщика, после которой клиент платит выкуп или заново вводит данные за полгода.

Чек-лист перед запуском в продакшен

Прежде чем считать инсталляцию готовой, я прохожу по списку:

Все три уровня запущены и отрабатывают по расписанию минимум 3 ночи подряд без ошибок.
Test restore критичной системы выполнен и зафиксирован в протоколе.
Zabbix-триггеры настроены и однажды протестированы (умышленно сломал бэкап — пришёл алерт).
Пароли от репозиториев Borg/Restic сохранены в KeePassXC у клиента и в нашей базе.
Доступ к S3-бакету ограничен по IP, MFA включён.
Учётка бэкапа выведена из доменных админских групп.
Object Lock включён на облачном бакете для критичных данных.
Документ «Процедура восстановления» передан клиенту в двух экземплярах: электронный и распечатанный в серверной.

Восьмой пункт многим кажется паранойей, пока не случается ситуация, когда основной админ в отпуске, в офисе нет интернета, а серверу нужно срочно вернуть базу 1С. Распечатанная инструкция в файлике на стене серверной — это спокойный сон.

FAQ

Сколько стоит развернуть схему 3-2-1 для офиса на 30 рабочих мест?
В среднем 60-90 тысяч рублей за оборудование (NAS + диски) и 35-50 тысяч за работу при разовой настройке. Лицензии не нужны — все инструменты open source.

Можно ли обойтись только облачным бэкапом без локального?
Технически можно, но при потере данных восстановление 500 ГБ из облака на канале 100 Мбит займёт 12-15 часов. Локальная копия даёт RTO в районе 30 минут.

Как часто нужно проверять восстановление из бэкапа?
Минимум раз в месяц для критичных систем (1С, файловый сервер, почта) и раз в квартал для всего остального. Без тестов бэкап — это надежда, а не страховка.

Borg или Restic — что выбрать?
Borg чуть быстрее на больших объёмах и экономнее по дедупликации, Restic проще в настройке и нативно работает с S3-совместимыми хранилищами. Для офиса до 50 РМ часто берём Restic из-за облачной интеграции.

Куда складывать офсайт-копию, чтобы соответствовать 3-2-1?
Используем Selectel S3, Yandex Object Storage или арендуем VPS у российских хостеров с шифрованием на стороне клиента. Главное — географически удалённая площадка и отдельный аккаунт с MFA.

Готовы построить надёжную защиту данных?

Если ваш офис в Москве и вы хотите получить рабочую схему 3-2-1 без головной боли — оставьте заявку на itfresh.ru или напишите на 7296241@gmail.com. Проведём аудит текущей ситуации, посчитаем смету и за два рабочих дня внедрим систему. Первая консультация бесплатна.

Семёнов Е.С., технический директор АйТи Фреш. 15+ лет в IT-аутсорсинге для бизнеса.