Как лучше и проще делать бэкапы/дампы базы Postgresql ?

единственный нормальный вариант - https://github.com/wal-g/wal-g
есть еще barman, wal-e, но они скорее мертвы, чем живы, но надо признать, еще работают.
pg_dump - это плохой бекап. Нет централизации, нет консистентности. Если тебе совсем прям пофиг на эти вещи, то и нет никакой разницы как это делать, всё равно это шляпа.
И да pg_dump и pg_dump_all мало чем отличаются, если нужна отдельная база или таблица - pg_dump, иначе второе.

pg_dump database_name | gzip > database_name_20160527.sql.gz

Если слишком медленно, то меняем gzip на pigz, lzop или другой компрессор по вкусу (всё равно примерно в 2 раза пожмет). Целостность можно проверять и исправлять ошибки устройства хранения с помощью par2.

Этот ответ неправильный и вредный. Прежде всего, надо конечно освоить pg_dump, то есть добиться, чтобы своя база восстанавливалась в другом экземпляре PostgreSQL или хотя бы в другой базе в том же PostgeSQL. Но на этом можно не останавливатья, а узнать , чем ещё пользуются, не полагаясь на случайный ответ. Но в том числе заслуживает внимания и Barman (поскольку им пользуются), в то время как рекомендованная предыдущим оратором приблуда мне не известна ( но я не знаток PostgreSQL). Литература: в комплекте документации по PostgreSQL есть книга по архивации и репликации. Сверх того, у издательства Packt Publishing есть несколько хороших книг по PostgreSQL (их можно быстро купить в электронном виде), в том числе книга по архивации и репликации. Да, и отличие между pg_dump и pg_dumpall не такое, его лучше узнать из документацим.

многие уверены, что pg_dump даст им настоящий дамп базы, а это не так. Это лишь однопоточное (если не говорить про файловый вариант) копирование таблиц, что приводит к тому, что это не является консистентной копией твоей базы. Так что использовать данный инструмент для копирования целой базы, а не выборочных таблиц, вкорне неверно.
Если неизвестна «приблуда» wal-g, то можешь сходить по ссылке, что я привел. Могу сказать, что ее пилит яндекс для своего же прода.

И не очень понятно, почему ты назвал мои советы неверными и вредными, даже не приведя чем мой вариант так плох? Или ты не согласен с тем, что юзать pg_dump для полного копирования базы неверно?
Ну и вообще, зачем расставлять оценка верно или не верно, если ты вообще не знаток postgres, а обычный мимокрокодил?

многие уверены, что pg_dump даст им настоящий дамп базы, а это не так.

И правильно уверены --- даст (если отработает без ошибок), но только одной базы, конечно же. Только вот dump --- не backup.

что это не является консистентной копией твоей базы.

Является, естественно (вы бы хоть документацию открыли).

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

Использовать его верно, и, более того, строго говоря, для DWH это единственно правильный вариант (для disaster recovery пофиг, но dump для него и не подходит).

Этот ответ неправильный и вредный.

Нет, это один из правильных советов. Штатные pg_basebackup, архивирование WAL и репликацию тоже вполне можно использовать, но на их основании делают более удобные «обёртки» --- вот, в основном, и всё.

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

Именно для backup-а осваивать pg_dump и добиваться описанного совсем не нужно. Как я уже писал в ответе другому автору: dump --- это не backup.

в то время как рекомендованная предыдущим оратором приблуда мне не известна ( но я не знаток PostgreSQL)

Может, не стоит и критиковать, в таком случае? ;)

Литература: в комплекте документации по PostgreSQL есть книга по архивации и репликации.

Там есть глава про это, да. Её лучше прочесть целиком.

это не является консистентной копией твоей базы

В официальной документации написано, что является.

ну вот как всегда — уже года 2 не пойму, как же всё-таки можно делать бэкапы, просто и без заморочек?

*какие 2-3 тулзы используется большинством как de-facto?*

В официальной документации написано, что является.

На заборе тоже написано (напишите bug report, или в -docs, может, исправят).

Но, вообще говоря, это зависит от того, что понимается под backup-ом. Нормальные люди понимают под этим инструмент disaster recovery, а что было в голове у того, кто писал документацию... кто его знает.

ну вот как всегда — уже года 2 не пойму, как же всё-таки можно делать бэкапы, просто и без заморочек?

