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