Алексей Пьянов

Установите внутри контейнера Supervisor и уже в нем описывайте Ваши команды.

Сначала делаем backup.
При наличии root доступа штатно linux переносится даже простым tar!

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

Затем восстановление - и тут могут быть проблемы.
Универсально все будет работать только с не openvz/lxc/docker системами виртуализации, так как такие могут тупо не позволить работать с версиями системных библиотек (очень редко), отличных от хоста... а у тебя древняя ubuntu (я запускал в chroot просто утилиты, развернув образ с помощью debootstrap еще до появления docker, так что технически шансы проблем - минимальны). Дело в том что хостер может запретить, а точнее не дать инструментов для подмены системных файлов, а из самой работающей системы заменить ее саму нельзя (очень сложно).

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

Если виртуальная машина kvm/vbox/vmware/... то проблем не будет от слова совсем. Чтобы развернуть бакап, понадобится на новом месте загрузиться в консоль восстановления (лучше с iso образа), отформатировать файловую систему и тупо распаковать архив с бакапом (обычно /dev в архив не складывают, но если его не будет на новой системе то я помню старые версии ubuntu ругались на отсутствие null, это все решается ручным копированием тут же), затем переустановить загрузчик

grub-install /dev/sdX --root-directory=/path/to/mounted/root/

Ну и само собой архитектура исходной машины и новой должны совпадать, т.е. нельзя смешивать ни тип процессора (x86/arm ни битность x86/x64), правда особых проблем с запуском x86 на x64 быть не должно.

Самый простой способ это подсмотреть точный дистрибутив, как я понял это Ubuntu 16.04, нужно задеплоить на новом VPS точно такой же сервер с Ubuntu 16.04, и затем с помощью команды rsync, вроде такой:

sudo rsync -aAXvP — exclude={/boot/,/dev/,/etc/fstab,/etc/modprobe*,/etc/modules/,/lost+found/,/etc/mtab,/etc/network*,/etc/sysconfig/ip*,/etc/sysconfig/kernel,/etc/sysconfig/network*,/lib/modules/,/media/,/mnt/,/proc/,/run/,/sys/,/tmp/,/var/lib/lxcfs/,/var/lock/}  root@mysite.ru:/ /

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

PS
В целом можно потом на той же машине на которую скопировался сайт попробовать обновить дистрибутив до 22.04 и уже на новую впс если всё взлетит (нужно проверить весь функционал), уже ставить систему с поддержкой, т.к. 16.04 закончилась в августе 2021.

Доступ в админку в VPS есть?
Если есть возможность загрузиться с загрузочного диска подключив VPSку
То можно каким нибудь акронисом, снять образ рабочей системы и потом развернуть его на новом VPS провайдере.

согласен с опубликованными ответами в части "Перенастроить"
при наличии доступа только к ssh (надеюсь, админского) относительно просто будет попробовать rear - relax and recover
Бэкап на шелл-скриптах и базовых утилитах. При переносе могут быть проблемы только с зеркалами на btrfs и, может, udev, если основа виртуалки "другой системы"

Устанавливать по новой все библиотеки/настраивать все конфиги не вариант

Чтобы следующий раз не страдать. Настройте ещё раз, но теперь с помощью Ansible.

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

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

1) процесс дискретного финансирования со стороны инвесторов. Логика следующая: если сайд проект нужен миру, то это значит, что с помощью сайд проекта можно заработать, а один из вариантов - купить долю в момент первой нарезки пирога.

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

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

4) можно переехать в страну из доступных вам с самым большим уровнем жизни, а команду набирать в стране с низким уровнем жизни. При этом вы будете больше менеджерить и находить клиентов будет проще.

5) можно продолжать схему, по которой вы уже что-то делаете. Наверное, просто стоит научится извлекать ошибки из прошлого опыта. Если такой сложный MVP, что у вас успевает core team распасться, может быть у вас не MVP вовсе? На энтузиазме больше двух недель работать могут только два друга, которые решили стать "духовными братьями", все остальное нужно чем-то питать.

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

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

1. https://tldp.org/LDP/abs/html/process-sub.html
2. bash это интерпритатор, вы всегда можете вставить куски выражения, и посмотреть что они выдают, например:

echo <(ls -1 .)
/dev/fd/63

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

shopt -s nullglob
for f in my_temp_dir/*; do
    echo "$f"
done

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

«В молодости я спросил у начальника, как оценить время на выполнение работы? И начальник ответил мне:
— Время, которое ты планируешь, умножить на Пи пополам, плюс 2 недели.
— Почему Пи пополам? — удивился я.
— Потому что в реальной жизни ты никогда не будешь двигаться к своей цели напрямую, а скорее — по дуге окружности.
— А почему плюс две недели?
— А потому, что когда ты в итоге просрёшь все сроки, то за две недели хоть что-то успеешь сделать.» (с)

Libre Office

LFS