Полное резервное копирование и восстановление данных

Павел Семёнов

Contents

Базовый сценарий резервного копирования и восстановления
- Создание бэкапа
- Восстановление из бэкапа
Настройка расположения бэкапа
Настройка структуры бэкапа
Настройка сжатия бэкапов
Параллельное резервное копирование и восстановление
Вспомогательные данные в бэкапе
Мониторинг

Этот раздел описывает, как выполнить резервное копирование и восстановление базы данных Greengage DB, а также как изменить настройки резервного копирования и проверить результат операции.

ПРИМЕЧАНИЕ

Все команды gpbackup и gprestore необходимо выполнять на мастер-хосте от имени пользователя gpadmin.

Полный бэкап базы данных включает все пользовательские данные, метаданные базы данных и глобальные объекты всего кластера. Чтобы создать полный бэкап, используйте утилиту gpbackup, указав имя целевой базы данных в опции --dbname:

$ gpbackup --dbname marketplace

После успешного завершения операции в выводе появится сообщение:

[INFO]:-Backup completed successfully

Также в выводе содержится метка времени бэкапа, которая однозначно идентифицирует его и используется для последующего восстановления:

[INFO]:-Backup Timestamp = 20251006063113

Эта команда создает файлы бэкапа на всех хостах кластера:

На мастер-хосте: файлы конфигурации бэкапа, метаданные базы данных (DDL) и общая информация о бэкапе.
На сегмент-хостах: сжатые файлы с данными таблиц, которые хранятся на сегментах этого хоста, каждая таблица в отдельном файле.

Каждый бэкап представляет собой распределенную иерархию каталогов, которая отражает внутреннее устройство файлов Greengage DB и включает подкаталоги для конфигурации, метаданных и данных. Такая структура позволяет выполнять полное и частичное (выборочное) восстановление в один поток или параллельно с помощью gprestore.

Чтобы убедиться, что операция резервного копирования завершена корректно, проверьте отчет об операции и логи gpbackup, созданные на мастер-хосте.

Чтобы восстановить базу данных из бэкапа, используйте утилиту gprestore с указанием метки времени бэкапа в опции --timestamp:

$ gprestore --timestamp 20251006063113

ВАЖНО

gprestore не перезаписывает существующие таблицы и другие пользовательские объекты в целевой базе данных. Чтобы восстановить данные в уже существующую базу, необходимо предварительно удалить или очистить целевые таблицы. Для автоматизации этого процесса можно использовать опцию --truncate-table:

$ gprestore --timestamp 20251006063113 --truncate-table --data-only

После успешного восстановления в выводе появится сообщение:

[INFO]:-Restore completed successfully

Можно также восстановить бэкап в кластер, где целевая база данных еще не существует, с помощью опции --create-db:

$ gprestore --timestamp 20251006063113 --create-db

Такой вызов создает новую базу данных на основе встроенного шаблона базы данных template0 и заполняет ее восстановленными объектами.

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

РЕКОМЕНДАЦИЯ

Чтобы узнать временные метки существующих бэкапов, выведите содержимое каталога с бэкапами:

$ ls $MASTER_DATA_DIRECTORY/backups/

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

Затем выведите содержимое выбранного подкаталога, чтобы увидеть доступные временные метки:

$ ls $MASTER_DATA_DIRECTORY/backups/20251006/

По умолчанию gpbackup сохраняет файлы бэкапа в каталоге $MASTER_DATA_DIRECTORY/backups на мастер-хосте и в соответствующих каталогах на сегмент-хостах. Вы можете изменить это расположение с помощью опции --backup-dir:

$ gpbackup --dbname marketplace --backup-dir /home/gpadmin/backups

ВАЖНО

Пользователь gpadmin должен иметь права на запись в указанный каталог на всех хостах кластера, так как каждый процесс сегмента записывает собственные файлы бэкапа локально.

При вызове с --backup-dir gpbackup создает структуру каталогов бэкапа внутри указанного каталога. На каждом хосте создаются подкаталоги с именами gpseg<N> для всех его сегментов. Внутри каждого каталога сегмента бэкапы организованы по дате и временной метке. Например, приведенная выше команда создаст следующие каталоги:

Мастер-хост:

/home/gpadmin/backups/gpseg-1/backups/20251006/20251006073432/

Сегмент-хост с сегментами 0 и 1:

