Сообщить об ошибкеКороткий ответ
Репликация защищает от отказа оборудования, но мгновенно копирует и ошибочные или вредоносные изменения (удаление таблицы, шифровальщик, баг в коде) на все реплики, поэтому только отдельные, изолированные во времени бэкапы защищают от логических ошибок и порчи данных.
Как это работает подробнее
реплика синхронно или почти синхронно повторяет все операции с основного узла, включая `DELETE`, `DROP TABLE` или повреждение файла; бэкап — это снимок состояния на конкретный момент времени, хранящийся отдельно и неизменяемо.
Пример / кейс
Ожидаемое поведение: на реплике эта же команда выполнится почти мгновенно, и данные пропадут везде; восстановить можно только из бэкапа, сделанного до ошибочной команды, либо через point-in-time recovery по журналу транзакций.
Пример кода
example.sql
-- Инженер по ошибке выполняет на проде:
DELETE FROM orders WHERE created_at < '2024-01-01';
-- без WHERE-условия сработал бы ещё хуже, но и так удалены легитимные старые заказыЧто использовать на практике
- Практический подход. Нужна комбинация — репликация для быстрого переключения при аппаратном сбое (высокая доступность) и регулярные бэкапы с ретенцией (возможность откатиться на точку до ошибки). Бэкапы стоит хранить в другом месте/аккаунте и с защитой от удаления (immutability, versioning).
Подводные камни
- Частые ошибки. Утверждать, что "у нас есть реплика, бэкапы не нужны"; хранить бэкапы в том же месте и с тем же доступом, что и продовую базу, из-за чего один скомпрометированный аккаунт убивает и то, и другое; не проверять, что бэкап реально восстанавливается.