denn

использовать для копирования rsync с подтверждением передачи по хеш-подписи файла - даст 100% достоверность правильности передачи файла.
такто tcp-канал имеет систему подтверждения достоверности передачи пакетов и досылку пакетов с неправильной подписью, так что проблемы в железе, рам/носитель обрабатывают данные с ошибками.

Имею похожу ситуацию, центральный офис + 2 отдаленных предприятия, на каждой точке по 20-30 камер. Задача организовать диспетчерские телевизоры, а это 3-4 и каждый хочет смотреть свой набор камер с разных точек. Изучая вопрос, стало понятно, что подключаться напрямую к камерам - это не верный вариант, канал накрывается медным тазом, как бы ты его не расширял, а так же сами камеры имеют ограничение на одновременное подключение по onvif. Сейчас стало понятно, что на каждом таком объекте необходимо поднимать ретранслятор потоков (мультиплекс, мультикаст), он собирает внутри объекта все камеры и дальше уже отдает условно 100 потоков, но при этом канал будет выглядеть примерно как на 1-2 подключения. Некоторые регистраторы типа dahua умеют поднимать свой сервер мультиплекса, но реальных примеров в интернете очень мало. Есть платные онлайн сервисы которые забирают твой поток и отражают его в личном кабинете - это тоже рабочий вариант, учитывая затраты на какой-то "мини-сервер мултиплекса" и весь последующий геморрой. Так же на github есть наработки, но все это довольно узкие инструменты, которые еще и не всегда заводятся. Еще в китайских региках появился протокол GB28181 - на нем работают китайские городские системы, можно поднять сервер и даже передавать изображение на стационарный ip-телефон с дисплеем по sip-протоколу, но опять же там черт ногу сломит, информации очень мало. Если кто-то поднимал такие структуры, буду признателен за дополнения и информацию! Удачи.

Как вариант хочу поставить гипервизор Proxmox и перенести базы сервера с винды на Linux.

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

И как быть с лицензиями 1С сервера? И какие подводные камни существуют?

Это к 1С, у них очень замудренная система лицензирования.
Раньше можно было купить ПО на какуюто сумму и сдавать его в аренду, сейчас не знаю нужно смотреть, или запросить у них на сайте условия.
С пираткой от 1С связываться не советую, очень многие попадают именно на 1С-ке на реальные уголовные дела.

Идея выполнима только в одном случае: если Вы являетесь единственной организацией обслуживающей всех клиентов, конфы у клиентов однородные;
Не слишком понятно также, что именно планируется - один общий Сервер 1С (на нем все конфы клиентов), один Сервер БД (на нем все бд клиентов) или для каждого клиента всё своё (полная копия его инфраструктуры)
С лицензиями как раз все просто, их можно будет переактивировать на новых серверах (без каких-либо проблем)
В целом идея сумасшедшая, т.к. при наличии проблем - лягут все клиенты; Уж лучше как есть, каждый на своем сервере;

Node-red, можно реализовать гибко свои сценарии, я вот интеграцию asterisk и битрикс24 на базе node-red сделал, создаются лиды, создаются звонки, прикрепляются звонки из астериск в битрикс. Интегрировал веб формы - с сайтов http запросом передается в node-red а node-red пуляет в битрикс, сделал умный дом себе. Короче много чего сделал

Делаете виртуалку http-гейт, ставите туда nginx, certbot - и проксируете.

PowerDNS Admin



PDNS Manager

10 юзеров - слишком мало для строительства локальной VDI инфраструктуры.
Если их будет хотя-бы 50-70 тогда еще норм
Потому как, нужен кластер хотя-бы N+1, т.е. минимум 3 физических сервака, хотя-бы по 10-15 юзеров на сервак, а лучше по 20-30, чтоб ресурсы легче перераспределялись.
Иначе, Вы заводите весь офис на единую точку отказа, встанет сервак - встанет все.
Ну и 10 комплектов десктопного железа, обойдется дешевле и практичней 1 надежного серверного железа

На счет 1 RDP почитал, там ведь зависеть будет от пользователей. А вдруг у кого-то крашнется ПО, то есть вероятность уйти в ребут или тупо зависнет ))

Пока рано вам переводить сотрудников.

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

сразу же, по логам - с одним из дисков проблемы.

Aug 14 12:32:26 nikita-desktop kernel: [  361.490159] device offline error, dev sdc, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Aug 14 12:32:26 nikita-desktop kernel: [  361.490164] Buffer I/O error on dev sdc, logical block 0, async page read
Aug 14 12:32:26 nikita-desktop kernel: [  361.490184] device offline error, dev sdc, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Aug 14 12:32:26 nikita-desktop kernel: [  361.490190] Buffer I/O error on dev sdc, logical block 0, async page read
Aug 14 12:32:26 nikita-desktop kernel: [  361.490219] device offline error, dev sdc, sector 24 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Aug 14 12:32:26 nikita-desktop kernel: [  361.490226] Buffer I/O error on dev sdc, logical block 3, async page read

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

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

Использовать С++ можно на любой системе, но:
1. С++ нужно знать. Погуглил и в продакшен - не выйдет. Быстро заклинит в глубоком непонимании ошибок, которыми сыплет компилятор.
2. С++ - это не быстро и не гибко (программу нужно всерьез писать, собирать и отлаживать, и так для любого изменения). Для формошлепства, где реально не требуется оптимальное использование ресурсов - совершенно избыточно.
3. Есть же альтернативы. И у Питона гуи найдутся, и Электрон какой-нибудь, на худой конец. Есть смысл изучать их и не городить.

Итого: искренне полагаю, что вам С++ не надо. Ничего хорошего из этого не выйдет.