То есть вы 2 года не можете прочитать соответствующую главу в документации, серьёзно?

А скажите, кстати, «делать backup»-ы --- это один из шаманских сисадминских ритуалов? Вроде плевков через левое плечо? Или у этого действия всё же есть какая-то реальная цель?

Если цель(и) есть, то backup --- только средство, а т.к. конкретные цели бывают разные, то и используется это средство по-разному, т.е. зависит от того, что конкретно вы хотите делать «просто и без заморочек».

Является, естественно (вы бы хоть документацию открыли).

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

Физическая целостность != логическая целостность.

Физическая целостность != логическая целостность.

Dumps created by pg_dump are internally consistent, meaning, the dump represents a snapshot of the database at the time pg_dump began running. pg_dump does not block other operations on the database while it is working. (Exceptions are those operations that need to operate with an exclusive lock, such as most forms of ALTER TABLE.)

Давай тогда конкретику, а не отмазки в духе «на заборе написано».

Как лучше и проще делать бэкапы/дампы базы Postgresql ? (комментарий)
вот же пример!

Ценность примера на уровне надписей на заборе. Таким образом есть разработчик, который утверждает, что данные консистентны (вполне правдоподобно для ACID СУБД), и есть некий анон, у которого бизнес спросил. Хм-хм, кому же верить.

Разработчик утверждает, что физически данные будут целостны, то есть ты можешь развернуть базу из бекапа и всё будет ок.
Но есть еще логическая целостность, где данные в таблицах зависят друг от друга на уровне логики, но копироваться они будут в разное время, то есть ты получишь сломанные транзакции с точки зрения логики.

Это основной кейс, который мешает юзать pg_dump на продуктовых частоизменяющихся базах.

Ты понимаешь о чем я?

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

Ты знаешь, что такое ACID? Если ты начинаешь транзакцию чтения на все таблицы, то СУБД тебе гарантирует, что ты до конца транзакции будешь видеть то состояние таблиц, которое было в начале транзакции. Говно ты можешь получить, если некий бизнес-процесс совершал одну свою логическую операцию в две («сначала запишу в эту таблицу, потом в другую») или более транзакции, и твоя вклинилась между ними. Разработчика такого бизнес-процесса, конечно, нужно уволить, у него явно проблемы в ДНК. Я это заявляю как разработчик бизнес-процессов (ну, чаще их реализаций в говнокоде), лол.

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

Только никакого отношения к тому, как реально работает pg_dump, вышеописанное не имеет.

Он действительно может снимать логически констистентные дампы.

Ещё раз вам советую --- прочитайте документацию.

Ты знаешь, что такое ACID?

Да ничего он такого не знает, по-моему...

Вообще, похоже, есть немало людей, которые воображают, что современные СУБД написаны примерно так, как они сами бы написали «на коленке» за пару дней, и исключительно на этом основании рассказывают, как работают базы данных.

Только вот на самом деле современные RDBMS — это, пожалуй, самые сложные артефакты из созданных человечеством (в них, между прочим, вложены сотни человеко-лет труда лучших программистов планеты). И, скорее всего, упомянутые люди даже неспособны понять (а не то что разработать) многие из используемых там алгоритмов и принципов. ;)

Если ты начинаешь транзакцию чтения на все таблицы, то СУБД тебе гарантирует, что ты до конца транзакции будешь видеть то состояние таблиц, которое было в начале транзакции.

Ну, вообще говоря, это зависит от реализации ACID в конкретной СУБД и используемого уровня изоляции (и, кстати, этой гарантии недостаточно для полноценного ACID)... но, в данном случае, к делу это всё не относится, т.к. конкретно в PostgreSQL, конкретно для pg_dump это именно так.

Только вот dump --- не backup.

ага

Разработчика такого бизнес-процесса, конечно, нужно уволить, у него явно проблемы в ДНК. Я это заявляю как разработчик бизнес-процессов

ясно, с этого бы и начинал :)
зарекался же не начинать спорить тут с анонами, да всё ведусь. Тебе еще учиться и учиться надо, пока, к сожалению, сочувствую бизнесу, которому бизнес процессы пишут такие ребята :)

Разработчика такого бизнес-процесса, конечно, нужно уволить, у него явно проблемы в ДНК.

ясно, с этого бы и начинал :)

А что не так-то (кроме избыточности реакции)?

