Автоматизация бэкапов 1С и файлового сервера в офисе Москвы 2026

Привет! Я, Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15 лет своей работы с малым и средним бизнесом в офисах Москвы мне довелось увидеть десятки настоящих катастроф, которые случались из-за отсутствия нормальных бэкапов. Это и шифровальщики, и внезапные отказы дисков, и, конечно, «случайно» удалённые базы 1С. Сегодня я хочу рассказать вам, как мы в нашей компании выстраиваем типовую систему автоматических бэкапов специально для офисов, где до 50 рабочих мест, есть 1С и файловый сервер. Я подробно объясню, что именно туда входит, сколько это стоит и почему фраза «бэкап на тот же сервер» — это, по сути, вообще не бэкап.

Почему «бэкап есть» — это часто иллюзия

Когда я приезжаю на аудит к новому клиенту, в первые же 10 минут прошу: «Покажите, как у вас сделан бэкап 1С». И в 70 % случаев слышу один из четырёх ответов:

• «У нас RAID, всё дублируется». RAID — это защита от выхода диска, а не от шифровальщика, удаления или пожара. Когда вирус доберётся до базы, RAID добросовестно продублирует уже зашифрованную копию.
• «Бэкапы делает 1С сама, в папку D:\Backup». На том же сервере, на том же диске. Утром после атаки шифровальщика и база, и «бэкап» одинаково мёртвые.
• «Раз в неделю копируем на флешку». Допустимая потеря данных 7 дней — это для большинства бизнесов катастрофа. И флешка обычно лежит в том же ящике, что и сервер.
• «У нас всё в облаке Yandex 360 / Bitrix24». Прекрасно, но Yandex 360 не бэкапит ваши почтовые ящики и файлы за пределы корзины. Если ушёл сотрудник и вы за 30 дней не заметили — данные потеряны.

Самое интересное, что почти все эти клиенты искренне убеждены: их «бэкап есть и работает». Но вот парадокс: никто из них ни разу не пробовал восстановиться. А сколько времени займёт восстановление 1С, если вдруг случится катастрофа? Этого тоже никто не знает. Именно поэтому я называю это «котом Шрёдингера»: вы просто не сможете понять, рабочий ваш бэкап или нет, пока не попробуете его в действии.

Правило 3-2-1 на практике для офиса 30 РМ

Стандарт индустрии для нормальных бэкапов — правило 3-2-1. Звучит просто, но весь дьявол в реализации:

• 3 копии данных: оригинал на боевом сервере + копия на NAS в офисе + копия в облаке
• 2 разных типа носителей: SSD/HDD в офисе (горячий бэкап) + объектное хранилище в облаке (холодный)
• 1 копия офлайн / в другой локации: внешний HDD, который физически отключается между бэкапами, или копия в облаке другого провайдера

Я в АйТи Фреш для офисов до 50 РМ обычно делаю это так:

Бэкап базы 1С: правильные инструменты

Для резервного копирования 1С я выбираю разные подходы. Всё зависит от того, как именно развёрнута платформа у клиента. Но чаще всего в офисах Москвы встречаются такие варианты:

• 1С на файловом варианте (база лежит как набор .cdn/.1CD файлов в общей папке). Бэкапим файлы напрямую через Veeam Agent for Windows — каждый час инкремент, ночью полный.
• 1С с базой в MS SQL Server. Бэкапим SQL native через BACKUP DATABASE с WITH DIFFERENTIAL и WITH COPY_ONLY. Транзакционный лог — каждые 15 минут (это даёт возможность восстановиться на любой момент времени).
• 1С с базой в PostgreSQL (всё чаще встречается у новых клиентов). pg_basebackup + WAL streaming — это самый правильный путь. RPO = 0 минут, восстановление возможно на любую секунду.

