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

Чем бэкапить 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. В цену входит хранилище, мониторинг, тестирование, отчётность, гарантия восстановления.