Разделение действий, которые должны выполняться в одной транзакции, на несколько --- 100% ошибка.

зарекался же не начинать спорить тут с анонами, да всё ведусь.

Правильно, лучше почитайте вместо этого документацию, чтоб и самому разобраться, и людей не дезинформировать.

да, пойду доку почитаю, лол :)
еще и парням на работе расскажу, пусть тоже поугарают :)

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

да, пойду доку почитаю, лол :)

Да идите вы почитайте, наконец! Ещё раз, для всех: pg_dump снимает логически консистентные дампы.

еще и парням на работе расскажу, пусть тоже поугарают :)

Они тоже любят смеяться без причины?

(Меня это воинствующее невежество уже начинает доставать, если честно.)

а ты всё таки не слушай этих клоунов,

Ну уж вы-то прям директор цирка. ;)

pg_dump это больше поделие для разработчика, чтобы снять дамп «прям тут» определенных таблиц для каких-то девелоперских целей,

Ну, не только. Его же можно использовать для перехода на новые версии, консистентного DWH и т.п.

если тебе нужен настоящий надежный бекап, то используй

инструменты, которые специально для этого и придуманы, чтобы самому потом не обосраться и не подвести людей, которые будут надеяться на эти бекапы. Но, внезапно, согласен. :)

я тебе уже описал варианты, как легко получить базу данных после бекапа, которая окажется «не рабочей» с точки зрения бизнес-логики. Да, ты мне можешь сейчас рассказывать про ДНК, про увольнения сотрудников и прочее крутые твои мысли и решения, но.. бекапы, как правило, делает не тот человек, у которого проблема с ДНК, то есть не тот твой вакуумный разработчик, а админ, либо дба. И когда случится, что нужен бекап, и админ, по твоему совету построивший бекапы на основе pg_dump начнет его восстанавливать, то для общего проекта это будет фейл, независимо от того, у кого там что с ДНК.
Я лишь за то, что если ты можешь сделать что-то надежно и правильно со своей стороны, застраховав себя от фейлов других людей, то изначально и делай так. А бекапы на основе wal-ов решат те проблемы, про которые я говорю.

Любая, более менее адекватная компания никогда не будет бекапить постгресы pg_dump-ом, иначе им просто наплевать на бекапы.
Прошу тебя, не пиши мне про ACID в очередной раз, я уже довольно давно работаю с разными RDBMS, я прекрасно понимаю эти принципы. Но я и обжигался на бекапах с pg_dump, так же прекрасно понимаю его принципы работы, поэтому и пытаюсь помочь человеку не наступить на те же грабли. А ты, зачем-то, пытаешься упорно подставить ТС, бросаясь аббревиатурами, про которые он не спрашивал.
Вобщем, акстись, пожалуйста, не пакости тут людям, дорогой анон.

Нет, с меня хватит.

я тебе уже описал варианты, как легко получить базу данных после бекапа, которая окажется «не рабочей» с точки зрения бизнес-логики.

Это не «варианты», а твои галлюцинации.

Да, ты мне можешь сейчас рассказывать про ДНК, про увольнения сотрудников и прочее крутые твои мысли и решения, но..

Что «но»? ДНК там или нет, если кто-то неправильно пишет бизнес-логику (некорректно разбивая её на отдельные транзакции), никакими backup-ами эту проблему не решить.

бекапы, как правило, делает не тот человек, у которого проблема с ДНК, то есть не тот твой вакуумный разработчик, а админ, либо дба.

По-хорошему, так.

И когда случится, что нужен бекап, и админ, по твоему совету построивший бекапы на основе pg_dump

Я никогда не давал такого идиотского совета!

Да, все аноны на одно лицо, что поделаешь. ;)

начнет его восстанавливать, то для общего проекта это будет фейл, независимо от того, у кого там что с ДНК.

Может будет, а может, и нет. Только вот консистентность (которая у дампа в пределах одной базы в некотором смысле даже лучше, чем у pg_basebackup (и любого решения, основанного на WAL)), недостаточна, чтобы сделать дампы пригодными для backup-а.

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

Backup-ы и должны быть основаны на WAL-ах (ну или full-ах, для небольших баз), кто с этим спорит --- не разбирается в вопросе.

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

Конечно, это так.

Прошу тебя, не пиши мне про ACID в очередной раз, я уже довольно давно работаю с разными RDBMS, я прекрасно понимаю эти принципы.