Кроме того, мы обязательно еженедельно выгружаем базу в формат .dt через конфигуратор. Я сразу предупреждаю: это не «бэкап в полном смысле» этого слова, ведь такая выгрузка не восстанавливает структуру блокировок, журналы регистрации и т.д. Но у неё есть огромное преимущество: она даёт нам возможность переехать на совершенно новый сервер 1С с чистого листа, если вдруг основное хранилище окажется полностью нечитаемым. Это такая «страховка на самый крайний случай».

Для базы PostgreSQL типовой скрипт ночного бэкапа в моих кейсах выглядит так:

#!/bin/bash
# /opt/backup/scripts/backup_1c_pg.sh
# Бэкап PostgreSQL для базы 1С с проверкой целостности

set -euo pipefail

BACKUP_BASE="/backup/1c_pg"
S3_BUCKET="s3://company-backups/1c-pg"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="$BACKUP_BASE/$DATE"
LOG="/var/log/backup/1c_pg.log"

# Telegram
BOT_TOKEN="..."
CHAT_ID="-1001234567890"

log() { echo "$(date '+%F %T') $1" | tee -a "$LOG"; }
alert() { curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
  -d chat_id="$CHAT_ID" -d text="$1" > /dev/null; }

mkdir -p "$BACKUP_DIR"
START=$(date +%s)

log "Starting pg_basebackup → $BACKUP_DIR"
pg_basebackup -h /var/run/postgresql -U backup_user \
  -D "$BACKUP_DIR" -Ft -z --checkpoint=fast \
  --wal-method=stream --label="1c_${DATE}" -P 2>> "$LOG"

# Проверка целостности
log "Verifying integrity..."
if ! pg_verifybackup "$BACKUP_DIR" 2>> "$LOG"; then
    alert "🔴 Backup 1C: integrity check FAILED for $DATE"
    exit 1
fi

# Загрузка в Yandex Cloud
log "Uploading to Yandex Cloud..."
aws s3 sync "$BACKUP_DIR" "$S3_BUCKET/$DATE/" \
  --endpoint-url=https://storage.yandexcloud.net \
  --storage-class STANDARD_IA --only-show-errors

# Ротация локальных бэкапов (хранение 30 дней)
find "$BACKUP_BASE" -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;

DURATION=$(( $(date +%s) - START ))
SIZE=$(du -sh "$BACKUP_DIR" | awk '{print $1}')
alert "🟢 Backup 1C OK: $SIZE in ${DURATION}s, verified, uploaded"
log "Done in ${DURATION}s, size $SIZE"

Важно: каждый бэкап обязательно проверяется (pg_verifybackup), и о результате (успех или провал) приходит уведомление в общий чат IT-команды в Telegram. Бэкап без уведомления — это угадайка.

Бэкап файлового сервера: дешёвый и быстрый

Для файлового сервера я почти всегда выбираю Veeam Agent for Windows. Будет ли он бесплатным или платным — это уже зависит от бюджета, который выделен на проект. Бесплатной версии вполне хватает на один сервер, а платная открывает гораздо больше возможностей: централизованное управление, репликацию в облако и, конечно, шифрование. Если же речь идёт о Linux, то здесь моя альтернатива — это rsync с инкрементальным копированием через hard links.

А теперь о ключевой фишке инкрементальных бэкапов, которые делаются через hard links: первый бэкап, конечно, скопирует все 1.5 ТБ файлового сервера, и это займёт от 4 до 6 часов. Но вот второй и все последующие копирования пройдут всего за 15–25 минут! Почему так быстро? Всё просто: неизменённые файлы не копируются заново, они просто связываются жёсткой ссылкой с предыдущей копией. Для вас, как для пользователя, в файловом браузере каждая папка-снапшот будет выглядеть как полная копия, но физически на диске она займёт только разницу. Это просто магия экономии места и времени!

#!/bin/bash
# /opt/backup/scripts/backup_files.sh
# Инкрементальный бэкап файлового через rsync + hard links

