Vitaly Karasik

1. API
2. Сервера могут общаться через базу данных
3. Сервера могут общаться через брокер очередей
4. Можно подумать насчет общего стораджа - S3, распределенная файловая система, просто сетевой диск замапленный на каждый сервер.

Вопрос не в том, чтобы "как связать", вопрос зачем вам это надо, как вы себе представляете "связывание" и какая у него цель?

Для pitr вам нужен:
- basebackup как основа, должно быть завершено его снятие до датывремени требуемого восстановления pitr
- непрерывный архив всех и абсолютно каждого сегмента wal без пропусков от момента checkpoint перед снятием используемого в восстановлении basebackup и до требуемой точки восстановления

database system was shut down at 2022-02-10 13:31:25 UTC
starting point-in-time recovery to 2022-02-10 07:00:00+00

Это, конечно, невозможно даже с корректным архивом WAL.
У postgresql REDO recovery, а не UNDO. Pitr только вперёд от текущей позиции. И не раньше достижения точки консистентности состояния (окончания снятия basebackup)

Чтобы не ходить по граблям консистентности ещё и файловой системы, basebackup предпочтительнее снимать с самого postgresql, а не снимком блочного устройства. Но в целом вариант предусмотренный, ничем неотличимый от обычного crash recovery вроде старта после пропадания электричества (лишь бы fsync работал на всех уровнях корректно и не игнорировался).

Можете отвечать этим выпендрёжникам, что computer science у всех в школе была.

Теоретически, это можно сделать, если хешировать/солить ваш пароль на клиенте и не передавать на сервер.
Практически, это все равно остается вопросом доверия между вами и сайтом - сегодня они не передают пароль при авторизации, завтра фронтенд Василий шото напутал, и пароль улетел не только в базу сайта, но и к кампании, которая предоставляет аудит пользовательских метрик.

в общем случае это невозможно
docker файл это список команд, которые необходимо выполнить на 'нулевой системе' чтобы приложение заработало

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

в некоторых случаях, пакетный менеджер linux предлагает вполне законченное описание того что нужно для того чтобы приложение заработало, к сожалению в реальности не все так просто, не все приложения корректно описаны, а для некоторых требуется ручная первоначальная настройка

Безопасность вещь комплексная и многое зависит от конкретной реализации. То что в одном месте закрывается (и то не факт, так как не известна реализация) один вектор мало влияет на общую безопасность.

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

Хотите комплексно подойти к вопросу? Копайте в сторону изучения материалов от OWASP. Например, https://owasp.org/www-project-web-security-testing... Там достаточно много материалов для чеклистов. Или смотрите готовые чеклисты что проверять. Например, https://github.com/0xRadi/OWASP-Web-Checklist (я не говорю что это прям лучший чеклист, но посмотрите на число пунктов для быстрой оценки).

Хотите подойти еще комплексней? Начните с книги для новичков по поиску узявимостей - Ловушка для багов. Полевое руководство по веб-хакингу | Яворски Питер https://www.piter.com/product_by_id/196618476

А далее например обратите внимание на более сложную книгу как строить защиту в приложениях
Безопасно by design | Берг Джонсон Д., Деоган Д., Савано Д. https://www.piter.com/product/bezopasno-by-design
Там уже более основательно доводится доводится мысль как выстраивать защиту на основании архитектуры.

Если по теории, то мне в свое время вот эта книга помогла:
https://www.litres.ru/robert-s-martin/chistaya-arh...

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

Через несколько месяцев прочел еще раз, анализируя все затупы, что записал за это время в блокнот. После прочтения начал потихоньку рефакторить в существующих проектах места, которые уж очень жить мешали.

Еще через пол года прочел третий раз, опять же с оглядкой на личный опыт. И тут я кажется уже совсем въехал. По крайней мере многие проблемы с организацией взаимодействия между компонентами стали разрешаться. И вообще появилось достаточно четкое понимание, как структурировать приложение и где разбивать его на компоненты.
Ну и после 3 прочтения еще помог момент: мне дали с нуля проектировать новое, достаточно крупное приложение на Rust. Притом заказчик кричал "микросервисы - это круто, хочу, хочу, хочу", а тимлид мне сказал "давай монолит, но так чтоб потом легко было распилить, а то все сроки про**ем". Вот тут прямо вообще понимание пришло. Ну и плюс в Rust архитектурные компоненты очень хорошо ложатся на отдельные крейты (это такая единица компиляции в Rust), а компилятор в принципе не дает делать циклические зависимости между крейтами.

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

Это нормальная практика, когда тестировщик итеративно смотрит сырые варианты. В определенных ситуациях это лучше, чем сделать готовый вариант, отладив программистами все баги и понять, что надо то было совсем другое.

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

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

У вас вероятно очень специфические задачи если производительности ноутбука за "цена вопроса не имеет значения" вас не устраивает.
Ноут лучшее решение.
Альтернативы:
Переносной накопитель. Ниже производительность, нужны современные интерфейсы, ниже надёжность, выше риск утраты включая возможность компрометации информации.
Любая форма rdp или удаленного ПО. Зависимость от сети.
Скриптованное окружение. Высокая сложность, издержки поддержки скриптов.

Ноут лучшее решение, в стационарных условиях к нему подключается внешний монитор или два.