Резервное копирование баз данных

Opfield создаёт штатные резервные копии баз PostgreSQL, Redis и ClickHouse и записывает их в подключённое хранилище. Резервное копирование работает и для управляемых баз данных, и для внешних подключений и доступно на тарифах Personal и выше. Каждое резервное копирование и восстановление выполняется как задание на ноде хранилища, которую вы выбираете исполнителем, а не на хосте Opfield.

Резервная копия защищает данные приложения. Она не заменяет набор для восстановления плоскости управления Opfield, описанный в разделе Обновления, резервные копии и восстановление, и не является восстановлением на момент времени: объём возможной потери данных определяется расписанием.

Перед началом

• Подключённое хранилище с уже существующим бакетом назначения. Opfield записывает данные в выбранные бакет и префикс, но не создаёт бакет. Имена бакетов должны соответствовать правилам именования S3 даже для мест назначения FTP, FTPS и SFTP, где бакеты — это каталоги внутри базового пути.
• Нода хранилища с актуальным демоном, которой доступны и база данных, и адрес хранилища. Для приватных управляемых баз данных и управляемого объектного хранилища Opfield открывает временные приватные маршруты на время запуска.
• Место назначения в управляемом хранилище с TLS должно обслуживать сертификат с именами localhost и 127.0.0.1. Opfield автоматически добавляет эти имена в кластеры, созданные в более раннем выпуске; пока новый сертификат не обслуживается, запуски ждут в очереди с указанием причины и повторяются сами, а через 7 часов завершаются ошибкой BACKUP_STORAGE_CERTIFICATE_OUTDATED. См. «Продление сертификата TLS».
• Пока запись в управляемое хранилище назначения заморожена для миграции, резервное копирование и восстановление, которые записывали бы в него, отклоняются с кодом STORAGE_WRITES_FROZEN; сначала перенесите или приостановите их политики.
• Для внешней базы данных с TLS задания резервного копирования и восстановления применяют параметр проверки сертификата этого подключения и его собственный CA. Исполнитель, Docker-демон которого старше 2.11, не умеет проверять сертификаты, поэтому запуск для проверяемого подключения завершается ошибкой BACKUP_EXECUTOR_TLS_VERIFICATION_UNSUPPORTED; обновите ноду хранилища или отключите проверку для этого подключения.
• Нода хранилища должна иметь возможность загрузить образ исполнителя резервного копирования из GitHub Container Registry. Исполнитель поставляется вместе с выпуском Opfield и закреплён по дайджесту; для PostgreSQL он выбирает клиентские утилиты, соответствующие версии сервера. Исполнитель запускается только на время резервного копирования или восстановления, как и другие внутренние контейнеры Opfield, скрыт из списков контейнеров и пользовательских действий жизненного цикла и содержит фиксированный набор штатных инструментов; клиенты API не могут передать команды, скрипты, SQL или другие образы.
• Право управлять политиками резервного копирования базы, nodes:backups:execute для ноды-исполнителя и права на хранилище, перечисленные в разделе Права доступа. Встроенная группа operator включает не все из них.

Создайте политику резервного копирования

1. Откройте базу данных и перейдите на вкладку Backups.
2. Выберите Add policy.
3. В разделе Destination выберите подключение Storage, Bucket и Prefix. Префикс обязателен и по умолчанию равен database-backups; каждый запуск записывает свои артефакты и manifest.json в <prefix>/<run ID>/. Для ClickHouse добавьте хранилище S3 staging, если движок не может записывать в место назначения напрямую; см. Как копируется каждый движок.
4. В разделе Execution выберите Storage node, на которой будут выполняться задания.
5. В разделе Schedule оставьте запуск вручную или укажите числовое выражение Cron из пяти полей и Timezone. Console предлагает 0 2 * * * в часовом поясе вашего браузера.
6. В разделе Retention задайте Completed backups to keep. Более старые завершённые копии удаляются из места назначения.
7. В разделе Resource limits измените рабочее пространство, тайм-аут, CPU и память задания, если значения по умолчанию не подходят для базы.
8. Сохраните политику, затем один раз выполните Run now и дождитесь завершения запуска, прежде чем полагаться на расписание.

В Console также можно включить или отключить расписание политики и удалить политику. Остальные параметры политики изменяются через API.

