и большинство ответов ссылается на не стандарнтые тулзы.
Если только архивирование wal )
сейчас почитаю, спасибо !)
В стандартном postgresql инкрементальных бэкапов нет. Только в сторонних утилитах.
😢 печально, спасибо
сори, что так задалбываю, а какую утилиту посоветовали бы вы?
pg_probackup сейчас хорошо поднялся
супер, спасибо 😌
pg_backrest, wal-g, pg_probackup - сравнивайте, выбирайте под свои нужды
Выбирайте: https://ru-postgres.livejournal.com/66359.html
большое спасибо, хз как попропускал столько инфы
поправьте, пожалуйста: - текущая версия pgbackrest - 2.32 - wal-g умеет в параллелизм (wal-e тоже, но как-то куцо)
pgbackrest - не вопрос, а wal-g в параллелизм - прошу ссылку на доку. Не нашёл, когда про него писал.
@vyegorov Я правильно понимаю, что это параметры WALG_DOWNLOAD_CONCURRENCY и WALG_UPLOAD_CONCURRENCY?
Спасибо, однако, поправил.
тут ещё одна “прелесть” у wal-e обнаружилась: они не стесняются лезть во внутреннее состояние базы и менять статусы архивации WAL-сегментов, если включена параллельность для wal-push (а она по умолчанию включена): https://github.com/wal-e/wal-e/blob/master/wal_e/worker/pg/wal_transfer.py#L30 в результате, для некоторых сегментов archive_command не вызывается, совсем. я это заметил во время миграции на pgbackrest по дыркам в последовательности WAL и долго не понимал что вообще происходит. я бы добавил предупреждение на эту тему. как и рекомендацию не использовать wal-e для новых проектов как минимум.
Однако, спасибо большое! Обновил.
поймали баг в wal-g: https://github.com/wal-g/wal-g/issues/636 выражается в том, что после апгрейда базы, при delete retain (политика хранения) удаляются самые свежие бэкапы, а старые остаются. баг закрыт: https://github.com/wal-g/wal-g/pull/816 но необходимо использовать опцию --use-sentinel-time, без неё поведение не меняется. опция доступна в 1.* версии
Спасибо, однако! Добавил инфу комментарием.
Обсуждают сегодня