Неважно, сколько ты с чем работаешь. Вот, например, идиоты от этого просто становятся опытными идиотами. ;)

А если ты «разбираешься» в ACID, откуда тут эта чушь про неконсистентные дампы?

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

Ага, оно и видно --- обжёгся, и даже не понял, что это было. ;)

А ты, зачем-то, пытаешься упорно подставить ТС, бросаясь аббревиатурами, про которые он не спрашивал.

Без этих «аббревиатур» нормальные backup-ы тоже невозможны. Т.е. для того, чтобы какое-то средство можно было использовать для backup, оно должно уметь снимать консистентную копию хотя бы по состоянию, как если бы сервер в какой-то момент её снятия «упал» (для правильно снятого pg_basebackup этот момент (почти или полностью) совпадает с моментом его завершения), но также это средство должно обладать по крайне мере одним другим важным свойством, которое у pg_basebackup (+WAL, или standby) есть, а вот у дампов практически отсутствует. Ты хоть знаешь, что это за свойство?

Вобщем, акстись, пожалуйста, не пакости тут людям, дорогой анон.

No you.

Прекрасно, ты пытаешься съехать теперь :)
Ой, всё :)

Прекрасно, ты пытаешься съехать теперь :)

Кто это тут пытается съехать?! Чушь про консистентность дампов спорол и в кусты?

Ты вообще понимаешь, что с тобой разговаривали разные anonymous-ы?

Лол, даже я вижу, что разные.

Да.

мда, много букв.

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

C pgBackRest (уже давно как входит в официальный репозиторий pg)

Гиговую базу дампить - норм, но не будет point-in-time recovery. Зато дампом можно делать upgrade и не бекапить ненужные данные, таблицу с логами или что-то такое.

Если нужен архив и PITR: Barman - самая простая штука с кучей док и ответов на stack overflow WAL-G - если нет своей надёжной железки для хранения и хочется бекапиться в облако. Или если ты и есть Облако. pgBackRest и pg_probackup - если до этого дошло, то ты уже хорошо знаешь что делаешь.

(пилю WAL-G для прода Яндекса)

Гиговую базу дампить - норм, но не будет point-in-time recovery. Зато дампом можно делать upgrade и не бекапить ненужные данные, таблицу с логами или что-то такое.

Ещё раз: дамп --- не backup. И это так даже для очень маленьких баз, как этом примере, но, чаще всего, по другой причине: с одного только pg_dump может тупо не получиться корректно восстановиться.

Если нужен архив и PITR: Barman - самая простая штука с кучей док и ответов на stack overflow WAL-G - если нет своей надёжной железки для хранения и хочется бекапиться в облако. Или если ты и есть Облако. pgBackRest и pg_probackup - если до этого дошло, то ты уже хорошо знаешь что делаешь.

Есть и стандартные средства, кстати... но да, лучше что-то из вышеперечисленного.

(пилю WAL-G для прода Яндекса)

Что, естественно, не делает необходимый для DBA минимум знаний обязательным для вас (я не издеваюсь, это в самом деле так --- вы разработчик). Но, в таком случае, не надо так уж смело давать советы DBA, ладно? ;)

https://www.postgresql.org/docs/current/static/app-pgdump.html

pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently.

В PG не так просто прочитать данные вне MVCC snapshot-а. Это касается и COPY TO и pg_dump.

//x4m

Хотя, в той же доке и правда написано что надо добавлять --serializable-deferrable

Use a serializable transaction for the dump, to ensure that the snapshot used is consistent with later database states

Странное противоречие доки, надо прояснить этот вопрос.

pg_dump is a utility for backing up a PostgreSQL database.

Да, я знаю, что там это написано. Опять-таки, написано, очевидно, каким-то разработчиком. :(

В PG не так просто прочитать данные вне MVCC snapshot-а. Это касается и COPY TO и pg_dump.

А почему вы думаете, что моё замечание как-то относится к snapshot-ам вообще? ;) Попытайтесь «накатить» дамп любой нетривиальной базы на чистый кластер, и (когда она не заработает нормально/вообще) сразу выяснится, что pg_dump снимает не всё (кстати, в v11 будут улучшения на эту тему).

Странное противоречие доки, надо прояснить этот вопрос.

Я про это уже писал --- дамп, снятый без этой опции, по-хорошему, не подходит для DWH, а вот для recovery это неважно, т.к. этих later database states просто нет. :)

