Melkij

А вы как думаете?

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

Может быть допустимо в случае чего потерять данные до двух месяцев, может быть вам критично потерять данные уже за час - это вопрос именно к потребностям и оценки рисков конкретного сервиса.

Аналогично с вопросом "за какой срок хранить бекапы" - за тот, который нужен и согласны оплачивать (сотня террабайт под бекап как-то не очень бесплатные).

Когда появляются требования ко времени восстановления из бекапа - то почти наверняка уже доросли до полноценного PiTR и лучше рассматривать именно полновесный бекап postgresql, чем сооружать снэпшоты.
Берёте pgbackrest, настраиваете архив WAL, желаемую периодичность снятия basebackup и сроки удержания. Ну либо barman или wal-g, тут по вкусу, смысл тот же.

Получаете полностью корректный с точки зрения самой базы снэпшот (ака basebackup), а так же возможность восстановиться на произвольную точку времени, а не только на момент снятия слепка. Без штрафа производительности записи от снэпшота LVM, без CoW файловых систем.

Реплика - не бекап, решают разные задачи. Реплика ответит на вопрос "как быстро мы можем восстановить базу при полном отказе основного сервера", но не ответит на вопрос "как быстро можем восстановить удалённую табличку". Если у вас важная база и всё ещё нет реплики - ну, это странно =)

Никак.

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

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

Единственное возможное исключение: если ваша функция шифрования обязуется быть immutable в терминах postgresql, т.е. на один и тот же ключ и исходные данные генерировать всегда один и тот же бинарно идентичный результат. Тогда делаете индекс по parent_iin и ищете по условию where parent_iin = функция_шифрования(данные, ключ) то есть по зашифрованному представлению данных.

Это должны быть те /sys/class/net/*, у которых существует /sys/class/net/$iface/wireless

HDD - это расходники. Нет смысла обсуждать "меньше" или "больше" проживут. Сдохнут гарантированно. Если повезёт, то ещё в гарантийный период - бесплатно поменяете.

Для SOHO разница между линейками по большей части неважна. Вот что стоит уточнить - SMR или CMR диск и готовы ли с этим мириться. Достаточную ли вам предлагают скидку за террабайт, чтобы вляпываться в SMR. В одной и той же линейке дисков могут быть одновременно и SMR и CMR диски, уточнять нужно модели.
Далее, скорость вращения диска. 7200 чуть быстрее, 5400 медленнее но их попроще охлаждать в среднем. Различие скорости для личной медиатеки скорей всего неважно, но на достаточно хорошем интернет-канале торренты могут заметно озадачить массив количеством IO.

Зеркало будет надежно или лучше пожертвовать местом и сделать raid5 или 6?

Звучит как полное непонимание вопроса. Каким местом жертвовать, если именно зеркало даст меньше всего форматируемую ёмкость массивов? Местом придётся жертвовать, если делать как раз зеркало.
На примере шести 10ТБ дисков для удобства счёта, из 60ТБ RAW ёмкость массива:

raid0 или JBOD - дадут вам все 60ТБ, выпадение любого диска фатально.
raid1 - зеркало - даст вам как максимум 3 массива по 10ТБ, до 30ТБ форматируемой ёмкости. В каждом массиве соответственно можно потерять по соседнему диску. То есть хранилка выпадение одного любого диска переживёт, выпадение второго диска - смотря какому из дисков не повезёт. Можно потерять один из массивов полностью. (raid1 на всех 6 дисках вряд ли входит в вопрос, 10ТБ итоговой ёмкости, но чтобы их потерять из-за отказа диска нужно чтобы отказали все 6 дисков)
raid5 - даст вам 50ТБ форматируемой ёмкости. Переживёт выпадение одного любого диска, выпадение второго диска - фатально для всего массива.
raid6 - ближайший родственник raid5 - даст вам 40ТБ ёмкости. Но зато гарантированно переживёт выпадение любых двух дисков. Только отказ третьего будет фатален для массива.
raid10 - даст вам 30ТБ ёмкости как raid1, гарантированно выдержит выпадение одного диска, в идеале может работать на только половине дисков массива но критично зависит от структуры raid10, какие именно номера дисков могут быть потеряны без краха всего массива. Отказ второго диска может оказаться фатален. Используется не когда нужна ёмкость или возможность пережить несколько выпавших дисков, а когда нужна производительность, особенно на запись. То есть вряд ли ваш случай.

Что ещё надо упомянуть - вот диск из массива умер, сколько времени вам нужно это заметить, купить новый на замену, заменить? Плюс на таких объёмах займёт ещё сутки-двое-трое на восстановление массива. Вот тут причина, почему существует RAID6, хотя он по ёмкости хуже RAID5 и не лучше по производительности - пока у вас массив деградировал до 5/6 дисков, он переживёт выпадение ещё одного из дисков пока вы ставите замену и массив восстанавливается.

У яндекса весьма медлительные сетевые диски, совершенно верно. Именно по latency, что куда более критично для СУБД чем обещанная полоса пропускания или IOPS (которые у большинства хранилок предполагают совершенно абсурдную для СУБД глубину очереди команд).

resize2fs /dev/centos/home с указанием размера файловой системы с каким-то запасом, до 400ГБ например обрезать. Критично следующим шагом не обрезать часть файловой системы.
lvresize /dev/centos/home до желаемого размера
lvresize /dev/centos/root до желаемого размера
resize2fs /dev/centos/home
resize2fs /dev/centos/root