Зачем нужно хранить FULL для выполнения последующих инкрементных бэкапов

[triwada]

Есть проблема с необходимостью хранения большого объёма бэкапов, может есть возможность оптимизировать этот момент?
Описание:

1. на локальный раздел в ОС выполняется бэкап согласно расписанию: FULL раз в сутки, каждые 2 часа DELTA или PAGE.
2. согласно документации DELTA/PAGE выполняется относительно успешного предыдущего успешного FULL или DELTA/PAGE (не указано, что для всех инкрементных нужно ещё хранить FULL)
3. выполненные бэкапы постепенно переносятся на ленту, после чего их по идее можно удалять, освобождая место на локальном разделе бэкапов.

Но если удалить FULL, то бэкапы DELTA/PAGE не выполняются.

[postgres@pglab ~]$ pg_probackup-std-12 show -B /data/backup --instance pgpro-std12
=========================================================================================================================================
 Instance     Version  ID      Recovery Time           Mode   WAL Mode  TLI    Time   Data   WAL  Zratio  Start LSN   Stop LSN    Status
=========================================================================================================================================
 pgpro-std12  12       QS3B8N  2021-04-25 01:46:00+03  DELTA  STREAM    1/1      6s  167kB  32MB    1.00  7/4F000028  7/4F000168  OK
 pgpro-std12  12       QS3B5V  2021-04-25 01:44:20+03  DELTA  STREAM    1/1      5s  167kB  32MB    1.00  7/4D000028  7/4D000168  OK
 pgpro-std12  12       QS3B48  2021-04-25 01:43:24+03  FULL   STREAM    1/0     10s  825MB  16MB    1.00  7/4B000028  7/4B000168  OK


[postgres@pglab ~]$ rm -rf /data/backup/backups/pgpro-std12/QS3B48

[postgres@pglab ~]$ pg_probackup-std-12 backup -B /data/backup --instance pgpro-std12 -b DELTA --stream --progress --log-level-console=INFO
INFO: Backup start, pg_probackup version: 2.4.10, instance: pgpro-std12, backup ID: QS3B9Q, backup mode: DELTA, wal mode: STREAM, remote: false, compress-algorithm: none, compress-level: 1
WARNING: Current PostgreSQL role is superuser. It is not recommended to run backup or checkdb as superuser.
WARNING: Valid backup on current timeline 1 is not found, trying to look up on previous timelines
WARNING: Cannot find valid backup on previous timelines, WAL archive is not available
ERROR: Create new full backup before an incremental one
WARNING: backup in progress, stop backup
WARNING: Backup QS3B9Q is running, setting its status to ERROR

Понятно, что FULL нужен для рестора, но зачем он нужен для последующих DELTA/PAGE (НЕ первого после FULL)?
Если поведение изменится, то можно существенно сэкономить на затратах на локальный диск для бэкапов, выступающих в качестве временного буфера перед перемещением бэкапов на ленту.
Есть довольно весомая разница в объёмах (особенно на БД с повышенной генерацией WAL) в хранении либо 1xFULL+1xDELTA, либо 1xFULL+11xDELTA (при условии, что DELTA каждые 2 часа).

[gsmolk]

Добрый день!

Понятно, что FULL нужен для рестора, но зачем он нужен для последующих DELTA/PAGE (НЕ первого после FULL)?

Дело в том, что при создании новой инкрементальной копии, пробэкап сначала находит подходящий FULL и подбирает подходящую цепочку инкрементальных бэкапов, исходящую из этого FULL бэкапа, к которой можно пристегнуть текущий. см пример в исходниках:
https://github.com/postgrespro/pg_probackup/blob/master/src/catalog.c#L1186

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

[triwada]

это плохое решение, т.к. бэкап FULL будет отображаться в списке бэкапов в статусе ОК, а по факту он будет невалидным, ведь каталог database будет пустым. Когда систему администрирует несколько DBA, это может приводить к проблемам, особенно, когда вдруг понадобится выполнить рестор. Решать регламентированием это не особо хочется.
Не планируется разделять метаданные бэкапов и непосредственно данные бэкапов?

[gsmolk]

Не планируется разделять метаданные бэкапов и непосредственно данные бэкапов?

Что именно Вы имеете ввиду?

[triwada]

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

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

[gsmolk]

Файлы метаданных бэкапа все же лежат отдельно от файлов данных.

это плохое решение, т.к. бэкап FULL будет отображаться в списке бэкапов в статусе ОК, а по факту он будет невалидным,

Наверное, тут можно придумать некий дополнительный статус, например, DETACHED, который говорил бы о том, что файлы данных отсутствуют.

[triwada]

это будет явно полезно, чем статус ОК и пустой каталог database внутри бэкапа.

Но на счёт разделения метаданных, думаю, стоит подумать (не в рамках этого issue, это больше архитектурный вопрос).
Если сравнить в MSSQL Server, Oracle RMAN, то там есть история бэкапов (по сути история метаданных бэкапов) и SQL-интерфейс к метаданным бэкапа.

В probackup при удалении бэкапа (например, при истечении retention) каталог бэкапа удаляется полностью и вместе с ним и метаданные о нём, а было бы здорово иметь историю бэкапов за гораздо больший период (в идеале с момента инициализации инстанса в probackup)

[gsmolk]

это будет явно полезно, чем статус ОК и пустой каталог database внутри бэкапа.

Хорошо, сделаем что-нибудь в этом направлении.

Но на счёт разделения метаданных, думаю, стоит подумать

Ну у нас есть мрия о хранении метаданных в отдельном PostgreSQL инстансе, это вполне бы позволило сделать то, чего Вы хотите.

[triwada]

Так и пришлось делать: отдельный инстанс + автоматизация выгрузки/загрузки/разбора pg_probackup show в формате json.
Думаю, таким "велосипедостроением" занимался уже не один DBA, который юзает pg_probackup.

[gsmolk]

А отдельный инстанс зачем?

[triwada]

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

[gsmolk]

а, туплю, я подумал, что речь идет об отдельной пробэкапном инстансе

[gsmolk]

Вопрос для расширения кругозора. Зачем Вам информация о давно удаленных бэкапах?

[triwada]

из истории за длительный период можно получить, например:

1. динамика объёмов архивации WAL (равно генерации WAL)
2. объёмы бэкапов DELTA/PAGE, FULL и отношение инкрементных бэкапов к FULL за сутки (или иной период) - можно пересмотреть расписание выполнения бэкапов с целью экономии места
3. деградация скорости выполнения бэкапов
4. эффективность компрессии в разрезе роста БД
5. оценка перехода на PAGE c DELTA на больших БД
6. отличие скорости выполнения бэкапов и размеров бэкапов одной БД на разных серверах (на мастере и реплике, или с разных репликах) может косвенно говорить о наличии какой-то проблемы (чаще всего устройство хранения бэкапов)

[gsmolk]

Спасибо большое!

[sgrinko]

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

[gsmolk]

Да идея-то простая, метаданные хранить в отдельном PG кластере.
Надо просто сесть и сделать =)