N

фронтэнд - это приложение (html+css+javascript) для веб-браузера, запускается у пользователя, оно должно быть создано таковым, что бы делать запросы к бакэнду

бакэнд - это приложение (другое), запускаемое на сервере, которое обеспечивает функцианирование всей системы (но бывает оно не единственное). Обычно бакэнд состоит из готового веб сервера (например nginx/apache или майкрософтовский IIS , который выполняет большую часть рутинных операций, включая отдачу статичных файлов, те самые html, css, javascript, точнее те что не меняются в процессе работы приложения) и приложения/модуля (php или к примеру майкрософтовский asp.net), который отдает динамический контент - файлов, содержимое которых меняется в зависимости от запроса фронтэнда.

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

Разделяют два подхода к реализации всего веб-приложения (обычно это не тригер а нестрогий выбор, типа 'немного первого подхода и в основном второго'):
1. на каждое действие пользователя (клик по разным страницам сайта и элементам интерфейса типа меню) бакэнд заново формирует html (и по необходимости все остальное) а веб браузер это отображает.
В этом подходе javascript не требуется, браузер практически не тратит ресурсы, но тратятся ресурсы сервера и нагружается сеть между ними.
2. все что касается интерфейса реализуется на javascript в браузере, html формируется на javascript, но данные и операции, отсылаются на сервер к бакэнду в виде относительно небольших (по сравнению с html интерфейса) файлов-запросов (формат и структуру этих запросов часто приходится разрабатывать самостоятельно, но есть хелперы).
Исторически сложилось, что данные от бакэнда удобнее передавать в текстовом виде в формате .json, а вот от фронтэнда к бакэнду исторически отправляют в виде multipart/form-data (то что отправляет на сервер html конструкция из тегов form, input, textarea и т.п.). Но это естественно не обязательные требование, и ничто не мешает и с клиента отправлять запросы в виде json, а так же вместо json использовать свой формат, например в браузер (и его javascript) встроено куча инструментов для отправки бинарных данных (например XMLHttpRequest).

Очень много ограничений и требований накладывает выбор среды разработки, например при использовании visual studio asp.net, все будет завязано на майкрософтовскую инфраструктуру, начиная с деплоя и кончая собственно работы бакэнда.. Но как бонус, я отчетливо помню (при использовании WinForms) приложение для веб разрабатывалось точно так же как для десктопа, с очень небольшими отличиями, и при этом это работало в браузере (если честно отвратительно, но кто сейчас смотрит на качество реализации).

p.s. есть еще старый но все еще рабочий способ, формирования страницы на клиенте с помощью xslt (это язык шаблонизатор для получения html), а сервер отправляет xml файл с данными. Можно упороться и реализовать все на таких шаблонах, что они не будут требовать javascript но работать все будет на стороне клиента с очень эффективной тратой ресурсов как сервера так и сети.

Как мне их правильно соединить?

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

Или frontend и backend размещены разными программами?

что-то мне подсказывает что наверное вы рановато по знаниям взялись за задачу...

В общем в гитхабе сказали делать так:

You need to use

$book->increment('some_value', extra: ['full_name' => $book->full_name]);
or
$book->increment('some_value', extra: ['full_name' => Str::random()]);
or
$book->increment('some_value', extra: $book->getDirty());

Т.е. указываем какие поля сохранять вместе с инкрементом ... так себе решение.

5xx - это ошибка сервера (раньше работало, а тут вдруг приболел чаво-то). Что-то типа - зовите админов и будите программеров, пусть чинят!
И это надо чинить!
А теперь представь, что спам-бот начинает запрашивать несуществующие страницы.
И что? Звать всю команду чинить это? Нет.
Это уже проблемы юзера, что он запрашивает то, чего не может быть

Пусть Федот проявит прыть, Пусть сумеет вам добыть. То-Чаво-На-белом-свете- Вообче-Не-может-быть

P.S. А сам вопрос интересный, буду задавать на собеседованиях

ЕСЛИ треугольник прямоугольный ТО квадрат гипотенузы равен сумме квадратов катетов

Отсюда не следует, что

ЕСЛИ квадрат гипотенузы равен сумме квадратов катетов ТО треугольник прямоугольный

Правильное обратное утверждение:

ЕСЛИ квадрат гипотенузы НЕ равен сумме квадратов катетов ТО треугольник НЕ прямоугольный

Простейший аналог:

ЕСЛИ животное это собака ТО у неё четыре лапы ⇏ ЕСЛИ у животного четыре лапы, ТО это собака
ЕСЛИ животное это собака ТО у неё четыре лапы ⇒ ЕСЛИ у животного НЕ четыре лапы, ТО это НЕ собака

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

ЕСЛИ треугольник прямоугольный ТОГДА И ТОЛЬКО ТОГДА квадрат гипотенузы равен сумме квадратов катетов

Зачем проксмокс? там будут еще виртуалки?
делайте обычный mdadm для данных
на виртуалке какой смысл делать рейд? его надо делать на хранилище...
raid 1+0 называется raid-10

mailcow \ roundcube

С резким ростом популярности React Server Components и Next.js в последнее время происходит некий сдвиг в понимании, что такое фронтенд.
BFF уже почти становится неотъемлемой частью "фронтенда", и становится обременительно разделять браузер и сервер на разные команды.
На Западе, вообще, уже очень давно и макетами, и вёрсткой, и анимациями очень часто занимается один человек - дизайнер, фронтендеры занимаются связкой браузер + BFF, а бэкендеры занимаются более сложной бизнес-логикой.
К тому же, джуниорам зачастую дают те задачи, которыми сами не хотят заниматься, и на что нет времени. Т.е. это что-то занудное, работа с legacy, передвижение кнопки на 5px влево и т.д. Крайне редко джуниорам дают интересные творческие задачи. Не факт, что вам на новом месте не дадут такие же неинтересные задачи.
Вы можете либо молча сильно стараться в надежде, что вам потом дадут что-то интересное, заметив ваше рвение, либо, лучше всего, пообщаться по-человечески с коллегами и начальством, объяснив, что вы рветесь в бой, а вас в тылу держат. Попросите рассказать об их планах на ваш счёт.
Не исключено, что у вас как раз хорошо получается "Настройка тестов, CI/CD, OLAP CUBE, оптимизация запросов к БД", и поэтому вам эти задачи и дают)
В общем, человеческое общение с коллегами очень часто решает проблемы.
Если же вы к ним придёте с открытой душой, а вас токсично отошьют, вот тогда подумайте о смене работы.

Veeam Backup не хранит файлы как они были в оригинале, а создает что то типа архива в своем формате, со своими технологиями сжатия и дедупликации, поэтому файловая система не найдет в них копий.

Дедупликация это в принципе очень слабый механизм сжатия данных, который срабатывает в ограниченном количестве случаев (пофайлово, а точнее поблочно), когда ты делаешь копию файла и чуть чуть его редактируешь (меняя только его часть, вот например текстовые, если ты вставишь/удалишь символ в начале, это сдвинет содержимое всего файла и он будет считаться полностью изменившимся, но замена одного символа в начале позволит хранить только тот блок, в котором было это изменение, а остальное содержимое будет ссылаться на оригинальный файл)