Бэкап баз данных для бизнеса: MySQL, PostgreSQL, 1С — как мы это делаем в АйТи Фреш

Меня зовут Семёнов Евгений Сергеевич, я 15 лет занимаюсь обслуживанием офисной IT-инфраструктуры в Москве. За эти годы через мои руки прошли сотни инцидентов с потерей данных — от «случайно удалили прайс» до «в серверную залили воду с верхнего этажа». И каждый раз финал определялся не героизмом инженеров, а одним простым параметром: был ли нормальный бэкап. В этой статье я расскажу, как мы в АйТи Фреш организуем резервное копирование баз данных 1С, Bitrix24, CRM, интернет-магазинов и всего, что для бизнеса критично.

Почему «у нас есть бэкап» — это почти всегда неправда

За 15 лет я выработал профессиональную привычку: когда новый клиент говорит «у нас всё бэкапится», я не верю. Не потому что он врёт — он искренне уверен. Просто в девяти случаях из десяти на первом же аудите выясняется одно из следующего:

• Бэкап делается, но на тот же сервер, где стоит база. Сгорит сервер — сгорит всё.
• Бэкап делается на сетевую папку, но шифровальщик её тоже видит и тоже зашифрует.
• Бэкап делается, но за последние полгода никто не проверял, разворачивается ли он.
• Бэкап перестал делаться три месяца назад — место кончилось, скрипт тихо падает с ошибкой.
• Бэкап выгружается в облако, но никто не помнит пароль и у кого есть доступ.
• Бэкап есть, но он только за вчера. А утечка случилась месяц назад, и сейчас уже поздно.

Потому простой вопрос «есть ли у вас бэкап» я всегда заменяю на длинную серию: где хранится, как часто делается, когда последний раз успешно развернули, какой сценарий покрывает, где вторая копия, кто получит уведомление при провале задания. И если хоть на один вопрос «не помню/не знаю/никогда» — бэкапа считайте нет.

Принцип 3-2-1, который работает для любого офиса

Этот принцип я объясняю каждому клиенту на первой встрече, и за 15 лет не нашёл ничего лучше. Он прост: минимум три копии данных, на двух разных типах носителей, и одна копия физически вне офиса. Разберу на примере бухгалтерии с базой 1С 80 ГБ.

• Копия 1 — «живая» база на сервере 1С. Это не бэкап, это оригинал.
• Копия 2 — ежедневный бэкап на отдельный NAS в серверной. Быстрое восстановление при случайном удалении или порче базы.
• Копия 3 — еженедельный шифрованный бэкап в нашем дата-центре МТС. Страховка от пожара, кражи сервера, шифровальщика, захвата офиса.

Для офиса до 25 рабочих мест всё это стоит в районе 18–25 тыс. руб./мес абонентки на бэкап плюс разовая настройка 40–65 тыс. руб. Для сравнения: восстановление базы 1С из «остатков» после шифровальщика — от 250 до 800 тыс. руб. специалистам по data recovery, без гарантий результата.

Чем бэкапить MySQL и PostgreSQL для бизнес-приложений

К нам в АйТи Фреш часто приходят клиенты с Bitrix24 на собственном сервере, интернет-магазинами на MODX или WordPress с WooCommerce, CRM Мегаплан self-hosted. Под капотом у всех них — MySQL или PostgreSQL. Расскажу, какие инструменты мы используем на продакшене.

MySQL: mysqldump, Percona XtraBackup и бинарные логи

Для баз до 10 ГБ — mysqldump с опциями --single-transaction --quick --routines --triggers. Делаем раз в сутки, архивируем в gzip, отправляем на NAS и параллельно в S3-хранилище. Время создания бэкапа базы 8 ГБ — около 4 минут, восстановление — 12–15 минут.

Для баз 10–500 ГБ переключаемся на Percona XtraBackup. Он делает физическую копию файлов InnoDB без блокировки базы и работает в 5–10 раз быстрее mysqldump. Для базы 80 ГБ бэкап занимает 8 минут, восстановление — те же 8 минут. Плюс XtraBackup умеет в инкрементальные бэкапы, что экономит место.