SOURCE="/srv/fileserver/"
BACKUP_BASE="/backup/files"
LATEST="$BACKUP_BASE/latest"
DATE=$(date +%Y%m%d_%H%M%S)
TARGET="$BACKUP_BASE/$DATE"

# Делаем инкрементальный бэкап с hard links к предыдущему
rsync -a --delete \
    --link-dest="$LATEST" \
    "$SOURCE" "$TARGET/"

# Обновляем симлинк latest → новая копия
ln -snf "$TARGET" "$LATEST"

# Ротация: храним 30 ежедневных + 12 еженедельных
find "$BACKUP_BASE" -maxdepth 1 -type d -mtime +30 \
  -not -name "$(date +%Y%m%d -d 'sunday' )*" -exec rm -rf {} \;

На реальном офисе с 1.4 ТБ файлового сервера: первый бэкап — 5 часов 40 минут, дневной инкремент — 12–18 минут, занимает на NAS дополнительно 2–8 ГБ в день. Хранение 30 ежедневных копий съедает не 42 ТБ (как было бы при полных копиях), а всего 1.6 ТБ.

Расписание через systemd и Veeam

Я практически всегда отказываюсь от использования cron в пользу systemd-таймеров на Linux и встроенного планировщика Veeam на Windows. У меня на это есть свои причины:

• Systemd-таймеры умеют ждать запуска зависимых сервисов (например, бэкап PostgreSQL запустится только после старта самого PostgreSQL)
• Встроенное логирование через journald — не нужно отдельно настраивать ротацию
• Лимиты ресурсов через CPUQuota и IOWeight — бэкап не убивает сервер
• Статус через systemctl status — видно, когда был последний запуск и с каким результатом

Пример таймера для бэкапа 1С каждые 6 часов:

# /etc/systemd/system/backup-1c.timer
[Unit]
Description=Backup 1C database every 6 hours

[Timer]
# Запуск в 02:00, 08:00, 14:00, 20:00
OnCalendar=*-*-* 02,08,14,20:00:00
# Если пропустили (сервер был выключен) — выполнить при старте
Persistent=true
# Разброс ±15 минут
RandomizedDelaySec=900

[Install]
WantedBy=timers.target

# /etc/systemd/system/backup-1c.service
[Unit]
Description=Backup 1C PostgreSQL database
After=postgresql.service
Requires=postgresql.service

[Service]
Type=oneshot
User=backup
ExecStart=/opt/backup/scripts/backup_1c_pg.sh
TimeoutStartSec=7200
StandardOutput=journal
StandardError=journal
# Ограничиваем ресурсы — бэкап не должен мешать работе
CPUQuota=50%
IOWeight=100
Nice=10

Мониторинг: бэкап без алертов = «кот Шрёдингера»

Самая частая проблема в реальной жизни — бэкап тихо ломается. Кончается место на NAS, протухает токен Yandex Cloud, кто-то меняет пароль учётке backup_user в PostgreSQL — и весь август бэкапы не делаются, никто этого не знает. В сентябре прилетает шифровальщик, и выясняется, что последний рабочий бэкап датирован 30 июля.

Чтобы избежать такой неприятной ситуации, я специально выстраиваю отдельный health check — это такой «доктор», который каждые 30 минут проверяет состояние абсолютно всех бэкапов. Утром, ровно в 8:00, он отправляет сводку в наш общий Telegram-чат. Если вдруг что-то пойдёт не так, алерты прилетают немедленно, а сводка нужна для спокойного, пассивного контроля.

#!/bin/bash
# /opt/backup/scripts/health_check.sh
# Проверка возраста, размера и доступности всех бэкапов

ALERTS=()

