Восстановить базу из копии

POST /v1/infra/servers/:id/db/restore

Заменяет SQLite-файл приложения содержимым завершённой копии базы. Восстановление выполняется в фоновом режиме, а перед заменой платформа сохраняет защитную копию текущего файла.

Параметры

Поля запроса (body)

Других полей тело не принимает, размер тела — до 4 КиБ.

Примеры

curl — личный ключ

curl -X POST "https://vibecode.bitrix24.tech/v1/infra/servers/APP_ID/db/restore" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"backupId":"BACKUP_ID"}'

curl — OAuth-приложение

curl -X POST "https://vibecode.bitrix24.tech/v1/infra/servers/APP_ID/db/restore" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"backupId":"BACKUP_ID"}'

JavaScript — личный ключ

const res = await fetch(
  `https://vibecode.bitrix24.tech/v1/infra/servers/${appId}/db/restore`,
  {
    method: 'POST',
    headers: { 'X-Api-Key': 'YOUR_API_KEY', 'Content-Type': 'application/json' },
    body: JSON.stringify({ backupId }),
  }
)
const { success, data, error } = await res.json()
if (!success) throw new Error(`${error.code}: ${error.message}`)
// Ход восстановления — в data.restore ответа GET /db/backups с тем же restoreId
console.log('Восстановление принято:', data.restoreId)

JavaScript — OAuth-приложение

const res = await fetch(
  `https://vibecode.bitrix24.tech/v1/infra/servers/${appId}/db/restore`,
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ backupId }),
  }
)
const { success, data, error } = await res.json()
if (!success) throw new Error(`${error.code}: ${error.message}`)

Поля ответа

HTTP-статус успешного ответа — 202 Accepted: восстановление принято в очередь, база ещё не заменена.

Пример ответа

{
  "success": true,
  "data": {
    "restoreId": "cm2r7x4k10003qv8n5d2b6w1z",
    "backupId": "9e4d2c1b-6a3f-4b8e-a7d5-0c1f2e3d4b5a",
    "targetAppId": "5c0e8f2a-3d1b-4a7e-9f60-2b8c4d1e7a93",
    "status": "QUEUED"
  }
}

Пример ответа при ошибке

404 — копии с таким backupId нет:

{
  "success": false,
  "error": {
    "code": "NOT_FOUND",
    "message": "Server not found"
  }
}

Ошибки

Полный список общих ошибок API — Ошибки.

Известные особенности

Ход восстановления. Ответ 202 означает только приём запроса. Состояние читайте в data.restore ответа GET /db/backups, сверяя restoreId. На тестовом приложении восстановление заняло 12 минут и прошло фазы по порядку: VALIDATE, PREPARE, PRE_CHANGE, STAGE, STOPPING, SWAPPING, VERIFY, STARTING, CLEANUP. После завершения данные базы совпали с копией. Восстановление остаётся в статусе QUEUED, пока на платформе выполняется другое восстановление или на том же хосте идёт копирование либо запись в базу.

База занята до конца восстановления. Пока восстановление не завершено, запись в базу этого приложения и новые копии отвечают 409 APP_DB_BUSY. Чтение тоже получает 409 APP_DB_BUSY: так ответило чтение сразу после запуска восстановления на живом вызове, а с фазы STOPPING чтение закрыто до конца восстановления.

Перезапуск приложения. Работающее приложение на фазе STOPPING останавливается и на фазе STARTING запускается снова. Приложение, которое было остановлено до восстановления, остаётся остановленным.

Защитная копия перед заменой. На фазе PRE_CHANGE платформа сохраняет текущий файл копией с triggerType равным PRE_CHANGE — она видна в списке копий. Чтобы отменить восстановление, восстановите базу из этой копии. Если защитную копию создать не удалось, восстановление завершается со статусом FAILED, файл не заменяется. Если файла file у приложения ещё нет, защитная копия не создаётся.

Сбой во время замены. Сбой на фазах VALIDATE, PREPARE и PRE_CHANGE файл не трогает. Сбой на фазах от STAGE до VERIFY возвращает исходный файл через фазу ROLLBACK. В обоих случаях восстановление завершается со статусом FAILED и errorCode равным APP_DB_RESTORE_FAILED. Сбой на фазе STARTING и три неудачные попытки ROLLBACK переводят восстановление в фазу RECOVERY_REQUIRED со статусом RUNNING без автоматического отката: с фазы STARTING приложение уже работает с восстановленной базой. Такое восстановление ждёт службы поддержки, а база приложения до её вмешательства остаётся занятой.

Условия доступа к базе и правила хранения копий — Когда база доступна и Копии и их хранение.

Смотрите также

• Получить список копий базы
• Создать копию базы
• Защитные копии перед записью
• База данных приложения