Melkij

pg_basebackup
Сделает консистентную физическую копию базы. Соответственно размер бекапа примерно равен размеру кластера postgresql + накопленные за время копирования WAL.
Восстанавливаться элементарно запустив postgresql с указанием PGDATA в место где лежит результат pg_basebackup.
Им обычно реплики поднимают.

pg_dump или pg_dumpall
Логический бекап данных. Обычно не очень подходит по критерию быстро восстанавливаться т.к. при восстановлении будут перестраивать индексы, проверять fk и прочие constraint, зато как правило сильно (в пару раз без сжатия легко, со сжатием ещё больше разница) компактнее по размеру бекапа

Все из штатной поставки Postgresql. И другие способы бекапа Postgresql в основе своей опираются на них же.

Как по скорости и надежности такая схема по сравнению с просто RAID5 из всех дисков

По скорости лучше, т.к. запись можно просто распараллеливать. По чтению - надо замерять, хуже быть не должно.
По надёжности лучше:
raid5 переживёт выпадение одного любого диска из массива - но только одного. Два - развал массива со всеми данными.
Два raid5 объединённых в логический диск - гарантированно переживут смерть одного любого диска, при определённой доле везения - переживут смерть второго диска (если тот отвалился из другого массива).
С большим числом дисков (имхо, больше 6 дисков) лучше использовать RAID6, который переживёт смерть любых двух дисков массива, а по производительности одноклассник RAID5. Тем более раз вы один диск всё равно решили держать hotspare (который нифига не поможет пока не будет перестроен массив - для террабайтных томов 2-4 часа полной утилизации добавляемого диска и очень повышенный риск смерти кого-нибудь из остальных дисков массива вместе со всем массивом). Или пару RAID6 в логическую группу, что ещё надёжнее.

3. Какой RAID предпочтительнее для виртуальных машин?

RAID10. Т.к. даёт внятную производительность чтения/записи.

Если не нужен join со значениями, а только фильтр - то

where array(select (j->>'category_id')::int from jsonb_array_elements(data->'items') j) && array[1,3,5];

Можно загнать подзапрос с построением массива в immutable хранимку и повесить по ней gin или gist индекс.

Смотрим операторы: https://www.postgresql.org/docs/current/static/fun...
Печально, прямого оператора как && overlap у массивов нет.

?| text[] Do any of these array strings exist as top-level keys?

Зато тот вполне подходит. Значит, заменить json на jsonb затем запрос будет

select * from t where jsonbfield ?| array['0', '5', '7']::text[];

Если на входе удобен именно json массив, а не pg массив, то относительно просто переписывается одно в другое

select * from t where jsonbfield ?| (select array_agg(t) from json_array_elements_text('["0","5","7"]') t);

gin и gist индексы оператор ?| могут обрабатывать.

Ноутбучным HDD вы даже за возможности SATA1 очень сомневаюсь что выйдете. 150мб/с для HDD - это весьма приличная цифра.
Для механики sata3 имеет смысл только в ту же цену, что и sata2.

isset - конструкция языка
array_key_exists - функция
Очень разные накладные расходы на вызов функции и отсутствие вызова функции.

Используйте pgbouncer.
Лучше всего в режиме transaction пула. Тогда backend postgresql будет выдаваться соединениям от приложения только на время выполнения транзакции. Что позволяет и очень эффективно утилизировать лишь небольшое число процессов postgresql и сохранить возможность транзакционной работы. В режиме транзакций не работают prepared statements, но PDO их и так эмулирует, так что проблемой это не является.

pgbouncer легко держит тысячи открытых соединений с приложением, легко их открывает и закрывает, развлечения начинаются при попытке прокачать через баунсер с гигабит трафика (и обходится банально запуском второго баунсера тут же на другом порту). Обычно размещается на машине непосредственно с базой на 6432 порту.
И вообще-то является фактическим стандартом для инсталляций postgresql.

Если autoremove предлагает удалить пакет автоматически - значит он был установлен по зависимостям, а теперь от него никто больше не зависит. Или каким-то образом были потеряны флаги о ручной установке этих пакетов.

Пакету можно выставить флаг "установлено вручную" через apt-mark, тогда он не будет удаляться через autoremove.
apt-mark manual имя_пакета

Никак. Работает как задумано.

И уже при вставке идет разрыв в id.

sequence не гарантирует неразрывность. И последовательность значений тоже не гарантирует.
Гарантирует только уникальность значений.

#!/bin/bash
apt-get install ..
git clone ...
cd /
rm ...

Переключите PDO::ATTR_ERRMODE в PDO::ERRMODE_EXCEPTION. Если exceptin прилетел - значит запрос выполнен не был.
Не было исключения - значит запрос выполнен.

их хеши со старым равны

И это криптографически плохо. См. стандартные password_hash + password_verify

Разрешите получать ответы на DNS запросы. UDP 53 порт. В OUTPUT разрешено, а в INPUT DROP, конечно DNS работать и не будет.

Официальный установщик из debian-9.1.0-amd64-DVD-1.iso выглядит вот так:

То есть вообще-то сложно сказать, что здесь что-то принято по-умолчанию. Предлагается сразу 6 вариантов по вкусу. Если ничего не выбрать, то да, наверное это будет gnome, как первый в списке.

Для начала немного терминологии, чтобы явно говорить на одном языке.
Кластер postgresql - это один запущенный postgres.
Один кластер может содержать несколько именованных баз данных, но все они обслуживаются одним запущенным postgres.
На физической машине кластеров postgres может быть несколько.

А теперь - что вы хотите сделать?
* перенести директорию базы в другое место. Остановить базу, скопировать rsync'ом datadir куда надо, на старом месте сделать симлинк (datadir в конфиге в этом случае даже не надо править, если поправить пути в конфиге - то не обязателен симлинк)
* оставить одни БД в дефолтном месте, а некоторые другие - в другом, но под управлением одного кластера. Вам необходимо сделать tablespace и использовать его. При create database можно указать tablespace, который и будет считаться по-умолчанию для всех объектов этой базы (но переопределить его можно для каждого объекта)
* запустить отдельный кластер. В одно и то же место вы две базы просто не вставите. Соответствующий, и обычно обязательный, параметр в initdb плюс указать datadir в конфиге или строке запуска базы (зависит от того, как будет запускаться база и где лежать ещё конфиг). А для весьма приятного враппера в debian и ubuntu pg_createcluster параметр --datadir так же есть сразу

см. также Как правильно изменить месторасположение базы postgresql-9.2.18.rl7?