Дополнительно включаем binary logging — это «журнал операций» MySQL. Каждые 15 минут ротируем текущий binlog и отправляем в хранилище. При катастрофе восстанавливаем последний полный бэкап, потом накатываем binlogs до нужной секунды. Точность восстановления — до секунды.

# ежесуточный полный бэкап базы Bitrix
xtrabackup --backup --target-dir=/backup/bitrix/full-$(date +%F) \
  --user=backup --password=XXX --compress --compress-threads=4

# каждые 15 минут — flush binlog в архив
mysql -e "FLUSH BINARY LOGS"
rsync -a /var/lib/mysql/mysql-bin.* /backup/binlogs/

PostgreSQL: pg_dump и WAL-архивирование

Для PostgreSQL логика та же, инструменты другие. Ежедневный pg_dump -Fc (custom format, встроенное сжатие) для баз до 50 ГБ. Для больших — pg_basebackup плюс постоянное архивирование WAL через pgbackrest. Этот инструмент мы используем уже четыре года на всех серьёзных Postgres-инсталляциях: он умеет параллельные бэкапы, шифрование AES-256, инкрементальные и дифференциальные копии, верификацию целостности.

На нашем типовом развёртывании pgbackrest держит 7 ежедневных полных бэкапов, 30 дифференциальных, непрерывный архив WAL. Это даёт восстановление на любую секунду за последние 30 дней.

Бэкап 1С: отдельная история, где можно накосячить по-крупному

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

Правильная схема для файловой 1С:

1. Ночью пользователи выходят из базы (либо администратор принудительно выгружает их через сервис «Блокировка работы пользователей»).
2. Делается копия папки 1Cv8.1CD — это быстро и всегда восстанавливается.
3. Раз в неделю делается dt-выгрузка через конфигуратор для страховки.

Правильная схема для клиент-серверной 1С на MS SQL Server:

1. Full backup базы MS SQL каждую ночь через стандартный план обслуживания.
2. Каждые 15 минут — transaction log backup (если база в режиме Full Recovery).
3. Раз в неделю — проверка целостности через DBCC CHECKDB.
4. Раз в месяц — тестовое разворачивание на отдельный сервер и проверка, что база открывается в 1С и в ней видны свежие документы.

Последний пункт — самый важный и самый часто пропускаемый. Я видел компанию, где полгода никто не замечал, что backup-файлы MS SQL повреждены из-за bad-сектора на NAS. Узнали в тот момент, когда понадобилось восстанавливаться. Счастливчики — успели взять SQL-файлы с зеркала, которое сделал сам MS SQL по случайному везению. Нечастое везение.

Хранилище бэкапов: куда класть и как шифровать

Частый вопрос: «Можно ли хранить бэкапы в облаке Яндекса или Selectel?» Можно и нужно, но с оговорками:

Мы в АйТи Фреш используем гибрид: локальный NAS в офисе клиента для быстрого восстановления плюс резервная копия в нашей стойке в дата-центре МТС. Между ними — зашифрованный канал, бэкапы заливаются ежедневно ночью. Ключи шифрования хранятся отдельно у клиента, чтобы даже при компрометации нашей инфраструктуры злоумышленник не смог прочитать данные.

Что делать, чтобы бэкап не был фикцией

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

• Бэкап делается автоматически по расписанию, а не руками «когда вспомнит».
• Ежедневно приходит уведомление об успешном завершении с размером бэкапа.
• Уведомление о провале задания приходит в Telegram/email минимум двум людям.
• Ротация настроена: хранятся 14–30 ежедневных, 8–12 еженедельных, 12–24 ежемесячных копии.
• Одна из копий физически вне офиса.
• Копии зашифрованы, ключи не лежат рядом с бэкапами.
• Раз в месяц проводится тестовое восстановление на отдельный сервер.
• Размер бэкапа мониторится — резкое уменьшение сигнализирует о проблеме.
• Задокументирована процедура восстановления: пошагово, с контактами, паролями в KeePass.
• При смене админа процедуру знает минимум один резервный человек.

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

Реальный кейс: спасли интернет-магазин за 3 часа

