Melkij

sudo rm -rf /var/lib/postgresql

Это был home dir пользователя, а не каталог кластера. Каталог кластера в дефолтной поставке в /var/lib/postgresql/версия_pg/ещё_одна_директория_main_или_base

sudo mkdir /media/ad/data/bd1c

Допустим.

su postgres -c '/usr/lib/postgresql/9.6/bin/initdb -D media/ad/data/bd1c --locale=ru_RU.UTF-8'

Внимание на относительный путь. Я не уверен, где в итоге initdb пытался сделать базу.

привел к виду
data_directory = '/var/lib/pgsql'

? Откуда это здесь взялось?

какой из postgresql.conf главнее

Тот, который указан в аргументах запуска postgres. Явным образом через -c config_file либо находящийся в PGDATA в случае отсутствия аргумента с именем конфига.

Отмонтируйте файловую систему и сделайте глупый dd if=/dev/md0 of=/dev/раздел большого диска. И будет копия целиком файловой системы со всеми софт/хардлинками, разреженными файлами и всем чем надо. Затем resizee2fs для расширения ФС до ёмкости раздела.

А если вы хотите плавно заменить массива на более ёмкие - то вам вообще файлы копировать не надо. Добавить диски побольше, подождать синхронизацию, удалить старые диски и сделать resize2fs ru.stackoverflow.com/a/637847/203622

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

Это raid4 с отдельным диском под хранение избыточности.
В 5 и 6 избыточные блоки размазываются равномерно по всем дискам массива, а не выделяется отдельный диск для хранения избыточного блока.

/sys/block/md?/md/stripe_cache_size поправили? Bitmap внутренний/внешний/отключен? С внутренним производительность записи тоже неплохо просаживается.

Попробуйте выключить package diff: https://debian-administration.org/article/439/Avoi...

Это актуально для raspberrypi, где и видел комментарий, что на слабых cpu pdiff лучше выключить. Вам вероятно тоже поможет.

Софтовый рейд вас не ограничивает глупостями вроде 1 диск может быть только в одном массиве. Можно разделы одного диска объединять в разные массивы.
Пилить диски можно как угодно. Например, распилить 3тб диски каждый на два раздела: по 1 и по 2тб каждый. Собрать в итоге два raid5: 3 тома по 1тб и три по 2тб. Итого 6тб форматированной ёмкости, допустимо выпадение любого диска массива. При необходимости в едином куске места - поверх этого развернуть LVM.
Наращивать можно дисками любого размера, условие одно: добавляемый том не меньше используемого размера тома в действующем массиве.

Про raid5 в домашних NAS - у меня два диска разом за 8 лет не умирало. Дефолтно в debian включен кроновый скрипт верификации всех софтовых рейдов раз в месяц. Пару дисков проблемных он и обнаружил заблаговременно.
Но вот два диска разом выпасть из массива - это было. Кабель питания отошёл. Собрать обратно массив удалось, а вот ФС побилась. Но у меня был бекап, потеряны только неважные данные.

Если нет никакой возможности использовать географически-удалённое место для бекапа, то для бекапа можно выделить области на этих дисках. Только не в составе чего-то сложного (lvm, raid) и не на том же диске, где лежит основная копия! Можно использовать raid1 при необходимости продолжать работу при отказе диска - зеркало хоть восстанавливать просто и достаточно одного любого диска.
Например, порезать 3тб диски на два раздела: 2тб и 1 тб. Затем собрать raid5 на трёх 2тб томах - под всякое не очень нужное. Три раздела по 1 тб - под важные данные. Можно собрать raid1 из двух дисков. Но не как зеркало из всех 3 дисков! Это только от физической поломки поможет, а от проблемы с ФС - уже нет. Один раздел не должен быть примонтирован постоянно, монтируется только на время бекапа основной части. rsync в кроне как самый простой вариант. Лучше бы, как уже советовали, 3 независимых тома: актуальная копия, горячий регулярный бекап, последний диск под холодный бекап, его физически отключать (можно сколхозить автоматический девайс для размыкания цепей на твердотельных реле).

swap в наличии. Так что описываемое поведение вполне норма, когда начинает подходить к концу свободная памяти и ОС лезет в swap (что можно проконтролировать вызовом free при начале проблем). Немного странно выглядят падения расширений, но, возможно, их отстреливает хром за слишком долгий отклик.
Для начала стоит покрутить swappiness, чтобы ОС лезла в свап только в крайнем случае.
Затем поиграть в Zswap, zram. Что порежет производительность CPU, но поможет от нехватка памяти.

Раз на всё памяти не хватает - то есть варианты действий:
- отчаянно тормозить в свапе
- звать на помощь OOM killer, который будет убивать какой-нибудь на его усмотрение бесполезный процесс. Для этого достаточно вырубить swap и ядро само позовёт при необходимости.
- добавлять память
- уменьшать потребление памяти. Следить, кто сколько памяти жрёт, может у вас кто-нибудь не особо нужный просто течёт по памяти. Можно запускать текущие процессы в cgroup с жёстким лимитом памяти, тогда они будутт отстреливаться при превышении лимита.

https://habrahabr.ru/post/312900/
К сожалению, пока потребуется отдельная видеокарта для каждого места.

Странное что-то рассказываете. У вас железо-то вообще исправно? memtest?
sysrq жив? Скорей всего жив, раз вы можете на tty переключиться. Посмотрите, что ядро ответит https://en.wikipedia.org/wiki/Magic_SysRq_key

Будет работать. Даже fstab править не нужно.
Дополнительные действия нужны будут, если захотите как-то использовать свободное место с бОльшего диска.

Если правильно помню, Tor архитектурно открывают кучу соединений. А дебиан недавно вывесил зеркало пакетов напрямую в tor: https://habrahabr.ru/post/307208/
Попробуйте.

UPD: неправильно помню. Tor работает поверх одного соединения, которое периодически изменяется.
Полезных мыслей пока нет.