Каждые 12 часов система резервного копирования PlanetScale превращает состояние загруженной базы в консистентный зашифрованный снапшот и не трогает продакшен-запросы. Для шардированных баз приходится поднимать отдельные EC2-инстансы, тянуть данные из Amazon S3 и реплеить WAL с массовым параллелизмом — так можно забекапить петабайтные базы за часы на скорости больше 50 GB/s.
В Neki, шардированном Postgres от PlanetScale, за основу взяты обычные бэкапы Postgres: файловый снапшот + повторное применение архивированного WAL. Проблема в том, что делать это прямо на primary или репликах дорого по IOPS и CPU. Поэтому для каждого шарда запускают новый EC2-инстанс, восстанавливают на нём последний бэкап из S3 и догоняют его до текущего состояния. WAL непрерывно архивируется в S3 через wal-g, но из-за пятиминутного archive_timeout свежие сегменты могут не успеть уйти в хранилище. Поэтому основную часть WAL качают из S3, а последние несколько минут — напрямую с primary. Когда все ноды догнали репликацию до времени T, репликацию останавливают, время сохраняют, а бэкап шифруют и отправляют в новый S3-бакет. Потом временные инстансы удаляют.
Для первой копии новой базы используют pg_basebackup: он подготавливает временные ноды с каждого primary, затем настраивается репликация, WAL догоняется и бэкап заливается через wal-g — формат такой же, как у steady-state.
Параллелизм по шардам даёт огромный выигрыш. Не шардированная база 32 ТБ со сжатыми бэкапами 20 ТБ потребовала бы перекачать около 40 030 ГБ; при 500 MBps это ~22 часа — два бэкапа в сутки накладывались бы и ломали RPO. Те же данные на 8 шардах — 2.8 часа, на 32 — 42 минуты. 100 ТБ на 100 шардах бэкапятся с той же скоростью, что 1 ТБ на одном шарде.
Бэкапы нужны не только для спасения от катастроф. В Metal-базах на локальных NVMe они участвуют в каждом ресайзе: для 24 старых i8g.xlarge поднимают 24 новых i8g.2xlarge, каждый тянет бэкап из S3, догоняет WAL, становится standby и после switchover получает роль primary. Так же восстанавливают отказавшие ноды: новый инстанс, рестор бэкапа, догон WAL, включение в репликацию.
Шардированный MySQL на Vitess работает похоже: вместо встроенных механизмов Postgres используется VTBackup, вместо WAL — MySQL binary log, а догон идёт только с primary.