rPman

Именно функционал клонирования, причем запущенного, есть у систем виртуализации, если физически машины имеют одинаковое железо то, на этом даже основаны системы резервирования приложений, позволяющие не прекращать их работу (доля секунды пауза) даже после смерти одной из машин (Fault Tolerance как часть High Availability у vmware).

Если речь идет о переносе настроек, то в большинстве случаев достаточно определить место их хранения и скопировать только их. Можно проконтролировать как именно приложение устанавливается на машину с помощью монитора работы с диском и реестром (этого обычно достаточно) например приложения microsoft sysinternails

На практике никто конечно не решает это проблему в лоб, на целевую машину производят штатную установку приложения, а затем копируется реестр (с помощью штатного regedit) из HKLM и HKCU /Software/.. и и файлы из appdata (плюс собственно файлы приложения, где их хранят)

Если брата с linux нет а самому в linux ковыряться нет желания, то берешь установочный диск windows той версии что у тебя стоит (включая ревизию и битность, например если стоит home версия то не получится использовать ultimate для починки), загружайся в консоль восстановления и восстанавливай загрузочный раздел

вернется брат он вернет и починит grub

p.s. если чинить тебе - то livecd в руки, проверяй что файлы на месте и grub-install

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

Тебе же советую заниматься подобным с VPS-ок установленных в датацентре, либо с помощью VPN перенести выход своих подключений туда где провайдер таких ограничений не делает

В зависимости от того, как именно создан exe файл, а точнее какая именно версия java и как распространяется вместе с приложением.

В подавляющем большинстве случаев, windows сборки (например oracle java или или от redhat) ограничены лицензией на распространение, т.е. разработчики не имеют права распространять даже просто установщик jre вместе с приложением (полагаю можно получить персональное разрешение), а пользователь при загрузке таковой с офф сайта должен принять лицензионное соглашение.

Так вот в java имеется официальный метод деплоя приложений без необходимости установки jre на машину (это начиналось с javafx packager и подхвачено почти всеми пакерами в т.ч. launch4j), а сама java прикладывается к приложению в виде пакета .dll (т.е. там нет ни одного exe-шника), в этом случае на машине клиента ничего не нужно настраивать и устанавливать и не требуется принимать никакие лицензии.

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

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

гугли: transparent socks proxy iptables
учти трафик пойдет только tcp, без пингов, udp и броадкастов

В конечном счете все решает стоимость решений

Выделенный сервер (dedicated server upd или bare metal) - это буквально физический сервер, мощности которого принадлежат тебе и твоим программам
Виртуальный сервер (virtual private server) - это когда физический сервер делят на части и продают по отдельности, что сильно дешевле, и удобнее хостеру (он может перекидывать виртуальные машины между физическими, оптимизируя нагрузку), мало того он может оверселить, продавая и обещая больше мощности чем доступно в среднем, надеясь что пиковую нагрузку сервис клиента будет давать редко а остальное время она будет низкой (так обычно и бывает), такие машины обычно самые дешевые (когда видишь предолжения ниже ~30$ это оно самое)

Кстати нормальная практика даже для dedicated server жесткие диски заменять на NAS например iscsi, а реальный диск предлагать как опцию. Сетевые накопители обычно медленней но сильно дешевле для хостера, так как их так же можно делить, снапшотить (например за их счет делать дешевый бакап) и оверселить (а главное централизованное обслуживание, так как диски чаще всего выходят из строя).

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

Но нужно понимать что фишки гибкой конфигурации даются не бесплатно и если у тебя постоянная нагрузка, VPS оказываются дороже dedicated server. Правильный подход кроется в комбинировании.

И еще одна услуга у хостеров - предоставление не сервера а услуги - доступа к програмному обеспечению по какому то внутреннему алгоритму тарификации (Software As A Service). Например можно приобрести услугу http сервера (или к примеру хостинг nodejs бакэнда, отдельно базы данных, сервиса бакапов и т.п., такие точно есть), без покупки самой машины, с тарификацией по запросам, трафику или по внутренним cpu тикам, при этом пользователю не важно, сколько там в реальности задействовано серверов, хостер будет обеспечивать заказанный трафик с обещанной скоростью, только плати. Такие крупные провайдеры как гугл или амазон могут встраивать в свои прайсы на такие сервисы ловушки, не изучив и не подготовившись как следует к которым можно попасть на значительное повышение стоимости, к тому же часто такой доступ еще и привязывает клиента к конкретному провайдеру, так сильно что когда придет известность и нагрузка, может не получиться легко сменить хостера на более оптимальный.

Самое простое и правильное - в файле, как есть, для удобства обслуживания в файловой системе, контейнер которой отделен от всего остального (лучше отдельный раздел или диск, но при особой бедности - файл, который можно примонтировать в любой фс, например в windows это .vhd/.vhdx образы, а в linux вообще просто образ диска в raw формате), зачем отдельное устройство? - для упрощения обслуживания, когда там будет миллион файлов... в linux настоятельно рекомендую пользоваться cow fs (btrfs/zfs/xfs) ради встроенных бесплатных транзакций на основе снапшотов, плюс инкрементальные бакапы эффективно делать.

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

Во многих случаях рекомендуется не хранить много (десятки тысяч) файлов в одном каталоге, отсюда сразу напрашивается способ - если имя файла состоит из цифр (или hex или вообще base64, на выбор) то разбив его на фиксированной длины части можно использовать их как имена каталогов, последняя часть - имя собственно файла в них (типа /datastore/0d6a/011fc/0012.jpeg).

Достоинства
- для web, файлы очень эффективно могут быть отданы веб сервером (при необходимости права доступа разруливаются basic auth либо временными симлинками, хз что дороже)
- с файлами могут работать огромное количество утилит, поиск, копирование, редактирование, просмотр.. напрямую, когда как с любым другим хранилищем сначала файл придется от туда извлечь, т.е. понадобится соответствующий инструмент

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

p.s. ну или вот qna.habr.ru/q/10694/#answer_46206