Про снятие "физических" я ровно это и сказал — нельзя к pd_dump применять этот термин. Допустимо использовать термин "Бинарный".

Соответствует ли официальная документация _вашей_ реальности — да, мне это не очень важно.

Я мыслю, значит, постгрес делает дамп

Да, нельзя, я об этом и писал.
"Физические" копии снимает pg_basebackup (и "сторонние" tools, вроде pg_probackup, pgBackRest, Barman и т.п.).

У меня нет отдельной реальности. Раз Вы перешли на мою личность — скажите, а Вы сами-то DBA?
Способны самостоятельно определить, какая технология является backup-ом, а какая нет?

Мне видится вполне логическим следующая интерпритация термина "backup": "создание резервной копии". Далее начинаются варианты создания этой резервной копии, которые и описаны в официальной документации. Мне такая модель видится весьма логически стройной. Вероятно, можно докопаться и до такой интерпритации (которую использую я и сообщество постгрес), но это малопродуктивное занятие.

> "создание резервной копии".

И неважно, насколько эта т.н. "копия" точна, как долго она создаётся и "восстанавливается", восстанавливается ли она успешно вообще, получается ли в результате то, что было скопировано?

> Вероятно, можно докопаться и до такой интерпритации

Вот я и "докапываюсь". ;)

> и сообщество постгрес

Не всё сообщество. Это просто пока написано в документации (а вот документациям (всех?) backup tools для PostgreSQL приходится занудно объяснять, почему это неверно).

> но это малопродуктивное занятие.

Мне кажется иначе. Т.е. отделение мух и котлет (т.е. dump-ов и backup-ов) — полезное занятие.
Потому что многие пытаются использовать дампы не по назначению, и это плохо кончается.

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

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

https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html
https://docs.microsoft.com/en-us/sql/t-sql/statements/backup-transact-sql?view=sql-server-ver15

вакум освободил место, но размер таблицы не изменится

В случае её "физического" повреждения Вы потеряете весь кластер (instance) баз данных (так устроен PostgreSQL).

И нет, всё восстановить таким образом не получится — пользователи и глобальные настройки просто не хранятся в отдельных базах данных, например. И да, см. то, что я написал выше — неизвестно, что именно восстановится и как долго это будет происходить.
Т.е. если Вам нужно надёжное средство для DR, то дампы — это неподходящий инструмент.

Да, вы правы. Только, вроде vaccum с "full" возвращает дисковое пространство ОС

Ну так mysqldump — это тоже не backup, а дамп. Т.е. у них та же проблема... а там вообще есть настоящий backup, кстати?

А в приведённой ссылке на документацию MS SQL подстрока "dump" встречается только в "sp_addumpdevice" (названию функции уже более 20 лет, насколько я помню, т.е. это legacy), что Вы хотели этим продемонстрировать?

Этого достаточно?

Выполнение VACUUM никак не может повлиять на размер дампа — потому что логически в БД в результате его выполнения не меняется вообще ничего — разве это не очевидно?

Достаточно в качестве чего?

Того, что термины дамп и бэкап лежат в одной плоскости.

И того, что "отделение мух и котлет (т.е. dump-ов и backup-ов)" не имеет место быть.

Естественно, лежат (чтобы это точно ни означало). Иначе бы не было этой путаницы, то-то и оно.

Так Вы знаете, есть ли в MySQL настоящие backups в принципе?

В их документации написано logical backups.
А я утверждаю, что это неудачный термин, потому что вызывает путаницу, последствия которой мы наблюдаем прямо здесь и сейчас, не так ли?