/home/gpadmin/backups/gpseg0/backups/20251006/20251006073432/
/home/gpadmin/backups/gpseg1/backups/20251006/20251006073432/

Сегмент-хост с сегментами 2 и 3:

/home/gpadmin/backups/gpseg2/backups/20251006/20251006073432/
/home/gpadmin/backups/gpseg3/backups/20251006/20251006073432/

Чтобы восстановить базу данных из бэкапа с нестандартным расположением, укажите путь к нему в опции --backup-dir утилиты gprestore:

$ gprestore --timestamp 20251006073432 --backup-dir /home/gpadmin/backups/

При восстановлении gprestore предполагает ту же структуру каталогов, что была создана gpbackup. Если файлы были перемещены или скопированы в другой кластер, убедитесь, что структура и права доступа сохранены.

Физическая структура файлов бэкапа определяет их расположение на диске и формат. gpbackup предоставляет параметры для управления этой структурой в зависимости от среды и выбранной стратегии хранения:

Структура по умолчанию

По умолчанию gpbackup создает отдельный каталог для каждого бэкапа в каталоге данных каждого сегмента (или в каталоге, указанном в --backup-dir). Каждая таблица сохраняется в отдельном сжатом файле данных.
--single-backup-dir

При использовании этой опции все файлы бэкапов на каждом хосте сохраняются в одном каталоге вместо отдельных подкаталогов gpseg<N> для каждого сегмента. Каталог должен быть указан в --backup-dir. Это упрощает управление файлами при миграции или изменении числа сегментов кластера, так как можно скопировать все файлы из одного каталога вместо нескольких. Однако бэкапы с такой структурой могут выполняться немного медленнее из-за конкуренции при записи в один каталог.
```
$ gpbackup --dbname marketplace --single-backup-dir --backup-dir /home/gpadmin/backups
```
--single-data-file

Эта опция объединяет данные всех таблиц одного сегмента в один файл вместо отдельных файлов на каждую таблицу. Это уменьшает общее количество файлов, что может быть полезно в файловых системах с ограничениями по числу файлов. Однако это делает невозможным параллельное восстановление таблиц, поэтому такие бэкапы восстанавливаются дольше.
```
$ gpbackup --dbname marketplace --single-data-file
```

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

Утилиты gpbackup и gprestore поддерживают сжатие бэкапов, чтобы сократить объем занимаемого пространства и улучшить производительность ввода-вывода.

Поддерживаются алгоритмы сжатия gzip и zstd:

gzip (по умолчанию) — широко распространенный алгоритм. Он обеспечивает лучшую совместимость, так как доступен по умолчанию в большинстве систем Linux и UNIX.
zstd — более современный и эффективный алгоритм. Он обеспечивает более высокую степень сжатия и быстрее сжимает и распаковывает данные.

Чтобы выбрать алгоритм сжатия, используйте опцию --compression-type.

Вы также можете задать уровень сжатия от 1 (по умолчанию: наиболее быстрый, минимальное сжатие) до 9 (наиболее медленный, максимальное сжатие) с помощью опции --compression-level:

$ gpbackup --dbname marketplace --compression-type zstd --compression-level 5

Если нет особых требований, рекомендуется использовать средний уровень, например 4 или 5. Он обеспечивает хороший баланс между степенью сжатия, нагрузкой на CPU и временем выполнения операции.

Чтобы создать бэкап без сжатия, используйте параметр --no-compression:

$ gpbackup --dbname marketplace --no-compression

В этом случае данные сохраняются в виде CSV-файлов. Это снижает нагрузку на CPU во время создания бэкапа и позволяет напрямую использовать файлы, например, для создания внешних таблиц или загрузки данных с помощью команды COPY.

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

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

$ gpbackup --dbname marketplace --jobs 10

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

Во время создания бэкапа каждый процесс использует собственное подключение к базе данных и устанавливает блокировку на объект, с которым работает. gpbackup устанавливает на таблицы блокировку ACCESS SHARE, что запрещает изменения структуры (DDL) во время чтения данных. SQL-запросы, которые читают или изменяют данные таблицы, могут выполняться параллельно, но операции DDL, такие как ALTER TABLE, DROP TABLE или TRUNCATE TABLE, будут заблокированы до завершения создания бэкапа. Поэтому рекомендуется запускать параллельные бэкапы в периоды низкой DDL-активности, например, во время планового обслуживания.