Сентябрь 2025-го. К нам в АйТи Фреш пришёл интернет-магазин стройматериалов, который мы обслуживали на абонентке восьмой месяц. CMS — 1С-Битрикс на сервере с MySQL 8.0, оборот около 4 млн руб./мес. В пятницу в 14:00 контент-менеджер случайно через админку CMS удалил раздел «Двери» — это около 800 товарных карточек со всеми остатками, ценами, описаниями, изображениями. Заметили только в 16:30, когда стали поступать жалобы от клиентов: «У вас раздел дверей пропал».

Вот в этот момент клиент очень обрадовался, что три месяца назад мы убедили его поставить нашу схему бэкапа. По плану: ежесуточный полный бэкап XtraBackup в 03:00 ночи, плюс binary log каждые 15 минут с архивированием в наше S3-хранилище. Текущий размер базы — 14 ГБ.

Алгоритм восстановления:

1. В 16:45 я зашёл на резервный сервер в нашем дата-центре, развернул бэкап от 03:00.
2. В 17:10 применил binary logs до момента 13:58 (за две минуты до удаления).
3. В 17:25 экспортировал из восстановленной базы только таблицы с разделом «Двери» (b_iblock, b_iblock_element, b_iblock_property с фильтром по разделу).
4. В 17:50 импортировал эти данные обратно в продакшен-базу.
5. В 18:05 сбросил кэш Битрикса, проверил, что раздел отображается.

Итого — 3 часа 15 минут от обращения до полного восстановления, без потери ни одного заказа за день. Стоимость работ — 28 тыс. руб. (вне абонентки, как срочные работы). Стоимость отсутствия раздела «Двери» на выходные, если бы мы не восстановили: оценочно 600–900 тыс. руб. потерянной выручки плюс репутационный ущерб.

Сколько стоит нормальный бэкап в 2026 году

Цены на апрель 2026 по нашим проектам:

Шифровальщики и стратегия защиты бэкапов

За 2024–2025 год шифровальщики научились охотиться именно на бэкапы. Современный LockBit или Babuk сначала ищет в сети резервные копии, удаляет или шифрует их, и только потом начинает шифровать продакшен. Логика простая: если у жертвы нет бэкапов — она заплатит выкуп.

Что мы делаем, чтобы наши бэкапы пережили атаку:

• Принцип pull, а не push. Не сервер баз данных отправляет бэкапы на NAS, а наш бэкап-сервер сам ходит и забирает. Если продакшен скомпрометирован, до бэкап-сервера злоумышленник не доберётся.
• Immutable storage. На S3-хранилище включаем Object Lock — файл нельзя удалить или изменить в течение указанного срока даже из-под root. Это финальный рубеж защиты.
• Отдельные сетевые сегменты. Бэкап-инфраструктура в отдельной VLAN, доступной только с конкретных IP. Из обычной офисной сети туда не зайти.
• Отдельные учётные записи. Учётка для бэкапов нигде больше не используется и не имеет доступа к продакшену кроме чтения.
• Air-gap копия. Раз в неделю самый ценный бэкап копируется на внешний диск, который физически отключается. Сценарий «полный апокалипсис» он покрывает.

FAQ — частые вопросы

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

Полный бэкап — каждую ночь. Дополнительно в течение дня — инкрементальные или логи транзакций каждые 15–30 минут.

Где хранить бэкапы базы 1С?

По правилу 3-2-1: три копии, на двух разных носителях, одна копия вне офиса. Обычно это NAS + внешний диск + облачное хранилище.

Чем отличается холодный бэкап 1С от dt-выгрузки?

DT-выгрузка годится для переноса между версиями, но долгая и блокирует базу. Холодный бэкап — быстрая полная копия файлов. Для продакшена нужен холодный бэкап плюс архив логов.

Надо ли тестировать восстановление из бэкапа?

Обязательно, раз в месяц минимум. Бэкап, который ни разу не восстанавливали — это не бэкап, это надежда.

Сколько стоит нормальный бэкап для офиса?

От 12 до 45 тыс. руб./мес в зависимости от объёма и SLA. В цену входит хранилище, мониторинг, тестирование, отчётность, гарантия восстановления.