Миф: managed-база снимает с вас ответственность за данные

MAATRIX

«Мы на managed-PostgreSQL, там автобэкапы из коробки, о данных можно не думать» — фраза, после которой обычно наступает тишина, а через полгода приходит инцидент, показывающий, что «можно не думать» и «данные защищены» — не одно и то же. Managed-СУБД действительно снимает с вас часть работы, но не ответственность за содержимое базы. Разница между этими двумя вещами и есть тема этого разбора.

Что managed-СУБД действительно берёт на себя

Когда вы платите за управляемую базу данных, а не поднимаете PostgreSQL или MySQL сами на VPS, провайдер закрывает конкретный и довольно узкий набор задач:

• Аппаратные сбои — вышел из строя диск или узел, провайдер переключает нагрузку на реплику или поднимает инстанс на другом железе, обычно без вашего участия.
• Рутинное администрирование — установка минорных обновлений СУБД, применение патчей безопасности, настройка типовых параметров под объём инстанса.
• Отказоустойчивость на уровне инфраструктуры — синхронная или почти синхронная репликация между узлами, автоматический failover при падении primary.
• Базовый мониторинг ресурсов — метрики CPU, памяти, места на диске, числа соединений, иногда с алертами по порогам.
• Автоматические бэкапы и point-in-time recovery (PITR) — снимки состояния базы по расписанию плюс возможность откатиться на произвольную секунду в пределах какого-то окна.

Это реальная и немаленькая экономия: то же самое на своём VPS вы настраивали бы вручную — от установки СУБД и тюнинга до собственного скрипта резервного копирования, как в статье «managed-база против своей на VPS: за что доплата». Но список выше — это защита инфраструктуры и рутины, а не защита от того, что вы сами сделаете с данными внутри этой инфраструктуры.

Shared responsibility: где заканчивается зона провайдера

У managed-сервисов, как и у облачной инфраструктуры в целом, действует модель разделённой ответственности. Провайдер отвечает за то, что «под» вашей базой — железо, гипервизор, сетевую доступность, сам движок СУБД как программу. Вы отвечаете за то, что «внутри» — схему, данные, запросы, которые к ним применяются, и доступ к инстансу.

SLA, который провайдер публикует для managed-СУБД, почти всегда описывает *доступность инстанса* — процент времени, когда база отвечает на запросы, — а не *сохранность конкретного содержимого*, которое вы туда записали. Формулировки вида «99,9% времени работы» и «ежедневные автоматические бэкапы» ничего не говорят о том, что случится, если ваша миграция или скрипт очистки испортит данные логически, а не физически.

Логическая ошибка реплицируется как обычная запись

Здесь и кроется главное заблуждение мифа. Механизм репликации и автоматического бэкапа managed-СУБД не различает «правильную» запись и ошибочную — он честно фиксирует любое изменение состояния базы, каким бы оно ни было.

Классический пример:

-- задумывалось так:
DELETE FROM orders WHERE status = 'test' AND created_at < '2026-01-01';

-- по факту выполнилось так, потому что скрипт собрал запрос
-- динамически и часть условия потерялась при рефакторинге:
DELETE FROM orders;

Через несколько секунд эта операция уже реплицирована на standby-узел и попала в поток WAL/binlog, который питает автоматический бэкап. С точки зрения провайдера всё штатно: инстанс отвечает, реплики согласованы, метрики зелёные. Просто согласованы они теперь на пустой таблице orders.

Та же логика работает для:

• миграции, которая переименовала или удалила колонку без обратной совместимости;
• утечки учётных данных приложения и последующего массового UPDATE/DELETE от лица легитимного пользователя базы;
• бага в коде, который постепенно портит записи — и вы замечаете это не сразу, а через дни или недели, когда «правильное» состояние уже давно вытеснено из истории изменений.

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

Retention: почему автоматические бэкапы — не бесконечная история

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

Типичная логика устройства такого окна (конкретные цифры у каждого провайдера свои, и их нужно смотреть в настройках именно вашего инстанса, а не предполагать по аналогии):