Опция --jobs утилиты gprestore работает аналогично: она определяет, сколько таблиц восстанавливается одновременно.

$ gprestore --timestamp 20251010120101 --jobs 10

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

ПРИМЕЧАНИЕ

Опция --jobs неприменима к бэкапам, созданным с --single-data-file. Попытка использовать оба параметра одновременно приводит к ошибке.

Этот раздел описывает способы включить и исключить из бэкапа и восстановления вспомогательные объекты базы данных:

метаданные таблиц (DDL);
глобальные объекты;
статистику таблиц.

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

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

--data-only — создает бэкап только данных таблиц, без DDL для создания объектов. Используйте этот параметр при восстановлении данных в существующую базу с той же структурой. Пример:
```
$ gpbackup --dbname marketplace --data-only
```
--metadata-only — создает бэкап только метаданных (DDL), без данных таблиц. Этот режим полезен для воссоздания структуры базы данных на другом кластере или экспорта схем. Пример:
```
$ gpbackup --dbname marketplace --metadata-only
```
Комбинируя --metadata-only с фильтрацией по схемам и таблицам, можно извлечь DDL для отдельных объектов базы данных и пересоздать их в другом кластере:
```
$ gprestore --timestamp 20251010043530 --metadata-only --include-table public.customers
```

По умолчанию gpbackup включает в бэкапы глобальные метаданные, такие как роли, табличные пространства, ресурсные очереди и ресурсные группы. Чтобы исключить глобальные объекты, используйте параметр --without-globals:

$ gpbackup --dbname marketplace --without-globals

В свою очередь, gprestore не восстанавливает глобальные объекты по умолчанию. Чтобы восстановить их, используйте параметр --with-globals:

$ gprestore --timestamp 20251006092702 --with-globals

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

Бэкапы могут включать статистику таблиц, что позволяет восстановленной базе сохранить информацию для планировщика запросов без необходимости немедленного выполнения ANALYZE. Чтобы включить статистику в бэкап, используйте опцию --with-stats:

$ gpbackup --dbname marketplace --with-stats

Для восстановления статистики добавьте эту же опцию в вызов gprestore:

$ gprestore --timestamp 20251006100053 --with-stats

Однако если распределение данных изменилось во время или после восстановления, например, при восстановлении в базу с другой структурой или подмножеством данных, старая статистика может стать неактуальной. В таких случаях можно указать gprestore автоматически собрать новую статистику после завершения операции с помощью параметра --run-analyze:

$ gprestore --timestamp 20251006100053 --run-analyze

gpbackup и gprestore записывают информацию о своих вызовах в файлы отчетов. Эти отчеты содержат отметку времени операции, версии Greengage DB и утилит, статус выполнения, количество объектов и другие сведения. Отчеты сохраняются в каталоге бэкапа на мастер-хосте:

Отчеты gpbackup : gpbackup_<backup_timestamp>_report

Пример отчета gpbackup

Greengage Database Backup Report

timestamp key:         20251006065627
gpdb version:          6.29.0+dev.4.g7f02b2072f build dev
gpbackup version:      1.30.6+dev.1.g108659cb

database name:         marketplace
command line:          gpbackup --dbname marketplace
compression:           gzip
plugin executable:     None
backup section:        All Sections
object filtering:      None
includes statistics:   No
data file format:      Multiple Data Files Per Segment
incremental:           False

start time:            Mon Oct 06 2025 06:56:27
end time:              Mon Oct 06 2025 06:56:29
duration:              0:00:02

backup status:         Success

database size:         88 MB
segment count:         4

count of database objects in backup:
aggregates                   0
casts                        0
collations                   0
constraints                  0
conversions                  0
default privileges           0
database gucs                0
event triggers               0
extensions                   0
foreign data wrappers        0
foreign servers              0
functions                    0
indexes                      0
operator classes             0
operator families            0
operators                    0
procedural languages         0
protocols                    0
resource groups              2
resource queues              1
roles                        1
rules                        0
schemas                      1
sequences                    0
tables                       2
tablespaces                  0
text search configurations   0
text search dictionaries     0
text search parsers          0
text search templates        0
triggers                     0
types                        0
user mappings                0
views                        0

Отчеты gprestore: gprestore_<backup_timestamp>_<restore_timestamp>_report

