реализация режима разностного бэкапа

[triwada]

планируется ли реализация режима разностного бэкапа?
Чтобы можно было выполнить отдельно бэкап типа DELTA относительно последнего успешного FULL, а не относительно последнего успешного DELTA.
На больших БД (порядок >10ТБ) и с большим объемом модификаций выходит так, что несколько бэкапов DELTA в течении дня будут занимать значительный объем (и соответственно время восстановления тоже вырастет), поэтому было бы удобно иметь такой тип бэкапа.
Можно было реализовывать схемы расписания вида
FULL - раз в неделю
DELTA - в течении дня
DIFF - раз в сутки

[gsmolk]

Можем запланировать на 2.4.0.
Встаёт вопрос об интерфейсе. Лично я вижу два варианта:

1. Дешево и сердито. Просто даем возможность указывать айдюк родительского бэкапа, чтобы юзер, при запуске инкрементального бэкапа, мог самостоятельно задавать родителя. Получается довольно гибко, но потребует дополнительных телодвижений со стороны юзера.
   И, глядя в show, отличить просто инкрементальный бэкап от дифференциального "на глаз" не получится. Потребуется чекать родителя, а это опять лишние телодвижения.

2. Добавляем флаг --diff и при снятии инкрементального бэкапа автоматически ищем ближайший full и считаем его своим родителем. В show добавляем новое поле, чтобы различать инкрементальные и дифференциальные:

=============================================
 ID      Recovery Time           Type  Mode  
=============================================
 Q9S3WI  2020-05-04 02:29:14+03  INCR  PAGE  
 Q9S3V0  2020-05-04 02:28:27+03  INCR  DELTA 
 Q9S3U7  2020-05-04 02:28:02+03  INCR  PAGE  
 Q9S3T1  2020-05-04 02:27:21+03  INCR  PAGE  
 Q9S3QO  2020-05-04 02:25:59+03  INCR  DELTA 
 Q9S3OK  2020-05-04 02:24:36+03  INCR  PAGE  
 Q9S3NI  2020-05-04 02:24:04+03  INCR  PAGE  
 Q9S3JZ  2020-05-04 02:21:59+03  DIFF  PAGE  
 Q9S3GT  2020-05-04 02:20:23+03  INCR  PAGE  
 Q9S365  2020-05-04 02:13:32+03  INCR  PAGE  
 Q9S354  2020-05-04 02:13:01+03  INCR  PAGE  
 Q9S33U  2020-05-04 02:12:20+03  INCR  PAGE  
 Q9S31A  2020-05-04 02:11:32+03  INCR  DELTA 
 Q9S2XN  2020-05-04 02:08:41+03  INCR  PAGE  
 Q9R1T8  2020-05-03 12:46:42+03  FULL  FULL

Каково ваше мнение по данному вопросу?

[gsmolk]

Есть еще довольно радикальное мнение.
Единственный профит от DIFF бэкапа - это ускорение восстановления за счет того, что блоки не перезаписываются несколько раз подряд, как это происходит при восстановлении длинной цепочки инкрементальных бэкапов. pg_probackup даже подсчитывает эффективность инкрементального восстановления, чтобы иметь представление о том, какой объем работы был выполнен впустую:

INFO: Start restoring backup files. PGDATA size: 1554MB
INFO: Backup files are restored. Transfered bytes: 4382MB, time elapsed: 40s
INFO: Approximate restore efficiency ratio: 35% (1554MB/4382MB)

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

[triwada]

помимо этого преимущества, DIFF будет занимать места меньше, чем набор DELTA. Иногда это будет играть роль в случаях, когда экстренно нужно освободить место на хранилище бэкапов, чтобы смог завершиться очередной FULL, при этом пожертвовав цепочкой DELTA, зная, что есть DIFF.
По интерфейсу, я сначала предполагал, что будет просто новый режим DIFF по аналогии с DELTA/PAGE/FULL. Ведь по сути этот тип бэкапа актуален только для механизма на уровне изменений блоков (DELTA) в плане скорости выполнения при наличии на БД высокой генерации WAL (для PAGE ничего не выигрывается, т.к. нет разницы, сколько WAL в целом нужно будет проанализировать).

[gsmolk]

помимо этого преимущества, DIFF будет занимать места меньше, чем набор DELTA.

Почему? При неизменности RTO (например, бэкап на каждый час), DIFF наоборот съест больше места из-за дублирования данных.
Вообще DIFF бэкап - это про ускорение восстановления за счет потребления дополнительного свободного места.

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

Ну по идее Вы можете добиться аналогичного этого эффекта с помощью merge.

По интерфейсу, я сначала предполагал, что будет просто новый режим DIFF по аналогии с DELTA/PAGE/FULL. Ведь по сути этот тип бэкапа актуален только для механизма на уровне изменений блоков (DELTA) в плане скорости выполнения при наличии на БД высокой генерации WAL (для PAGE ничего не выигрывается, т.к. нет разницы, сколько WAL в целом нужно будет проанализировать).

У нас DELTA/PAGE описывают именно физический механизм снятия инкрементальной копии, а DIFF - это логическое понятие, означающее, что у этого инкрементальной копии родителем является FULL. Необходимость указывать физический механизм при этом остается. Поэтому такой вариант интерфейса не подходит.

[triwada]

помимо этого преимущества, DIFF будет занимать места меньше, чем набор DELTA.

Почему?

Всё-таки предполагается, что DIFF запускается намного реже DELTA.

По поводу интерфейса: вариант с добавление параметра --diff и колонки Type в show выглядит вполне понятным

[gsmolk]

Всё-таки предполагается, что DIFF запускается намного реже DELTA.

А общее кол-во DELTA при этой остаётся прежним? Если да, то Вы теряете дополнительное место. Если нет и их кол-во уменьшится, то Вы ухудшите свой RPO/RTO.

Предположим, что есть требование к RPO/RTO, выражающееся в том, что вам нужен бэкап на каждые два часа. Ваша дневная цепочка выглядит так:

22:00 I11
20:00 I10
18:00 I9
16:00 I8
14:00 I7
12:00 I6
10:00 I5
08:00 I4
06:00 I3
04:00 I2
02:00 I1
00:00 F

F - полный, I - инкрементальный (DELTA/PAGE/PTRACK)

Что именно Вы хотите выиграть с помощью DIFF бэкапа? Как бы Вы организовали эту цепочка, если бы можно было бы снимать DIFF бэкапы?

[triwada]

Да, при использовании DIFF естественно больше затраты на место, но есть весомый довод в скорости восстановления.

В моём случае FULL выполняется раз в три дня (т.к. он выполняется более суток), DELTA каждые 2 часа. Хотелось бы иметь DIFF раз/два в сутки.

При такой цепочке
FULL2
INCR
INCR -если нужно ресторится сюда, то ресторим FULL->DIFF->INCR12,...
..
INCR12
DIFF
INCR11
INCR10
...
INCR1
FULL1

Будет ли ломаться цепочка DELTA после выполнения DIFF?

[gsmolk]

Да, при использовании DIFF естественно больше затраты на место, но есть весомый довод в скорости восстановления.

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

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