Ну, в общем, там где где не подойдёт pg_dump, там не подойдёт резервная копия, основанная на журнале опережающей записи. Надёный вариант - остановите базку :)

Повторю свой тезис: гиговую базу дампить - норм.

--serializable-deffered, кстати, имеет смысл только если вы со смыслом используете уровень изоляции SERIALIZABLE.

Ну, в общем, там где где не подойдёт pg_dump, там не подойдёт резервная копия, основанная на журнале опережающей записи.

Нет, это совсем не так. Прочитайте мои сообщения выше, например:

Т.е. для того, чтобы какое-то средство можно было использовать для backup, оно должно уметь снимать консистентную копию хотя бы по состоянию, как если бы сервер в какой-то момент её снятия «упал» (для правильно снятого pg_basebackup этот момент (почти или полностью) совпадает с моментом его завершения), но также это средство должно обладать по крайне мере одним другим важным свойством, которое у pg_basebackup (+WAL, или standby) есть, а вот у дампов практически отсутствует. Ты хоть знаешь, что это за свойство?

А вы знаете, что это за свойство? ;)

Повторю свой тезис: гиговую базу дампить - норм.

От повторения этот тезис вернее не становится. Вы читали мой ответ?

--serializable-deffered, кстати, имеет смысл только если вы со смыслом используете уровень изоляции SERIALIZABLE.

Ну, не только (т.к. это работает, используете вы SERIALIZABLE или нет), но, действительно, если вы вручную управляете блокировками (SELECT ... FOR UPDATE и т.п.), то для вас это неважно.

*какие 2-3 тулзы используется большинством как de-facto?*

Использую pg_dump -Fc и pg_restore, но у меня база всего 5г.

А вы знаете, что это за свойство? ;)

Я не сторонник общения загадками.

Т.е. для того, чтобы какое-то средство можно было использовать для backup, оно должно уметь снимать консистентную копию хотя бы по состоянию, как если бы сервер в какой-то момент её снятия «упал»

В доке написано, что pg_dump - средство бэкапа, снимает консистентно. Если это не так - давайте конструктивно фиксить доку. Писать в pgsql-hackers и разбираться что не так с pg_dump.

Единственная аномалия возможная в pg_dump без --serializable-deffered - связана с сериализуемыми транзакциями, фиксация которых допущена с отличием логического порядка от физического. В остальном, если вы не доверяете pg_dump - то вы можете также недоверять и обычному select _ from и СУБД не СУБД. Все воркеры pg_dump читают из одного MVCC снепшота в режиме REAPEATABLE READ, READ ONLY.

Я не сторонник общения загадками.

Ладно. Свойство очень простое: длительность восстановления должна быть прогнозируемой. У pg_basebackup (и других основанных на бинарных копиях (+ WAL) решений) оно (в отличие от дампов) есть.

В доке написано, что pg_dump - средство бэкапа, снимает консистентно.

Я, вроде, уже не раз писал, что одной только консистентности недостаточно.

Если это не так - давайте конструктивно фиксить доку. Писать в pgsql-hackers и разбираться что не так с pg_dump.

Да, пишите. Можно только пожелать Вам удачи, т.к. разработчики PostgreSQL, внезапно, тоже (в большинстве своём) не DBA.

Единственная аномалия возможная в pg_dump без --serializable-deffered - связана с сериализуемыми транзакциями, фиксация которых допущена с отличием логического порядка от физического.

Да, в плане консистентности это так (или почти так, не помню точно, что там происходит при конкурентном DDL, т.к. дампы почти не использую).

В остальном, если вы не доверяете pg_dump - то вы можете также недоверять и обычному select _ from и СУБД не СУБД.

Да, могу и не доверять, в некоторых случаях (вышеупомянутого конкурентного DDL, например). Но в этих случаях можно хотя бы MVCC-unsafe statements при конкурентной активности просто не использовать (либо ждать maintenance window, либо (иногда) можно переписать DDL так, чтобы от них избавиться).

Все воркеры pg_dump читают из одного MVCC снепшота в режиме REAPEATABLE READ, READ ONLY.