Пример отчета gprestore

Greengage Database Restore Report

timestamp key:           20251006065627
gpdb version:            6.29.0+dev.4.g7f02b2072f build dev
gprestore version:       1.30.6+dev.1.g108659cb

database name:           marketplace
command line:            gprestore --timestamp 20251006065627 --create-db

backup segment count:    4
restore segment count:   4
start time:              Mon Oct 06 2025 07:07:23
end time:                Mon Oct 06 2025 07:07:27
duration:                0:00:04

restore status:          Success

Значения <backup_timestamp> и <restore_timestamp> указывают время начала операций бэкапа и восстановления соответственно.

gpbackup и gprestore могут автоматически отправлять отчеты о выполнении операций по электронной почте. Для использования этой функции на мастер-хосте должна быть доступна команда sendmail. Эта команда может быть реализована утилитой Sendmail или другим почтовым агентом, предоставляющим совместимый интерфейс.

Для включения функции отправки отчетов создайте файл gp_email_contacts.yaml в одном из следующих каталогов:

Домашний каталог пользователя gpadmin, например: /home/gpadmin/
Каталог установки утилит, например: /usr/local/gpdb/bin/

Если файл не найден ни в одном из этих каталогов, утилиты выводят информационное сообщение вида:

[INFO]:-Found neither /usr/local/gpdb/bin/gp_email_contacts.yaml nor /home/gpadmin/gp_email_contacts.yaml
[INFO]:-Email containing gpbackup report /data1/master/gpseg-1/backups/20251006/20251006083418/gpbackup_20251006083418_report will not be sent

В файле gp_email_contacts.yaml укажите адреса получателей и типы отчетов для отправки, используя следующую структуру:

contacts:
  gpbackup:
  - address: <user>@<domain>
    status:
         success: [true | false]
         success_with_errors: [true | false]
         failure: [true | false]
  gprestore:
  - address: <user>@<domain>
    status:
         success: [true | false]
         success_with_errors: [true | false]
         failure: [true | false]

Пример файла с контактами:

contacts:
  gpbackup:
  - address: admin@example.com
    status:
      success: true
      success_with_errors: true
      failure: true
  - address: alerts@example.com
    status:
      success: false
      success_with_errors: true
      failure: true
  gprestore:
  - address: admin@example.com
    status:
      success: true
      success_with_errors: true
      failure: true

Формат файла с контактами
Ключ	Описание	Обязательность
contacts	Обязательный раздел верхнего уровня	Да
gpbackup	Раздел с настройками почтовых уведомлений для утилиты `gpbackup`	Нет
gprestore	Раздел с настройками почтовых уведомлений для утилиты `gprestore`. Имеет такую же структуру, как раздел `gpbackup`	Нет
address <user>@<domain>	Адрес для отправки отчетов утилиты `gpbackup`. Можно указать один адрес или несколько адресов, каждый в своем разделе	Да
status	Указывает, какие отчеты `gpbackup` нужно отправлять на соответствующий адрес	Да
success true \| false	Отправляет отчеты об успешных операциях резервного копирования (код возврата `0`). Значение по умолчанию: `false`	Нет
success_with_errors true \| false	Отправляет отчеты об операциях, завершенных с некритичными ошибками (код возврата `1`). Значение по умолчанию: `false`	Нет
failure true \| false	Отправляет отчеты об операциях, завершенных с ошибками (код возврата `2`). Значение по умолчанию: `false`	Нет

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

Файлы логов хранятся вместе с другими логами Greengage DB. Обычно они находятся в подкаталоге gpAdminLogs/ домашнего каталога пользователя gpadmin.

Каждый файл лога охватывает все операции бэкапа и восстановления, выполненные в течение одного дня. Имена файлов содержат дату: gpbackup_YYYYMMDD.log и gprestore_YYYYMMDD.log, например gprestore_20251010.log.

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

Установка

Частичное резервное копирование

Полное резервное копирование и восстановление данных

Базовый сценарий резервного копирования и восстановления

Создание бэкапа

Восстановление из бэкапа

Настройка расположения бэкапа

Настройка структуры бэкапа

Настройка сжатия бэкапов

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

Вспомогательные данные в бэкапе

Данные и метаданные

Глобальные метаданные

Статистика таблиц

Мониторинг

Отчеты

Уведомления по электронной почте

Файлы логов