Лучший способ для инкрементного резервного копирования PostgreSQL


в настоящее время я использую pg_dump передается в gzip передается в split. Но проблема в том, что все выходные файлы всегда изменяются. Таким образом, резервное копирование на основе контрольной суммы всегда копирует все данные.

есть ли другие хорошие способы выполнить инкрементное резервное копирование базы данных PostgreSQL, где полная база данных может быть восстановлена из резервных данных?

например, если pg_dump может сделать все абсолютно упорядоченным, поэтому все изменения применяются только в конце свалка, или что-то подобное.

3 52

3 ответа:

обновление:проверить бармен для более простого способа настроить архивирование WAL для резервного копирования.

можно использовать непрерывное архивирование Wal PostgreSQL метод. Сначала вам нужно установить wal_level=archive, затем сделайте полную резервную копию на уровне файловой системы (между выдачей pg_start_backup() и pg_stop_backup() команды) , а затем просто скопируйте более новые файлы WAL, настроив .

плюсы:

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

недостатки:

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

есть некоторые инструменты, такие как pitrtools и omnipitr что может упростить настройку и восстановление этих конфигураций. Но я сам ими не пользовался.

также проверьте http://www.pgbackrest.org

pgBackrest-это еще один инструмент резервного копирования для PostgreSQL, который вы должны оценивать, поскольку он поддерживает:

  • параллельное резервное копирование (проверено масштабировать практически линейно до 32 ядер, но, вероятно, может пойти гораздо дальше..)
  • сжатый в местах хранения резервных копий
  • инкрементный и дифференциальный (сжатый!) резервные копии
  • потоковое сжатие (данные сжимаются только один раз в источнике а потом передается по сети и хранится)
  • параллельное, Дельта-восстановление (возможность обновления старой копии до последней)
  • полностью поддерживает табличные пространства
  • резервное копирование вращения и архив истечения срока действия
  • возможность возобновить резервное копирование, которое не удалось по какой-то причине
  • etc, etc..

другой метод заключается в резервном копировании в обычный текст и использовании rdiff для создания инкрементных различий.