По умолчанию, да. Но Вы опять-таки забываете, что, во-первых, pg_dump снимает не всё, на самом деле относящееся к конкретной базе (например, пользователей, настройки...) --- т.е. на «чистом» кластере база может просто не заработать после «восстановления». И, во-вторых, кое-что pg_dump просто не dump-ит. Можете попробовать (как и многие до Вас) ещё раз поднять соответствующие темы в -hackers или -bugs... только вот «конец немного предсказуем». :(

Ладно. Свойство очень простое: длительность восстановления должна быть прогнозируемой. У pg_basebackup (и других основанных на бинарных копиях (+ WAL) решений) оно (в отличие от дампов) есть.

Время восстановления дампа довольно стабильно. Для гигабайтной базы время восстановления может стать проблемой только при наличии индексов с долгим построением, но это не будет очень уж долго. Я ничуть не против WAL-based резервных копий, просто для маленьких баз настройка архива может быть неоправданно сложной. Проще, кстати, взять managed database, где всё настроено за вас.

Да, пишите. Можно только пожелать Вам удачи, т.к. разработчики PostgreSQL, внезапно, тоже (в большинстве своём) не DBA.

Я пока не увидел конкретных проблем.

не помню точно, что там происходит при конкурентном DDL

Ничего особенного, LOCK TABLE %s IN ACCESS SHARE MODE устраняет все проблемы MVCC-unsafe DDL. https://github.com/postgres/postgres/blob/master/src/bin/pg_dump/pg_dump.c#L6567

на «чистом» кластере база может просто не заработать после «восстановления»

Может не восстановится без проблем, да. Проблемы, к сожалению, могут сопровождать любой способ восстановления резервной копии, могут возникнуть вообще на ровном месте в работающей базе.

Можете попробовать (как и многие до Вас) ещё раз поднять соответствующие темы в -hackers или -bugs

Я пока не увидел проблемы. Наверное, потому что я разработчик :)

только вот «конец немного предсказуем»

Кажется, я не видел commitfest item с доработкой док, который бы не был принят.

Время восстановления дампа довольно стабильно.

Это, эээ... «интересная» фраза. ;) Для данного конкретного дампа и данных настроек кластера время восстановления, наверное, довольно стабильно (а для других настроек на том же железе может запросто отличаться в несколько раз, например).

Но суть в том, что задача состоит совсем не в восстановлении одного дампа снова и снова, а в восстановлении, например, последнего снятого с этой базы. И данное время восстановления может очень сильно отличаться для дампов, снятых, например, вчера и сегодня (потому что кто-то добавил десяток GIST индексов, или парочку materialized view). Т.е. час накатывания дампа может легко превратиться в день --- прощай, RTO! (И, в некоторых «особо удачных» случаях --- здравствуй, банкротство организации!)

Конечно, для гигабайтных баз это, скорее всего, не так важно.

Для гигабайтной базы время восстановления может стать проблемой только при наличии индексов с долгим построением

Не только.

, но это не будет очень уж долго.

А может, и будет. Вы RTO каждой такой базы знаете? ;)

Я ничуть не против WAL-based резервных копий, просто для маленьких баз настройка архива может быть неоправданно сложной.

Сложно, не сложно, это правильное решение, в отличие от...

Я пока не увидел конкретных проблем.

Я не понимаю, зачем мне повторять одно и то же (по поводу длительности восстановления)? Это фатальный недостаток, других просто не нужно, чтобы сделать дампы непригодными для backup в общем случае.

Ничего особенного, LOCK TABLE %s IN ACCESS SHARE MODE устраняет все проблемы MVCC-unsafe DDL.

Возможно, я этот код подробно не читал.

Может не восстановится без проблем, да. Проблемы, к сожалению, могут сопровождать любой способ восстановления резервной копии, могут возникнуть вообще на ровном месте в работающей базе.

Нет, не нужно путать тёплое с мягким, я считаю, т.е. оправдывать неправильный выбор инструмента в конкретном случае тем, что мир вообще несовершенен. ;)

Я пока не увидел проблемы. Наверное, потому что я разработчик :)

Вы искать в указанных mailing lists пробовали? Например: https://www.postgresql.org/message-id/20160229183023.GA286012@alvherre.pgsql

Или попробуйте сделать pg_dump только что созданной пустой базы, потом «DROP SCHEMA public;», сделайте дамп ещё раз... и найдите отличие в этих дампах.

Кажется, я не видел commitfest item с доработкой док, который бы не был принят.

Ну так пишите, чего же Вы ждёте? ;)