Евгений Хлебников

Плоховато с планированием, возможно потому, что плоховато с пониманием бизнес-процессов.

Для текущей работы компании важнее что - архив старых писем или новые письма, которые приходят прямо в эту минуту? В 99% рабочих ситуаций важнее новые письма. Вам нужно в первую очередь планировать действия так, чтобы вся новая почта куда-то дошла и была доступна сотрудникам, а не пропала в "безвременье", когда старый почтовик уже недоступен, а новый ещё не совсем доступен из-за какой-то упущенной детали. Поэтому при правильном планировании у вас должен быть промежуток времени, когда доступны одновременно старый и новый почтовые сервера. Причём, доступны как для ваших пользователей, так и для внешнего мира, из которого вам что-то присылают.
Для внешнего мира это означает всего лишь две MX-записи в DNS. Потом вы поменяете приоритет этих записей. Дождётесь обновления во внешнем мире. Потом снова оставите только одну запись. До этого нужно прочитать и понять, как работают приоритеты MX.

Отдельно планируете, в какой момент вы замените исходящий сервер на новый. Тут совсем другая история, при замене исходящего никакая внешняя почта не потеряется, уже проще. Но зато нужно подумать о SPF, DKIM, DMARC, которые влияют только на отправку во внешний мир.

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

Итак. Напишите подробный план действий, обязательно. Сделайте это самостоятельно, полагайтесь не на чужие инструкции, а на собственное понимание. У всех организовано не одинаково и без понимания чужие инструкции могут ввести в заблуждение. А вот читать теорию до просветления, написать свой план, потом прийти сюда и сказать, "чуваки, у меня такой план, укажите на ошибки если они есть" - это бы совсем другое дело.
Из вышесказанного, ваш план на самом верхнем уровне будет состоять из трёх пунктов: (1) перенос входящего SMTP, (2) перенос исходящего SMTP, (3) перенос архива старых писем. Не зацикливайтесь на третьем пункте, он наименее важный.

Неохота разбираться с формами, но работать с датами надо не полагаясь на дефолты, которые зависят от локали.

Просто используйте универсальные работающие варианты $date.ToString('yyyy-MM-dd HH:mm:ss')

а настройки php?

upload_max_filesize = 100M
post_max_size = 100M
memory_limit = 256M

каким кодом файл принимаете?

Вам нужен один хороший роутер и проложить провода до стационарных потребителей (например до ПК или телевизора).
На 55квм этого будет достаточно.

Если ставить fluentbit из helm, то там уже все есть, только output прописать в файле values.yaml,
В любом случае можно найти этот хелм чарт и посмотреть как там сделано

Настроить xrdp или vnc и xserver для работы с ними и подключаться к серверу по протоколу, поддерживающему графический интерфейс. В гугле много информации по запросам vps with gui и т.п.
Либо установить и использовать что-то типа selenoid

купить видеорегистратор hiwatch \ hiksivion и подключить в него камеры по onvif \ rtsp

Ваш вариант с распбери и дороже и хуже

1. В PATCH технически можно передавать больше 1 значения на изменение. Правильно ли это?

См Json patch
https://en.wikipedia.org/wiki/JSON_Patch
Вообще RFC не обязывает тебя использовать именно json patch, а потому и нельзя сказать, можно ли передать больше одного значения. Это всё на усмотрение разработчика.

2. Фактическое отличие между всеми тремя методами лишь в том

Различие только в том что они предназначены для разного и "разное" лучше черпать из спецификации HTTP.
https://www.ietf.org/rfc/rfc9110.html
POST: https://www.ietf.org/rfc/rfc9110.html#name-post
кратко - можно использовать для всего что не GET.
В теле передаётся что угодно, в зависимости от назначения.

PUT: https://www.ietf.org/rfc/rfc9110.html#name-put
кратко - полная перезапись ресурса (из-за этого этот метод идемпотентен)
В теле передаётся весь ресурс целиком.

PATCH: про него отдельный rfc https://www.ietf.org/rfc/rfc5789.html
кратко - для частичной модификации ресурса (как конкретно будет производиться модификация - это уже детали реализации. Можно использовать уже упомянутый json patch, можно что попроще или просто другое, но из-за такой гибкости он является неидемпотентным).
В теле передаётся описание того, как нужно модифицировать ресурс.

PathVariable тут вообще никаким боком не стоит. Если у твоей сущности есть какой-то id и для её чтения ты пишешь что-то типа GET /documents/42, то тогда и изменение тоже должно быть через PUT(PATCH) /documents/42
А создание документа будет, скорее всего, через
POST /documents

Но это только если ты пытаешься следовать REST или подобным штукам.
Если у тебя тупо RPC, то тогда лучше использовать только POST

Смотря для чего. Судя по вашему описанию достаточно будет просто запустить какую-нибудь ось в vitualbox.

На компе есть игры. Значит пара свободных гиг оперативы и несколько потоков процессора найдется.