Концепции резервного копирования

YDB обеспечивает сохранность данных при аппаратных сбоях за счёт репликации и отказоустойчивости. Однако репликация не защищает от логических ошибок: случайный DROP TABLE, ошибочный массовый UPDATE или DELETE будут воспроизведены на все реплики. Для защиты от таких сценариев необходимо резервное копирование — отдельная копия данных, из которой можно восстановиться.

Полное резервное копирование

Полная резервная копия — это снимок данных таблиц на определённый момент времени. YDB предоставляет несколько способов создания полных резервных копий, от простых к более функциональным.

Копирование таблиц внутри кластера

Самый простой способ — создать копию таблицы (или нескольких таблиц) внутри того же кластера с помощью команды ydb tools copy. Копия создаётся атомарно из согласованного снимка и использует механизм копирования при записи, поэтому операция выполняется быстро.

Подходит для:

• быстрого создания «страховочной» копии перед опасной операцией;
• клонирования данных для тестирования.

Дамп в файловую систему

Команды ydb tools dump и ydb tools restore позволяют выгрузить данные в локальную файловую систему и восстановить их обратно.

Подходит для:

• локальной разработки и тестирования;
• небольших баз данных;
• создания копии на отдельном носителе.

Экспорт в S3-совместимое хранилище

Команды ydb export s3 и ydb import s3 позволяют выгружать и загружать данные во внешнее S3-совместимое хранилище.

Подходит для:

• аварийного восстановления (данные хранятся вне кластера);
• миграции данных между кластерами;
• долгосрочного архивирования.

Экспорт в NFS

Команды ydb export nfs и ydb import nfs позволяют выгружать и загружать данные в сетевую файловую систему (NFS), смонтированную на всех хостах кластера YDB. В отличие от дампа в файловую систему, выгрузка выполняется на стороне сервера и не требует передачи данных через CLI.

Подходит для:

• аварийного восстановления (данные хранятся вне кластера);
• миграции данных между кластерами;
• долгосрочного архивирования.

Подробнее про настройку NFS для резервного копирования и восстановления см. рецепт Резервное копирование и восстановление через NFS.

Инкрементальное резервное копирование

При работе с большими таблицами повторное создание полных резервных копий может быть слишком затратным. Инкрементальное резервное копирование решает эту задачу: после начальной полной копии каждый последующий инкремент захватывает только изменения (вставки, обновления, удаления), произошедшие с момента предыдущей резервной копии.

Инкрементальные резервные копии организованы в цепочку:

Полная копия → Инкремент₁ → Инкремент₂ → ... → Инкрементₙ

Для восстановления необходима вся цепочка: сначала применяется полная копия, затем последовательно все инкременты. Восстановление выполняется к состоянию на момент последнего инкремента в цепочке.

Инкрементальное резервное копирование реализуется с помощью коллекций резервных копий.

Резервное копирование системных таблеток

Механизм резервного копирования системных таблеток обеспечивает инкрементальное копирование метаданных кластера — таких как Hive, BSController и SchemeShard — на локальную файловую систему хостов кластера.

Этот механизм используют для восстановления метаданных кластера, когда восстановление из резервных копий баз данных технически возможно, но не подходит по времени или объёму работ. Типичный сценарий — совокупный объём баз данных в кластере велик из‑за их количества, размера отдельных баз или сочетания обоих факторов; полный import/restore всех данных в новый кластер в таком случае приводит к длительному простою. В этом сценарии можно восстановить системные таблетки и вернуть кластер к работоспособному состоянию, не выполняя массовое восстановление пользовательских данных на новом кластере.

Если объём баз данных позволяет выполнить штатное восстановление, используйте в первую очередь export/import или dump/restore. Резервное копирование системных таблеток следует применять как специальный механизм для ситуаций, когда нужно восстановить именно метаданные кластера и сократить объём восстановительных операций.

Принцип работы

Резервное копирование состоит из двух компонентов:

• Снимок состояния (snapshot) — при каждом запуске таблетка сканирует все свои таблицы и записывает свое полное состояние в резервную копию, включая схему данных. Сканирование выполняется на основе снимка состояния и не блокирует работу таблетки.
• Журнал изменений (changelog) — при каждом изменении данных или схемы таблетка асинхронно записывает изменение в журнал параллельно с записью в распределённое хранилище. Когда размер журнала превышает размер снимка состояния, таблетка автоматически делает новый снимок.

Резервные копии создаются локально на хосте, где в данный момент работает таблетка. Поэтому наиболее актуальная копия находится на том хосте, где таблетка работала непосредственно перед сбоем.

Количество хранимых резервных копий на хосте ограничено в конфигурации. После успешного снятия снапшота самая старая копия автоматически удаляется при превышении лимита. Незавершённые копии (без полностью записанного снапшота) удаляются при создании новой резервной копии.

Сравнение подходов

См. также

• Резервное копирование и восстановление — практическое руководство
• Коллекции резервных копий — архитектура и ограничения
• Рецепты для резервного копирования системных таблеток — включение и восстановление
• Резервное копирование и восстановление — практическое руководство
• Справочник export/import — команды CLI
• Справочник YQL:
  • CREATE BACKUP COLLECTION
  • BACKUP
  • RESTORE
  • DROP BACKUP COLLECTION