Обработка резервных копий большого стола (>1 ТБ) в Postgres?

Question

У меня есть таблица на 1 ТБ (X), которая является проблемой для резервного копирования.

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

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

Я хотел бы включить X в нашу стратегию резервного копирования, чтобы время восстановления было намного быстрее. Не представляется возможным включить X в ночное логическое резервное копирование.

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

Мне не хватает опыта, чтобы исследовать решения в одиночку, и мне интересно, каковы мои варианты?

Бармен для дополнительных обновлений? Раздел X? И то и другое?

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

Спасибо!

Answer 1

Я думаю, что использование barman с опцией потоковой передачи rsync/SSH + WAL и выполнение инкрементного резервного копирования - лучший вариант в вашем случае. Такой подход делает ваши ночные резервные копии более легкими и менее дорогостоящими, поскольку вам не нужно самостоятельно выполнять логику после настройки barman. Я скоро обновлю это в своем блоге, в котором подробно описаны шаги.

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

Спасибо

ОБНОВЛЕНИЕ (2020-08-27):

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

https://github.com/softwarebrahma/PostgreSQL-Disaster-Recovery-With-Barman

Спасибо