check_backup() {
    local name="$1" max_hours="$2" min_mb="$3"
    local status_file="/opt/backup/status/${name}.json"

    if [ ! -f "$status_file" ]; then
        ALERTS+=("$name: status file отсутствует — бэкап ни разу не запускался")
        return
    fi

    local status=$(jq -r '.status' "$status_file")
    [ "$status" != "ok" ] && ALERTS+=("$name: последний бэкап FAILED")

    local age=$(( ($(date +%s) - $(jq -r '.timestamp' "$status_file")) / 3600 ))
    [ "$age" -gt "$max_hours" ] && \
      ALERTS+=("$name: бэкап ${age}ч (норма ≤${max_hours}ч)")

    local size_mb=$(jq -r '.size_mb' "$status_file")
    [ "$size_mb" -lt "$min_mb" ] && \
      ALERTS+=("$name: подозрительно маленький размер ${size_mb} MB")
}

check_backup "1c_pg"      8   1500    # База 1С: не старше 8 часов, мин 1.5 ГБ
check_backup "files"      4   500     # Файловый: не старше 4 часов, мин 500 МБ
check_backup "ad_state"   26  10      # System State AD: не старше 26 часов

# Доступность облачного хранилища
aws s3 ls s3://company-backups/ --endpoint-url=https://storage.yandexcloud.net \
  > /dev/null 2>&1 || ALERTS+=("Yandex Cloud Storage недоступен")

# Свободное место на NAS
USED=$(df /backup --output=pcent | tail -1 | tr -d ' %')
[ "$USED" -gt 85 ] && ALERTS+=("NAS заполнен на ${USED}% (порог 85%)")

