Pg_dump vs pg_basebackup


#1

Частенько слышу мнения о том, что pg_dump не пригоден для бэкапов. Стало интересно, почему.

Допустим, что проблема в том, что созданный через pg_dump дамп нельзя проверить на целостность после создания и перед восстановлением. Но ведь и pg_basebackup не будет добавлять чексуммы, если кластер проинициализирован без них (по дефолту).

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

Еще из того, что вспомнилось - в процессе дампа некоторые запросы (особенно DDL) могут блокироваться до завершения создания дампа. pg_basebackup вроде как лишен этой проблемы.

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

Можете ли вы назвать еще какие-нибудь весомые причины не использовать pg_dump для бэкапов?


#2

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

Минусы pg_dump:

  1. нет статистики и hint bits. После восстановления нужно будет гонять ANALYZE и VACUUM по всей базе, что займет время и сгенерит кучу I/O.
  2. берет снапшот - будет мешать автовакууму.
  3. долгое восстановление(нужно создать все индексы заново в один поток)
  4. не умеет в PITR

#3

Если убрать те вопросы которые вы написали что вам не критично - основное что остается это время развертывания backup.
Если вы никогда не пробовали развернуть базу в пару терабайт с dump файла - вы просто недооцениваете что это может занять легко 4тро суток (даже если параллельное восстановление использовать которое требует использование не plain text формата а -Fc или -Fd по которым не погрепаешь).

Для backup же редкоизменяемой небольшой базы - pg_dump решение более удобное потому что занимает на порядок меньше места и проще автоматизируется.


#4

Да тут главное даже не то, что долго, а что это время для наугад взятого дампа размера N Мб просто непредсказуемо. Backup – это, по определению, инструмент для disaster recovery. А для него, в свою очередь, критически важным является понятие RTO, а без предсказуемого времени восстановления достигнуть этой цели в принципе невозможно. Таким образом, дампы просто непригодны для backup-а, вот и всё.

Ну и, конечно, pg_dump снимает не всё и не всегда, но, после вышеизложенного, это уже не имеет значения.