Изнанка бэкапов YDB: что остаётся за кадром / Хабр

Решил собрать нюансы создания резервных копий и восстановления таблиц в YDB. Это не замена документации, а раскрытие деталей, которые не очевидны для тех, кто начинает работать с этой базой данных.

В этой заметке разберём три сценария: нативные бекапы средствами облака, дамп в локальную файловую систему и экспорт/импорт в S3.

1. Нативные бекапы Yandex Cloud (Managed Service)

Самый простой способ, если вы используете Managed YDB. Бекапы хранятся внутри инфраструктуры Яндекса и управляются через консоль или CLI.

CLI для нативных бекапов

Убедитесь, что CLI смотрит в нужную папку облака.

# Проверяем текущий конфиг
yc config list

# Переключаем на нужный каталог
yc config set folder-id <FOLDER_ID>

# Проверяем список баз
yc ydb database list

Создание резервной копии

Команда запускает создание бекапа для базы production-db.

yc ydb database backup production-db \
  --storage-class standard \
  --async

Флаг --async нужен, чтобы не блокировать терминал. Получить статус и ID бекапа можно командой:

yc ydb backup list --folder-id <FOLDER_ID>

Стратегии восстановления

Важный нюанс: В YDB нет команды "откатить всё назад одной кнопкой". Нативные бекапы можно восстановить только в новую базу данных или в отдельный каталог внутри текущей. Заменить текущую базу данных "на месте" не получится.

Поэтому существует несколько стратегий отката изменений. Рассмотрим основные:

Стратегия А: Параллельное восстановление (Side-by-side)

Суть: Мы восстанавливаем данные из бэкапа в новую директорию рядом с рабочей версией (внутри той же базы данных).

Плюсы: Нулевой риск потерять текущие данные, минимальный простой (только на переключение конфига), возможность сравнить старую и новую версии.

Эта стратегия рекомендуется по умолчанию и собственно её Яндекс и продвигает в документации.

Алгоритм:

Восстанавливаем бэкап в папку restore_v1:

yc ydb database restore production-db \
  --backup-id <BACKUP_ID> \
  --target-path restore_v1 \
  --async

Меняем в конфиге приложения префикс таблиц (Table Prefix) на /restore_v1.
Перезапускаем приложение. Старую папку можно удалить позже, когда убедитесь, что всё работает.

Стратегия Б: Полная замена (Replacement)

Суть: Полное уничтожение старых данных и заливка новых из бэкапа.

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

Важно: Не выполняйте yc ydb database delete! Это удалит сам инстанс базы данных. При создании новой базы изменится endpoint (адрес подключения), и придётся менять конфиги во всех приложениях.

Как правильно:

Вручную или скриптом удалите все таблицы внутри базы (DROP TABLE).
Запустите восстановление в корень базы (без флага --target-path или с указанием /).
Теперь произойдёт полная замена на резервную копию.

Общий шаг для обеих стратегий — перевести приложение в режим чтения. Например, через фича-флаг, если он реализован, или показать экран технических работ. Это самый простой, но действенный подход, чтобы новые данные не записывались во время восстановления.

2. Дамп на локальную машину

Используем нативный CLI ydb (не путать с yc). Этот способ хорош для разработки и для баз небольшого размера, когда копию можно хранить локально.

Аутентификация

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

export YDB_TOKEN=$(yc iam create-token)

Экспорт и восстановление

Экспорт таблицы:

ydb \
  --endpoint grpcs://ydb.serverless.yandexcloud.net:2135 \
  --database /ru-central1/<FOLDER_ID>/<DB_ID> \
  tools dump \
  -p your_table \
  -o ./backup_folder

Восстановление:

ydb \
  --endpoint grpcs://ydb.serverless.yandexcloud.net:2135 \
  --database /ru-central1/<FOLDER_ID>/<DB_ID> \
  tools restore \
  -p my_restore_folder \
  -i ./backup_folder \
  --restore-acl=0

Команда tools dump поддерживает несколько режимов работы:

Указать таблицу: -p your_table — выгрузится только указанная таблица.
Указать папку: -p my_folder — выгрузится всё содержимое папки рекурсивно (все таблицы внутри).
Не указывать путь: По умолчанию выгружается вся база целиком (от корня /).

Нюансы локального восстановления (tools restore)
Эта команда работает в режиме Upsert: она обновляет существующие записи и добавляет новые, но НЕ удаляет записи, которых нет в бэкапе. Для чистого восстановления всегда восстанавливайте в пустую папку или предварительно удаляйте таблицы.

3. Бэкап в S3 (Object Storage)

Хотя нативные бекапы достаточно гибкие, дополнительные копии в S3 могут быть полезны для долгосрочного хранения или миграции между облаками.

Подготовка

Не забудьте указать токен доступа к базе:

export YDB_TOKEN=$(yc iam create-token)

Далее нужно выдать сервисному аккаунту доступ к бакету, в который будут сохраняться бэкапы. К уже существующей роли ydb.admin добавляем роль для Object Storage:

yc resource-manager folder add-access-binding \
  --id <FOLDER_ID \
  --role storage.editor \
  --service-account-id <SA_ID>

После этого можно создать статические ключи доступа для сервисного аккаунта.
Полученные access key и secret key будут использоваться в параметрах --access-key и --secret-key.

Команды экспорта/импорта

Экспорт в S3 (асинхронно):

ydb \
  --endpoint grpcs://ydb.serverless.yandexcloud.net:2135 \
  --database /ru-central1/<FOLDER_ID>/<DB_ID> \
  export s3 \
  --s3-endpoint storage.yandexcloud.net \
  --bucket your-ydb-db \
  --access-key <ACCESS_KEY> \
  --secret-key <SECRET_KEY> \
  --item src=your_table,dst=backups/your_table_v1

Импорт из S3:

ydb \
  --endpoint grpcs://ydb.serverless.yandexcloud.net:2135 \
  --database /ru-central1/<FOLDER_ID>/<DB_ID> \
  import s3 \
  --s3-endpoint storage.yandexcloud.net \
  --bucket your-ydb-db \
  --access-key <ACCESS_KEY> \
  --secret-key <SECRET_KEY> \
  --item src=backups/your_table_v1,dst=restored/your_table

Можно передать несколько флагов --item для разных таблиц. Если указать --item src=., то будут сохранены или восстановлены все таблицы в текущей директории.

Решение проблемы SSL сертификата

При работе с S3 через CLI может возникнуть ошибка curlCode: 60:

ListObjectKeys error: curlCode: 60, SSL peer certificate or SSH remote key was not OK

Это происходит потому, что CLI не доверяет сертификату Яндекса.

В теории можно отключить проверку SSL (что небезопасно), но правильнее явно указать проверенный сертификат.

Рабочее решение:

Скачиваем универсальный бандл корневых сертификатов от Mozilla/curl, которому доверяют все системы:
```
curl -o ~/cacert.pem https://curl.se/ca/cacert.pem
```
Указываем путь к нему через переменную SSL_CERT_FILE (именно её читает libcurl):
```
export SSL_CERT_FILE=~/cacert.pem
```

После этого команды export s3 и import s3 будут работать без ошибок SSL.

Изнанка бэкапов YDB: что остаётся за кадром