Melkij

Задача минимумум: прочитать файлы, содержащиеся в образе.

mount -o loop,offset=$((512*start_сектор_нужного_раздела)) file mountpoint
или losetup с параметром модуля ядра loop.max_part в какое-нибудь адекватное значение - тогда будут loop устройства с разделами как обычное блочное устройство.

Задача максимум: и прочитать файлы и засунуть виртуалку в Proxmox, в качестве хранилища использующий LVM на CephFS.

Сделать LV по меньшей мере такого же размера, скопировать весь файл поблочно через dd

Повесить дополнительный IP на интерфейс, перевесить веб-сервер туда и обратиться к этому адресу.
Или банально воткнуть $_SERVER['REMOTE_ADDR'] = 'any another ip'; где-нибудь до проверки. $_SERVER не защищён от записи. Только не забыть удалить перед коммитом.

Да, будут потеряны.

Во время переезда на массив часто массив инициализируют деградировавщим:
mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/hdc1
Затем копируют на него данные и потом добавляют недостающий диск.

select json_agg(tablename) from tablename;
Всё. Получите json массив.

Недостаточно данных. Разные storage engine будут вести себя разным образом. Для транзакционных storage будут иметь значение уровень изоляции транзакции и собственно как именно реализована транзакционная обработка в обоих приложениях.

innodb, read commited, транзакционная работа писателя: читатель увидит версию данных как будто писатель ничего ещё не делал.
innodb, read commited, нетранзакционная работа писателя/autocommit - читатель увидит какой-то промежуточный результат, что-то обновлено, что-то ещё нет.
myisam - подождёт завершение пишущего запроса (только мешающего запроса! Следующий пишущий запрос постоит подождёт завершение читающего запроса), прочитает текущее состояние

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

Суть для вашего случая: разметить sdb, инициализировать как degraded массив:
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb1
mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb5
Перенести всё полезное с sda на sdb, поправить загрузчик, перезагрузиться с рейда, добавить разделы sda в соответствующие массивы.
Инициализировать массив напрямую на устройство, а не разделы, возможно, но с этого устройства нельзя будет загружаться.

Разные фокусы с переносом всего полезного. Системный раздел может быть проще через dd скопировать (но раздел на sdb должен быть чуть больше, там ещё mdadm суперблок в 2048 секторов)
/home - начальную копию в 2-3 прохода rsync'ом, затем перемонтировать в ro и ещё один rsync.

Всё очевидно:
суперпользователь базы - лицо доверенное и база доверяет этому пользователю. И суперпользователь множеством хитрых и не очень способов способен сделать с сервером на котором запущена база всё на что хватит прав у пользователя, от которого запущен postgres.
Например, запустить любую произвольную команду даже простой и очевидной командой copy, не говоря уже о каких-то извращениях.

Конкретная атака по-видимому уже разобрана и описана вот тут: https://habrahabr.ru/post/351452/

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

Вы предполагаете слишком умную логику для глупой функции.
https://github.com/php/php-src/blob/PHP-7.2/ext/st...
var_export пытается вывести строку в одинарных кавычках, чтобы в ней не осуществлялись подстановки спецсимволов и другого счастья. Но null-байт поэтому же в одинарных кавычках вывести нельзя. Поэтому все \0 заменяются на ' . \"\\0\" . '
В предельном случае получаются как раз одинарные кавычки по краям результирующей строки и ' . \"\\0\" . ' в качестве основных данных. А проверять предварительно, что у нас всего-то и есть \0 в строке -- слишком частный случай.

2. Нужно ли включать order by в таких огромных таблицах?

Не зависит от размера базы.
Или у вас есть order by и поведение ожидаемое или у вас нет order by и СУБД имеет полное право на каждый запрос выдавать любые подходящие под фильтр данные в любом порядке.
Запрос выдающий неправильные данные обычно никому не нужен, даже если он и быстрый.

offset для пагинации вообще вещь неуклюжая. https://use-the-index-luke.com/no-offset
Быстрая пагинация - это передача уникального идентификатора, последнего на просматриваемой странице. Т.е. запрос на выборку следующих 100 записей начиная после такого-то id.
Бонусом консистентное поведение, если, например, что-то из строк предыдущей страницы удалили. Оффсет тупо потеряет строку из выборки и пользователь может не найти то что искал.

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

Вы изобрели то что делает джойн. База в общем случае его сделает лучше.
Будет ли огромная временная таблица - смотрите план.

В пределах одного сервера СУБД - сделайте view. При наличии прав у пользователя к другим БД этого же самого хоста обращаться может.
На другой сервер - насколько мне известно невозможно.

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

Неверно полностью.

Кратко алгоритм:
- коммутатор получает пакет на порту
- заносит mac отправителя в таблицу адресов, ассоциируя таким образом mac и физический порт, к которому подключено устройство
- проверяет, есть ли mac получателя пакета в таблице
- если есть - отправляет пакет только в этот порт
- если нет - отправляет на все порты кроме того, откуда пакет пришёл

Из таблицы вычищаются адреса, от которых не было пакетов в течении определённого времени (в настройках коммутатора если такие такая, типично 5 минут)

pg_repack - это community extension, форк более раннего pg_reorg. И не отрицая вклад участников pgpro в разработку postgresql в целом - я не вижу их среди контрибьютеров pg_repack.

Мы активно используем обе. Основные моменты касательно pg_repack vs pgcompacttable в общем-то именно я и изложил в README компактора. Если говорить на русском:
- pg_repack делает копию таблицы, т.е. требуется двукратный запас диска. Компактор работает в рамках одной таблицы и требует место только под копию наиболее толстого индекса и то, толстые индексы обрабатываются самыми последними. Т.е. расчёт на работу когда места уже мало.
- компактор намеренно выполняется медленно чтобы не задевать работающий проект
- компактор не может обрабатывать toast таблицы. Репак - может.
- pg_repack характеризуется очень заметными пиками io и wal. Вся таблица едет одной транзакцией и это никак не регулируется. Поэтому может аффектить прод на неважных дисках и в том числе оторвать реплики при недостатке сетевой полосы.
- pg_repack умеет перемещать между tablespace и может делать команду cluster

(или лучше подстроить автовакум)?

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