Проблема в том, что окно retention молчаливо тикает независимо от того, заметили вы инцидент или нет. Логическая порча данных — не всегда мгновенно видимое событие: баг, который постепенно искажает часть записей, может оставаться незамеченным ровно столько, сколько нужно, чтобы «здоровая» версия данных выпала из окна хранения бэкапов. К моменту, когда проблему находят (например, при сверке с внешней системой или жалобе клиента), восстанавливать уже не из чего — ровно то же самое отсутствие точки отката, что и в разборе «миф: облако само делает бэкапы», только относится не к диску VPS, а к managed-инстансу базы.

Сколько именно нужно хранить историю, чтобы такой сценарий не сработал против вас, — вопрос не универсальный, а зависящий от того, как быстро в вашей системе обнаруживаются логические ошибки. Эта логика разобрана в статье «сколько хранить бэкапы и какая ротация»: чем медленнее вы замечаете проблему, тем глубже должна быть история, независимо от того, own-hosted у вас база или managed.

Что искать в SLA, а чего там никогда не будет

Прежде чем полагаться на конкретный managed-сервис, стоит прочитать не маркетинговую страницу, а раздел документации или тарифа именно про backup/retention для выбранного вами инстанса, и найти в нём ответы на несколько конкретных вопросов:

1. Какой конкретно retention период у автоматических бэкапов по умолчанию — часы, дни, недели? Это число, а не общая фраза «регулярные бэкапы».
2. Есть ли PITR, и на какую глубину назад он реально позволяет откатиться, а не только «есть снимок раз в сутки».
3. Продлевается ли retention платно, и если да — до какого предела, и хватает ли этого предела для вашего сценария обнаружения ошибок.
4. Хранятся ли копии физически отдельно от рабочего инстанса (другой регион, другое хранилище), или всё крутится в одном логическом периметре и погибнет вместе при более крупном инциденте.
5. Что именно покрывает компенсация по SLA при его нарушении — почти всегда это кредит на будущие платежи за простой сервиса, а не возмещение стоимости утраченных данных.
6. Кто управляет ключами шифрования бэкапов, если оно есть, — это отдельный вопрос ответственности, который стоит уточнить явно, а не считать решённым по умолчанию.

Ни один из этих пунктов SLA обычно не формулирует как «мы гарантируем сохранность содержимого вашей базы» — потому что провайдер физически не может гарантировать, что вы или ваш код не удалите данные сами. Это структурно та же граница, что описана в статье про проверку рабочего бэкапа: наличие функции бэкапа в тарифе — это не гарантия того, что конкретно вам эта функция поможет в конкретной ситуации, если её параметры не сверены с вашими рисками заранее.

Что дополнительно должен делать владелец данных

Managed-сервис закрывает инфраструктурную часть, поэтому оставшаяся часть shared responsibility — процессная, и она не требует администрирования СУБД, только дисциплины:

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

# логический дамп managed-базы по внешнему подключению
pg_dump -h your-managed-host.example.com -U appuser -Fc mydb \
  > /tmp/mydb-$(date +%F).dump

# отправка во внешнее хранилище, не связанное с провайдером базы
restic -r s3:https://s3.another-provider.example.com/db-archive \
  backup /tmp/mydb-$(date +%F).dump --tag weekly

• Продлите retention до величины, соответствующей скорости обнаружения проблем в вашей системе, если дефолтного окна недостаточно — и держите отдельный длинный архив (еженедельный или ежемесячный дамп) поверх ежедневных PITR-точек провайдера.
• Вводите ревью для деструктивных операций — миграции и разовые скрипты с DELETE/UPDATE/DROP должны проходить через --dry-run, транзакцию с явным ROLLBACK для проверки количества затронутых строк, или как минимум второй взгляд коллеги перед прогоном на проде.
• Ограничивайте права доступа по принципу минимально необходимых: массовые операции по всей таблице не должны быть доступны той же учётной записи, от имени которой работает обычное приложение.
• Регулярно тестируйте восстановление, а не только факт, что бэкап существует, — поднимите отдельный инстанс из точки PITR или из архивного дампа и сверьте данные приложением, а не глазами.
• Зафиксируйте RPO и RTO письменно — сколько данных вы готовы потерять и за сколько времени готовы восстановиться — и сверяйте с этим реальные параметры retention и скорость восстановления, а не считайте их приемлемыми по умолчанию.

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

Частые вопросы