Параметр	Допустимый диапазон	По умолчанию
Completed backups to keep	1–365	7
Workspace (GiB)	1–1024	20
Timeout (seconds)	60–86 400	3 600
CPU cores	1–32	1
Memory (MiB)	128–262 144	1 024

Как копируется каждый движок

Движок	Резервное копирование	Восстановление
PostgreSQL	Штатный дамп в пользовательском формате	В пустую базу данных
Redis	Штатный снимок RDB	Проверенный RDB загружается во временный Redis, полностью реплицируется в пустую цель и затем отключается. Внешней цели нужны права на репликацию и изменение конфигурации, а также возможность подключиться обратно к исполнителю
ClickHouse	Штатные BACKUP и RESTORE через S3	В пустую цель тем же путём через S3

ClickHouse записывает резервную копию через S3, поэтому самому серверу ClickHouse нужен доступ к адресу S3. Для приватного управляемого места назначения S3 без промежуточного хранилища источником должна быть управляемая база ClickHouse, а её нода хранилища — исполнителем. Внешнему серверу ClickHouse нужно промежуточное подключение S3, доступное ему напрямую. Для мест назначения FTP, FTPS и SFTP также нужны промежуточное подключение S3 и бакет; Opfield переносит артефакты между промежуточным и конечным хранилищем, сохраняет штатную структуру каталогов ClickHouse и затем удаляет промежуточную копию.

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

Запуски, очередь и расписание

Нода хранилища, выбранная исполнителем, выполняет одно резервное копирование или восстановление за раз. Запуск, принятый во время занятости ноды, остаётся в статусе Queued и начинается в порядке создания, когда нода освобождается; запуск в очереди можно отменить сразу. Отмена выполняющегося задания ждёт подтверждения от исполнителя; Force cancel завершает запуск без такого подтверждения, а Opfield продолжает согласовывать задание в фоне. Запуск, превысивший тайм-аут более чем на 15 минут, помечается как неудачный. У политики может быть не больше одного резервного копирования в очереди или в работе: Run now, пока копирование этой политики активно, отклоняется с 409 BACKUP_ALREADY_RUNNING и указанием активного запуска, а запуск по расписанию пропускается с ошибкой в политике. Точно так же в очереди или в работе может быть только одно восстановление в новую управляемую базу данных с одним и тем же именем; следующее отклоняется с 409 BACKUP_RESTORE_ALREADY_RUNNING. Оба правила соблюдает сама база данных Opfield, поэтому они действуют и при нескольких процессах Opfield. Если при обновлении Opfield до 2.11 у политики было несколько активных копирований, работу продолжило одно — выполняющееся, а не ожидающее в очереди, иначе самое новое, — а остальные помечены как неудачные и отменены; см. «Конфликты, разрешённые при обновлении до 2.11». Если в запланированное время Opfield не работал, он выполняет только последний пропущенный запуск за последние 24 часа, а не всю накопившуюся очередь.

Резервная копия считается завершённой только после проверки её манифеста. Манифест фиксирует идентичность источника, версию сервера, размеры и контрольные суммы SHA-256 артефактов; одной успешной выгрузки недостаточно. Ограничение числа копий сохраняет самые новые завершённые копии каждой политики и удаляет только более старые артефакты под префиксом политики, пропуская артефакты, которые использует восстановление.

Запуски по расписанию и удаление старых копий выполняются от имени владельца политики — пользователя, который последним сохранил политику, — и Opfield перепроверяет его права перед каждым запуском. Если владелец теряет доступ или удалён, запуски по расписанию пропускаются, а политика показывает ошибку, пока пользователь с нужными правами не сохранит политику и не станет её владельцем.

Восстановите резервную копию

1. На вкладке Backups откройте Backup history и выберите Restore для завершённого запуска.
2. Выберите Storage node, на которой выполнится восстановление, укажите имя новой управляемой базы данных и при необходимости выберите для неё папку баз данных. Если движок использует имя базы данных, можно изменить имя целевой базы.
3. Дождитесь завершения восстановления и проверьте новую базу запросами приложения, прежде чем переключать на неё клиентов.

