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

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

Пятнадцать лет в аутсорсинге — это десятки историй, где одна крошечная ошибка буквально ставила компании на колени. Ну вот скажите, что может быть хуже, чем шифровальщик, внезапный крах 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-решений, но зачем мне они? Мой выбор прост и прагматичен: rsync предсказуем до невозможности, летает как ракета и даёт мне стопроцентный контроль. Я всегда точно знаю, что именно и куда уходит. Это особенно бесценно, когда мы имеем дело с файловыми шарами 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, никаких 'кронов'! Почему? Потому что мне нужна максимально точная отчётность об ошибках прямо в 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. Даже если что-то случится с хостером и его скомпрометируют, ваши данные останутся под надёжной защитой.

Офсайт-копии мы делаем реже локальных бэкапов — и это не просто так. Смотрите сами: критичные данные копируются раз в сутки, обычно где-то в три часа ночи. Важные бэкапим раз в неделю. А вот так называемые 'холодные' данные — раз в месяц. Почему так? Всё дело в том, что в обычном офисе канал редко выдаёт больше 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 часов. Мы специально добавили двухчасовой запас — так спокойнее, вдруг окно копирования растянется.

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

Знаете, бэкап, который ни разу не проверяли на восстановление, — это, по сути, такая 'шрёдингеровская копия данных'. Вроде бы он есть, но в самый ответственный момент его может и не оказаться. Поэтому у нас действует железное правило: ежемесячно дежурный инженер обязан провести тестовое восстановление для случайно выбранного клиента. И, конечно, не забыть про подробный протокол.

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

Знакомая ситуация? Пользователь случайно стёр важный договор. Мы восстановим не только сам файл, но и его права, и даже исходное время изменения. Как будто ничего и не было.
Нужно проверить? Мы запросто восстановим всю структуру каталога, целиком, на ваш тестовый сервер.
Мы умеем разворачивать базы 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 года). А теперь просто прикиньте эти суммы и сравните с тем, во сколько обойдётся одна-единственная удачная атака шифровальщика. Когда клиенту приходится либо выкуп платить, либо вручную вбивать данные за полгода. Почувствуйте разницу!

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

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

Мы не просто запустили уровни. Все три уровня бэкапа работают идеально, отрабатывая строго по расписанию. Причём, минимум три ночи подряд — никаких сбоев, никаких ошибок. Мы это тщательно контролируем.
Критичные системы — это святое. Мы не только выполняем тестовое восстановление, но и тщательно фиксируем каждый шаг в протоколе. Максимальная прозрачность и уверенность.
Мы не верим на слово. 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-аутсорсинге для бизнеса.