# Если есть алерты — шлём в Telegram
if [ ${#ALERTS[@]} -gt 0 ]; then
    MSG="⚠️ Backup health check FAILED ($(hostname)):"
    for a in "${ALERTS[@]}"; do MSG+=$'\n - '"$a"; done
    curl -s "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
      -d chat_id="$CHAT_ID" -d text="$MSG"
fi

В моих клиентских инфраструктурах этот скрипт работает каждые 30 минут через systemd-таймер. За полгода у одного из клиентов он трижды поймал серьёзные проблемы: переполнение NAS из-за роста файлового, истёкшие credentials Yandex Cloud и однажды — отказ сетевой карты сервера, из-за которого бэкап не выгружался в облако. Все три случая мы починили в течение часа после алерта.

Тесты восстановления: ежемесячная гигиена

Вот это, на мой взгляд, самая-самая важная часть, но почему-то её почти никто не делает! Бэкап, из которого вы ни разу не пробовали восстанавливаться, это, по сути, просто лотерейный билет. Вы же не знаете, сработает ли он в критический момент. Поэтому мы в АйТи Фреш поступаем так:

1. Автоматический недельный smoke-test. Скрипт по расписанию ночью со среды на четверг разворачивает последний бэкап PostgreSQL на отдельном порту, делает контрольный запрос (SELECT count(*) FROM Контрагенты), сравнивает с продакшеном. Если расхождение в пределах нормы (5 % за неделю) — лог OK. Если бэкап вообще не разворачивается — критический алерт.
2. Ручной DR Drill раз в месяц. Один из инженеров команды разворачивает базу 1С с нуля на тестовом стенде, открывает её через тонкого клиента 1С, делает контрольный документ реализации, сверяет несколько отчётов с продакшеном. Время и результат записываются в журнал учений. Делает это каждый раз другой инженер — чтобы навык не зависел от одного человека.

Журнал учений за последние 4 месяца у одного из моих клиентов:

Как видите, мартовский DR drill помог нам выявить серьёзную проблему: устаревший recovery.conf, который замедлял процесс восстановления аж на 11 минут! Если бы не эта проверка, мы узнали бы об этом только в самый неподходящий момент — во время реальной аварии. Вот это тот самый случай, когда учения окупаются на десятилетия вперёд, я вам точно говорю!

Стоимость системы для офиса 30 РМ

Давайте посмотрим на конкретные цифры для типового офиса: это 30 рабочих мест в Москве, один сервер 1С с базой на 80 ГБ и файловый сервер на 1.2 ТБ:

Итак, за первый год общие затраты составят 222 000 + 12 × 13 400 = 382 800 руб. А вот со второго года эта сумма снижается до 160 800 руб./год. Теперь сравните это с одним-единственным инцидентом ransomware, который произошёл у нашего клиента, о чём мы писали в статье про шифровальщиков: тогда прямые потери составили 1.62 млн руб. Очевидно, что наша бэкап-система окупается десятками раз, даже если она предотвратит всего одну катастрофу.

Чек-лист: насколько защищены ваши данные сейчас

Если вы хотите быстро, буквально за 5 минут, оценить текущее состояние своих бэкапов, просто честно ответьте на эти 9 вопросов:

1. Когда последний раз делался бэкап вашей базы 1С? (Если не знаете — это уже плохо)
2. Где хранится этот бэкап? Можете ли вы посмотреть его на физически другом устройстве, не сервере 1С?
3. Есть ли копия бэкапа в облаке или на отдельном внешнем диске?
4. Когда последний раз пробовали восстановить базу из бэкапа? (Не «открыть файл», а развернуть рабочую базу)
5. Знаете ли вы, сколько времени займёт восстановление в случае катастрофы?
6. Получаете ли вы автоматические уведомления, если бэкап провалился?
7. Сколько данных вы готовы потерять в худшем случае — час, день, неделю?
8. Есть ли журнал учений по восстановлению с подписями ответственных?
9. Если завтра придёт ransomware и зашифрует всё — через сколько часов вы сможете работать?

Если на половину вопросов вы отвечаете «не знаю» или «нет» — пора пересматривать бэкап-стратегию. Это не сложно, не безумно дорого и точно дешевле, чем последствия.

FAQ — частые вопросы по бэкапам 1С и файлового сервера

Как часто делать бэкапы базы 1С в офисе?

Минимум — ежедневный полный бэкап ночью + ежечасный инкрементный днём. Для торговых и производственных компаний с активной работой в 1С — каждый час, всегда. Для бухгалтерских баз без интенсивной работы — один полный бэкап в сутки. RPO (допустимая потеря данных) для большинства офисов — не более 1 часа.

Куда хранить бэкапы 1С — на тот же сервер или отдельно?

Никогда не на тот же сервер. Шифровальщик, отказ RAID или пожар уничтожат и базу, и бэкап. Минимум — отдельный NAS в другой комнате офиса. Лучше — NAS + копия в облаке Yandex Cloud / Selectel S3 + еженедельная офлайн-копия на внешний диск через умную розетку. Это и есть схема 3-2-1.

Сколько стоит автоматизация бэкапов для офиса 30 РМ?

Разовая настройка — 40 000–95 000 руб. в зависимости от объёма и инфраструктуры. Подписка на Yandex Cloud Storage для 1 ТБ — около 1 800 руб./мес. Лицензия Veeam Agent на сервер — 12 000 руб./год. Внешний HDD на 8 ТБ — 22 000 руб. разово. Итого первый год — 80 000–140 000 руб., далее — 30 000–45 000 руб./год.

Можно ли восстановить базу 1С без бэкапа?

После шифровальщика — практически никогда. После сбоя диска — иногда, через лабораторию восстановления данных, ценой 80–250 тыс. руб. и шансом 30–60 %. После случайного удаления — теневыми копиями Windows, если они включены и не успели ротироваться. Главный вывод: бэкап должен быть, и он должен регулярно проверяться.

Как проверить, что бэкап рабочий?

Только тестовым восстановлением на отдельном стенде. Раз в месяц мы поднимаем последний бэкап базы 1С на тестовом сервере и делаем контрольные запросы: сколько контрагентов, сколько проводок за прошлый месяц, открывается ли последний документ реализации. Если цифры сходятся — бэкап рабочий. Без таких тестов даже автоматический «успешно завершён» в логе не гарантия.