Восстановление из Console создаёт новую управляемую базу данных на ноде хранилища, выбранной исполнителем, и никогда не перезаписывает существующие базы. Для этого нужно право создавать базы данных на этой ноде или в выбранной папке. Opfield использует самую новую версию из каталога с той же мажорной версией движка, что и у резервной копии, и завершает восстановление ошибкой, если такой версии нет. Новая база получает 1 CPU, 1024 МБ памяти (2048 МБ для ClickHouse), без swap и публикации TCP, с включённым TLS и хранилищем размером 20 ГБ или трёхкратный размер резервной копии — в зависимости от того, что больше; при необходимости затем измените размер. Само задание восстановления использует ограничения ресурсов по умолчанию — 20 ГиБ рабочего пространства и тайм-аут в один час, — а не ограничения политики; через API их можно переопределить.

Через API можно также восстановить резервную копию управляемой или внешней базы в существующее пустое подключение к базе данных того же движка, которое не является источником. Для этого нужны право на восстановление для базы, которой принадлежит резервная копия, и право на изменение целевой базы. Штатная предварительная проверка подтверждает, что цель пуста, и Opfield проверяет это ещё раз непосредственно перед восстановлением. Восстановление в подключение, из которого сделана резервная копия, отклоняется ещё до создания запуска с кодом 409 BACKUP_RESTORE_SOURCE_REJECTED; восстановите копию в другое пустое подключение или в новую управляемую базу данных.

Права доступа

Скоуп	Что разрешает
databases:backups:view	Просмотр политик и истории запусков
databases:backups:manage	Создание, изменение и удаление политик и удаление записей истории запусков
databases:backups:run	Запуск и отмена запусков
databases:backups:restore	Восстановление завершённой резервной копии
nodes:backups:execute	Использование ноды хранилища как исполнителя

Хранилище назначения и промежуточное хранилище проверяются отдельно. Для создания или изменения политики, запуска и отмены резервного копирования, удаления старых копий, удаления файлов резервных копий и восстановления нужен только storage:credentials:use на место назначения, а также на промежуточное хранилище, если оно используется. Это право позволяет исполнителю резервного копирования получить сохранённые учётные данные хранилища, не показывая их пользователю, и не открывает просмотр объектов; storage:credentials:reveal включает его. Скоупы storage:objects:* не нужны.

Встроенные группы admin и operator включают storage:credentials:use. Группа operator может создавать политики и запускать резервное копирование, но не включает databases:backups:restore. API-токены и разрешения OAuth с ограниченными скоупами сохраняют свои более узкие полномочия. См. справочник скоупов.

Правила удаления и хранения

Удаление политики останавливает будущие запуски. Чтобы удалить завершённый запуск из Backup history, выберите, что делать с его файлами в хранилище:

• Запуск без оставшихся файлов, например после удаления старых копий, удаляется сразу.
• Delete backup and files удаляет файлы резервной копии, а затем запись истории; восстановить такую копию больше нельзя. Для этого нужен storage:credentials:use на место назначения. Если хранилище отказывает в удалении, запись сохраняется, причина показывается, и можно повторить попытку или вместо этого забыть запись.
• Forget entry удаляет только запись истории и оставляет файлы в хранилище; журнал аудита фиксирует их бакет и префикс.

Через API DELETE /api/databases/{id}/backups/runs/{runId} принимает artifacts=delete или artifacts=forget. Без этого параметра запуск, файлы которого ещё существуют, отклоняется с кодом BACKUP_HISTORY_HAS_ARTIFACTS (409); неудачное удаление файлов возвращает BACKUP_ARTIFACT_DELETE_FAILED (502) и сохраняет запись; запуск, файлы которого ещё читает восстановление, возвращает BACKUP_ARTIFACT_IN_USE. Инструмент резервного копирования в AI Workspace и MCP принимает тот же выбор в config.artifacts. Запуски в очереди и выполняющиеся запуски удалить нельзя.

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

Базу данных нельзя удалить, пока выполняется её резервное копирование или восстановление. При удалении базы данных её политики отключаются и удаляются, а история резервного копирования сохраняется. Шифрование, сроки хранения и контроль доступа на стороне места назначения планируйте в самой системе хранения и храните хотя бы одну копию вне зоны отказа базы данных и её ноды хранилища.

Регулярно проверяйте восстановление на отдельной цели. Резервная копия, которую ни разу не восстанавливали, не доказывает возможность восстановления; см. проверку восстановления.