Как сделать резервное копирование эффективным и надёжным?

Создать карусель
Прошло уже более 15 лет с момента внедрения нашей текущей системы резервного копирования, и за это время она многократно доказывала свою эффективность. Именно она позволяет нам быстро восстанавливать утраченные данные в результате технических сбоев или человеческих ошибок.
Однако в 2025 году мы столкнулись с рядом инцидентов, которые указали на узкие места и необходимость усовершенствования текущей системы.

Анализ инцидентов

 1. Февраль 2023

Внутренний сервер, находящийся в дата-центре Хесснера (Германия), стал недоступен. Он использовался с начала 2010-х годов и содержал около 2 ТБ критически важной информации: архивы проектов, dev-серверы, резервные копии и особенно важные данные git-сервера, где хранилась вся история изменений и накопленные данные за десят лет, а также все задачи и обсуждения в Jira.
Результат:
Благодаря действующей системе резервного копирования, за два дня было восстановлено 80–90% инфраструктуры, остальное — в течение нескольких дней.

2. Февраль 2025

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

3. Март 2025
В другом проекте база данных стала недоступна — сервер не откликался, а восстановить резервную копию было некуда.
Результат:
Потери: один день на восстановление работы, два дня потерь данных. За это время клиент утратил сотни заказов, включая те, что поступали из маркетплейсов и обрабатывались через 1С-Битрикс. Система фактически выступала посредником между маркетплейсами и учётной системой.

Вывод:
Даже однодневная потеря данных критична. Необходима более частая и актуальная копия базы данных.


Принцип работы системы резервного копирования


С учётом инцидентов, мы построили новую многоуровневую систему:
1. Ежедневное и промежуточное копирование:
  • Полный бэкап ядра и базы данных — ежедневно вечером.
  • Копия базы данных — каждые 3 часа (без временных/служебных таблиц).
  • Медиа-контент — раз в неделю, отдельным потоком (объёмы до сотен ГБ).

Храним локально в специальной директории backup внутри папки Bitrix, поскольку мы ориентированы исключительно на работу с платформой 1С-Битрикс.

2. Автоматизированный сбор:
Утром специальный сервер, ответственный за функцию передачи данных (transfer server), подключается к серверам клиентов и скачивает последние копии.

3. Распределённое географическое хранение (5 мест):
  • BackUp-сервер в дата-центре — основной сервер резервного копирования.
  • Облачное облачное хранилище, которое полностью синхронизируется с BackUp-сервером.
  • Физический сервер с RAID-массивом, обеспечивающим защиту данных посредством синхронизации дисков. Который также синхронизирует данные из BackUp-сервера.
  • Нововведение — S3-хранилище в другом data-центре (сначала сделали по просьбе клиента — а теперь внедрили у всех).
  • Локальная копия у клиента.

4. Снимки серверов (snapshots):
Раз в неделю создаём полный образ сервера с ОС. На случай сбоя «железа» можно будет развернуть образ проекта на другом «железе» с необходимой конфигурацией и оптимизацией под проект.

Мы храним данные по проектам за последние 15 дней. Хранить больше — нет смысла, данные становятся неактуальными.

5. Git-контроль версий:
Весь код проекта, включая ядро 1С-Битрикс, хранится в Git. Мы отслеживаем все изменения, в том числе при обновлении платформы или моделей, и можем восстановить проект с любой точки истории. История кода хранится более 15 лет — это все задачи за все годы работы.
Также проект можно выгрузить на USB-флешку. В случае полного отказа сети или невозможности доступа к другим источникам резервных копий, это решение позволит быстро передать проект клиенту или воспользоваться самим в случае инцидентов.


Рекомендации по настройке резервного копирования


При работе с крупными проектами важно учитывать эти особенности:
1. Ежедневного копирования — недостаточно.
При большом объёме данных за сутки одна резервная копия в день — это слишком редко. Разница между копией, сделанной раз в 24 часа, и копией каждые 3 часа может быть критичной: за это время теряется значительный объём заказов, данных и транзакций.
Поэтому копии каждые 3 часа — оптимальны.
2. Большой объём бэкапов.
Размер одного бэкапа может достигать 100 ГБ и больше. При использовании стандартных средств системы может возникнуть множество проблем:
  • часть данных не попадёт в бэкап;
  • бэкап получится повреждённым;
  • восстановление будет затруднено или невозможным.

Вывод:


В крупных проектах важно выстраивать систему резервного копирования в несколько потоков — отдельно для базы данных, медиафайлов и системных компонентов. Это повышает надёжность и скорость восстановления данных.
Частота копирования определяется уровнем активности проекта и объемом обрабатываемых данных:
  • Низкая активность — еженедельно.
  • Средние проекты — ежедневно.
  • Проекты с высокой нагрузкой — каждые 3 часа.

Такой подход позволяет минимизировать потерю данных в случае аварии и обеспечить непрерывность бизнеса.

Географическое распределение данных:
Каждая копия хранится на 5 независимых друг от друга площадках. :
  • Облако — основной вариант размещения данных.
  • Физические сервера — дополнительный уровень безопасность.
  • Дата-центры — обеспечивают территориальное разделение и минимизируют риски потери данных.

Такой подход обеспечивает высокий уровень отказоустойчивости и гарантирует быстрое восстановление данных даже в случае масштабных сбоев.


Дополнительные меры предосторожности


  • Хранение важных документов и баз данных в S3-облаках.
  • Регулярные снимки серверов с ОС, позволяющих быстро вернуть систему к рабочему состоянию.
  • Разделение резервного потока: ядро, база, медиа — отдельно.

Эти шаги помогают снизить риск полной утраты данных и сократить время восстановления после аварийных ситуаций.


Итоги:


Соблюдение этих рекомендаций позволяет:
  • минимизировать потери при сбоях,
  • обеспечить бесперебойную работу бизнеса,
  • защитить данные на всех уровнях.