Вопрос по периодам хранения бэкапов

[ktulkhu]

Добрый день. Хотелось бы возможности задавать политику хранения резервных копий по типу: 14 ежедневных, 28 еженедельных, 2 года ежемесячных. Я так понимаю, в одном инстансе этого сделать никак не получится, даже комбинируя команды delete, merge.

В голову пришло только насоздавать дополнительных инстансов, типа erp_pitr, erp_weekly, erp_monthly и для каждого инстанса задавать свою политику хранения и комбинировать выполнение full, delta, page так, чтобы минимизировать оверхеды по фулл-копиям и по дополнительному времени выполнения для каждого инстанса..

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

[slothfk]

Это вполне реализуется с помощью закрепления резервной копии (см. параметр запуска--ttl)

[ktulkhu]

Это вполне реализуется с помощью закрепления резервной копии (см. параметр запуска--ttl)

Я смотрел в эту сторону. Но тоже показалось как-то мудрено.. Не смог до конца продумать всю концепцию.. при таком подходе, как я понимаю, нужно с разными параметрами запускать бэкапы full?

раз в месяц делать FULL STREAM ${PROBACKUP} backup --instance=$INSTANCE -j 4 -b FULL --compress --delete-expired --merge-expired --stream --ttl=2y

еженедельно (исключая дату, когда делается полный ежемесячный) делать FULL STREAM с датой истечения, например, 60 дней ${PROBACKUP} backup --instance=$INSTANCE -j 4 -b FULL --compress --delete-expired --merge-expired --stream --ttl=60d

задать для инстанса в настройках хранение 2 недели с избыточностью 3 фулла, хранение WALL 2 недели

# Retention parameters
retention-redundancy = 3
retention-window = 14
wal-depth = 14

в остальное время (ежедневно) делать PAGE с последюущим удалением истекших копий? ${PROBACKUP} backup --instance=$INSTANCE -j 2 -b PAGE --compress --delete-expired --merge-expired --delete-wal

как-то так? Или можно еще проще и изящней? Буду рад примерам (в доке примеров, как можно комбинировать и играть периодами - нету).

[slothfk]

С параметром --ttl не обязательно делать FULL, помеченная на длительное хранение копия станет FULL за счет слияния "устаревших" В остальном все так

[ktulkhu]

С параметром --ttl не обязательно делать FULL, помеченная на длительное хранение копия станет FULL за счет слияния "устаревших"

А что-то я такого в документации не углядел. Или это личный опыт?

И еще вопрос: а тогда имеет значение, будет FULL STREAM или ARCHIVE? для PITR я делаю без stream, но там WAL перекрывают период хранения, а тут будут фуллы с --ttl=90d, которые выходят за период хранения WAL, не совсем понятно, что будет при восстановлении такого фулла, для которого уже удалены WAL. Перестанет быть консистентным?

Иными словами: что будет с бэкапом FULL ARCHIVE, для которого уже удалены WAL, которые были созданы в момент его выполнения? С него можно будет восстановиться (на указанное для него время в "Recovery Time"?)?

[slothfk]

Или это личный опыт?

И еще вопрос: а тогда имеет значение, будет FULL STREAM или ARCHIVE?

Личный опыт, плюс в документации не написано обратного. У нас делаются бекапы ARCHIVE.

что будет при восстановлении такого фулла, для которого уже удалены WAL. Перестанет быть консистентным?

Бекап останется консистентным, при условии, что слияние пройдет без ошибок! Разумеется не будет возможности восстановления PITR Восстановиться можно будет только на "время создания резервной копии". Для каждой полной резернвой копии, находящейся за retention-window хранятся журналы с момента начала резервного копирования, до момента завершения. Тоже самое касается и резервных копий, в случаях когда настройкой wal-depth "вычищаются журналы для PITR для тех копий, которые остаются в retention-window ...

[ktulkhu]

Тоже самое касается и резервных копий, в случаях когда настройкой wal-depth "вычищаются журналы для PITR для тех копий, которые остаются в retention-window ...

Да у меня тоже ARCHIVE, просто периоды такие, что фуллы при этом не остаются без WAL. Проверить даже не на чем :).

Тоесть, можно все бэкапы делать ARCHIVE, не заморачиваться,чтобы фуллы были STREAM? и, получается, при настройках

# Retention parameters
retention-redundancy = 3
retention-window = 14
wal-depth = 14

при создании FULL еженедельно, PAGE ежедненвно между фуллами - смысл флага --merge-expired теряется? с чем будет слияние производиться, если у FULL стоит флаг TTL больше, чем окно retention-window? Не соображу, что будет происходить с фуллом, который "на границе" окна снизу будет (самый старый по времени). Будет постепеенно сливаться с порожденными от него PAGE, пока не "выдавится" следующим FULL? и уйдет на длительное хранение?