Репликация и резервное копирование баз данных: в чём разница и зачем нужны оба

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

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

Что такое репликация данных

Репликация данных — это синхронизация копий базы между узлами в режиме реального времени или близко к нему. Запись на мастере почти сразу попадает на реплики. Это делается ради высокой доступности: при падении одного узла трафик уходит на живой.

Есть два подхода:

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

В Tarantool асинхронная репликация работала с самого начала, синхронная добавилась в версии 2.5.1, а в 2.6.1 появились выборы лидера по алгоритму RAFT. Все транзакции проходят через WAL (write-ahead log).

Для горизонтального масштабирования применяют модуль vshard: данные шардируются по бакетам, и вместе с WAL и снапшотами это закрывает аппаратный контур отказоустойчивости.

У репликации есть особенность: она не различает «хорошие» и «плохие» изменения. Любая команда на мастере — будь то DELETE без WHERE или запись, сделанная шифровальщиком, — попадает на все реплики в том же виде. Ограничение действует для любого типа репликации: синхронной или асинхронной — и не зависит от СУБД.

Что такое резервное копирование

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

Типы бэкапов различают по полноте:

• Полный (Full) — полная копия базы. Она занимает много места, зато восстанавливается быстрее всего.
• Инкрементный (Incremental) — только изменения с прошлого инкремента. Место экономит, но для восстановления нужна вся цепочка.
• Дифференциальный (Differential) — изменения относительно последнего full. Это компромисс между скоростью и объёмом.

Также есть деление по способам снятия:

• Логический бэкап, или дамп, — экспорт данных через SQL или утилиту. Он портативен, но работает медленнее.
• Физический, или snapshot, — слепок файлов на диске. Он быстрый, но привязан к версии движка.

Отдельно стоит point-in-time recovery. Базу восстанавливают из снапшота, а затем накатывают WAL-файлы до нужной секунды. Это единственный способ откатиться к состоянию «за минуту до того, как кто-то выполнил DROP TABLE».

Репликация и резервное копирование баз данных: ключевые различия

Типичная ошибка проектов любого масштаба — считать репликацию бэкапом. Это не так.

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

Например, представьте, что администратор выполнил DELETE без WHERE. Репликация разнесёт эту команду по всем узлам кластера за секунды, и живых копий не останется. То же происходит с шифровальщиком: ransomware попадает на мастер, синхронизация уносит зашифрованные блоки на реплики, а если бэкапы лежат в той же сети, шифруются и они.

Репликация без изолированного бэкапа не защищает от логических и злонамеренных изменений, независимо от СУБД и топологии кластера.

Репликация несёт риски потери информации там, где ошибка логическая, а не аппаратная. Резервное копирование как раз закрывает сбои этого класса: человеческий фактор, шифровальщики, повреждение данных.

Что происходит при аварии: реальные сценарии

Разберём сценарии катастроф в IT-инфраструктуре, с которыми сталкиваются команды.

Случайное удаление. DROP TABLE, TRUNCATE, DELETE без WHERE. В кластере с синхронной репликацией и тремя репликами ошибка разойдётся за миллисекунды. Без бэкапа и PITR возвращать нечего. Защита данных от случайного удаления строится только на внешних копиях и журнале транзакций.

Шифровальщик. В июне 2024 года группа Brain Cipher (вариант LockBit 3.0) атаковала индонезийский национальный ЦОД PDNS 2 и остановила более 200 государственных сервисов. Атакующие запросили 8 млн долларов выкупа, правительство отказалось платить, восстановление растянулось на недели, пока хакеры сами не выложили ключ дешифрования. Кейс показывает, почему иммутабельные копии критичнее готовности платить: целенаправленные атаки на системы бэкапа — стандартная часть сценария.

Повреждение данных. Битый сектор диска, баг в приложении, неправильная миграция. Один bad record превращается в тысячи на всех репликах — классическое распространение ошибок при репликации баз данных.

Шаги восстановления после сбоя базы данных в каждом сценарии разные, но порядок общий: изолировать источник, проверить целостность ближайшей рабочей копии, восстановить до точки перед инцидентом, накатить WAL, верифицировать данные, вернуть трафик.

Рабочая архитектура

Стандарт индустрии — правило 3-2-1-1-0. Это три копии данных, два разных типа носителей, одна копия off-site, одна копия immutable или air-gapped и ноль ошибок при верификации восстановления.

Иммутабельный бэкап обычно реализуют через S3 Object Lock или WORM-хранилища. Такую копию нельзя перезаписать или удалить до истечения срока, даже администратору с root-правами. Это защита от ransomware.

Отказоустойчивая архитектура хранения данных состоит из двух непересекающихся контуров:

• Горячий контур высокой доступности включает синхронную репликацию, автоматический фейловер и шардирование. Его цель — минимальный RTO при отказе узла или ЦОДа/зоны доступности.
• Холодный контур резервного копирования включает регулярные full, инкременты, WAL-архив для PITR, off-site и immutable-копии. Его задача — гарантированное восстановление при логической аварии.

Tarantool закрывает горячий контур штатными средствами: RAFT-репликацией с кворумом и выборами лидера, WAL для журналирования транзакций, снапшотами для быстрого старта, vshard для горизонтального масштабирования и автоматическим переключением мастера. Для Disaster Recovery поверх этого настраивают отдельный иммутабельный бэкап во внешнее хранилище.

Tarantool Database — готовая in-memory СУБД, где репликация, снапшоты и резервное копирование собраны из коробки. Команда получает преднастроенный кластер вместо ручной сборки компонентов. Разборы архитектурных кейсов — в блоге Tarantool.

Как правильно строить систему бэкапов

Нередко восстановиться из бэкапа после инцидента не удаётся. Причины обычно повторяются от проекта к проекту:

• Бэкап хранят в той же сети, что и прод. Шифровальщик добирается до всего, что доступно по сети.
• RPO и RTO задекларированы, но ни разу не замерялись. При первой аварии выясняется, что реальность в разы хуже.
• Нет изоляции: air-gap отсутствует, immutable-политика не включена. Достаточно одной скомпрометированной учётки, чтобы остаться без копий.
• Мониторинг заканчивается на сообщении «джоб завершился успешно». Целостность архива никто не проверяет.

Команда без отлаженного Disaster Recovery восстанавливается неделями и тратит сотни человеко-часов, команда с тестируемым DR укладывается в час. Разница в том, что бэкап заранее проверен, изолирован и документирован.

Рабочая стратегия резервного копирования и репликации держится на трёх принципах:

• Репликация закрывает аппаратные отказы и балансировку нагрузки.
• Бэкап закрывает логические аварии и катастрофы.
• Регулярная верификация превращает обе линии обороны из декларации в рабочий инструмент.

Заключение

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

Архитектура, которая работает в бою, включает оба контура. Они должны быть изолированы друг от друга, с иммутабельными копиями и регулярной проверкой восстановления. И правило 3-2-1-1-0 — это не просто бюрократическая формальность, а реальная необходимость для сохранности ваших данных.

Платформы вроде Tarantool дают готовые примитивы для горячего контура: RAFT, WAL, vshard, снапшоты. Поверх них уже строится собственная политика DR.

Дальше всё упирается в дисциплину: тестировать восстановление, хранить копии вне прод-сети и замерять RPO и RTO на учениях, а не после инцидента.