Коллекция резервных копий

Коллекция резервных копий организует полные и инкрементальные резервные копии выбранных строковых таблиц в управляемые цепочки. Она позволяет восстановить данные к состоянию самой поздней резервной копии в цепочке, обеспечивая защиту от случайной потери данных — ошибочных удалений или изменений.

Примечание

Практические инструкции по созданию и управлению коллекциями резервных копий см. в разделе Коллекции резервных копий документа «Резервное копирование и восстановление».

Обзор

Коллекции резервных копий решают типичные задачи резервного копирования для производственных нагрузок:

  • Эффективность хранения: Инкрементальные резервные копии захватывают только изменения с момента предыдущей резервной копии, значительно сокращая требования к хранилищу по сравнению с множеством полных резервных копий.
  • Согласованное восстановление: Все таблицы в коллекции создаются из одного глобального снимка, обеспечивая ссылочную целостность между таблицами при восстановлении.
  • Восстановление по цепочке: Восстановление к состоянию самой поздней резервной копии в актуальной цепочке — см. RESTORE.

Для сравнения с другими методами резервного копирования (export/import, dump/restore) см. Концепции резервного копирования.

Ключевые концепции

Эти термины необходимы для понимания коллекций резервных копий. Подробные определения см. в глоссарии.

  • Полная резервная копия: Полный снимок всех данных в коллекции на определённый момент времени. Служит основой для последующих инкрементальных резервных копий.
  • Инкрементальная резервная копия: Захватывает только изменения (вставки, обновления, удаления) с момента предыдущей резервной копии. Требует всей цепочки резервных копий для восстановления.
  • Цепочка резервных копий: Упорядоченная последовательность, начинающаяся с полной резервной копии, за которой следует ноль или более инкрементальных резервных копий.

Ограничения

Перед использованием коллекций резервных копий учтите эти ограничения:

  • Только строковые таблицы: Колоночные таблицы не поддерживаются.
  • Одна коллекция на таблицу: Таблица может принадлежать только одной коллекции резервных копий. Чтобы включить таблицу в другую коллекцию, выполните DROP BACKUP COLLECTION для текущей коллекции и создайте новую с нужным составом таблиц.
  • Неизменяемый состав: После создания список таблиц в коллекции нельзя изменить. Для добавления новых таблиц создайте новую коллекцию со всеми нужными таблицами.
  • Нет частичного восстановления: Нельзя восстановить отдельные таблицы из коллекции; восстанавливается вся коллекция целиком.
  • Внешнее планирование: YDB не предоставляет встроенного планирования резервного копирования. Используйте внешние инструменты, такие как cron, для автоматизации.

Архитектура

Коллекции резервных копий используют механизм копирования при записи в сочетании с потоками изменений для эффективных инкрементальных резервных копий. В этом разделе объясняется, как компоненты работают вместе.

Как работают коллекции резервных копий

Следующая диаграмма иллюстрирует процесс резервного копирования:

Создание коллекции определяет, какие таблицы включить, и создаёт схемный объект. Это быстрая операция только с метаданными.

Полная резервная копия создаёт согласованный снимок всех таблиц в коллекции. Ключевые характеристики:

  • Использует глобальный снимок, который обеспечивает согласованность всех таблиц в коллекции.
  • Создаёт потоки изменений для каждой таблицы для отслеживания последующих модификаций.
  • Использует копирование при записи: Резервная копия создаётся быстро путём ссылки на существующие данные; фактическое копирование данных происходит только при модификации исходных данных.

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

  • Использует распределённую транзакцию для чтения потоков изменений из всех таблиц в согласованной точке, обеспечивая ссылочную целостность всей коллекции.
  • Считывает накопленные изменения из потоков изменений, созданных при выполнении полной резервной копии и накапливающих изменения с момента предыдущей резервной копии (полной или инкрементальной).
  • Записывает все модификации: вставки, обновления и удаления (в том числе в виде записей об удалении).
  • Сохраняет данные потоков изменений в таблицы инкрементальной резервной копии.

Важно

Изменения схемы (ALTER TABLE) таблиц в коллекции резервных копий не отслеживаются инкрементальными резервными копиями. Если вам нужно изменить схему таблицы с резервной копией, создайте новую полную резервную копию после изменения схемы, чтобы цепочка резервных копий отражала новую структуру.

Примечание

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

Хранение

Коллекции резервных копий хранятся в кластере YDB в выделенной структуре каталогов:

/Root/database/.backups/collections/
├── my_collection/
│   ├── 20250821141425Z_full/
│   │   ├── table_1/
│   │   └── table_2/
│   └── 20250821151519Z_incremental/
│       ├── table_1/
│       └── table_2/

Примечание

Каталог .backups создаётся автоматически при создании первой коллекции резервных копий и управляется системой. После его создания вы можете управлять таблицами резервных копий внутри него (например, при экспорте или импорте резервных копий).

Кластерное хранилище

По умолчанию резервные копии хранятся в кластере. Резервные копии в кластере предназначены для восстановления после логических ошибок, таких как случайный DROP TABLE, TRUNCATE TABLE или ошибочные изменения данных. Преимущества:

  • Быстрые операции резервного копирования и восстановления.
  • Интегрированные механизмы безопасности.
  • Не требуется внешняя инфраструктура.

Важно

Резервные копии в кластере находятся в той же зоне отказа, что и защищаемые данные. Если кластер выйдет из строя с превышением его отказоустойчивости (например, полная потеря кластера или катастрофические события в дата-центре), и данные, и резервные копии могут быть потеряны. Для защиты от таких сценариев используйте внешнее хранилище.

Внешнее хранилище

Для аварийного восстановления и защиты от отказов всего кластера регулярно экспортируйте коллекции резервных копий во внешнее хранилище (S3-совместимое хранилище или файловую систему) с помощью операций export/import.

Для экспорта резервных копий во внешнее хранилище используйте YDB CLI:

Каждую резервную копию в цепочке необходимо экспортировать отдельно. Сохраняйте порядок цепочки при экспорте/импорте для успешного восстановления.

Фоновые операции

Все операции резервного копирования и восстановления выполняются асинхронно, позволяя продолжать обычные операции с базой данных. Отслеживайте прогресс с помощью ydb operation list incbackup.

Восстановление из резервных копий

Восстановление возвращает данные к состоянию самой поздней резервной копии в цепочке, находящейся в кластере. Чтобы восстановиться к более раннему состоянию, импортируйте из внешнего хранилища только нужный префикс цепочки — см. Импорт и восстановление.

Процесс восстановления

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

  2. Выполнение восстановления: Выполните RESTORE collection_name для восстановления всех таблиц из коллекции резервных копий. Система применяет полную резервную копию и все инкрементальные резервные копии последовательно для достижения последней точки резервного копирования.

Важно

Операция восстановления завершится с ошибкой, если хотя бы одна из восстанавливаемых таблиц уже существует по тому же пути. Переименуйте или удалите конфликтующие таблицы перед восстановлением.

Все таблицы в коллекции восстанавливаются к одной и той же точке во времени: данные из разных таблиц будут взаимно согласованы.

Примечание

Во время операции восстановления целевые таблицы недоступны для модификаций. Частично восстановленные данные могут быть видимы для читающих нагрузок. Планируйте восстановление на окно обслуживания или отключайте доступ приложений к затронутым таблицам до завершения операции.

См. также