Эта инструкция для проекта на Ubuntu 24.04 или 26.04: сайт, бот или сервис с файлами, базой и, возможно, контейнерами Docker. Перенос обычного сайта на хостинг описан в статье перенос сайта на другой хостинг. Все команды ниже подставляйте со своими именами: deploy это пользователь, 203.0.113.20 адрес нового сервера, site и appdb примеры названий.
Перед любым переносом сделайте резервную копию на старом сервере. Как её организовать, написано в статье резервные копии VPS. Команды копирования ничего не удаляют на старом сервере, но ошибка в пути может перезаписать файлы на новом.
Команды из разделов 2–4 мы выполнили 6 октября 2026 года на VPS с Ubuntu 24.04 (rsync 3.2.7, MariaDB 10.11, PostgreSQL 16, Docker 29): файлы, обе базы и том Docker перенеслись без потерь, кириллица в базах сохранилась. Переключение DNS на живом домене не проверяли.
1. Подготовьте новый сервер
Сначала пройдите первую настройку VPS: обновления, пользователь, вход по ключу, файрвол. Затем установите те же программы и версии, что на старом сервере: веб-сервер, среду выполнения, СУБД, Docker. Версии на старом сервере смотрите командами вроде nginx -v или docker --version.
Заранее понизьте TTL записей DNS у домена (время, на которое чужие серверы запоминают адрес). В панели DNS поставьте минимальное разрешённое значение, например 300 секунд, и подождите старый TTL: пока он не истёк, понижение не вступило в силу.
2. Перенесите файлы через rsync
Выполняйте команду на старом сервере:
rsync -az --progress -e ssh /var/www/site/ deploy@203.0.113.20:/var/www/site/rsync копирует только отличающиеся файлы. Ключ -a сохраняет права, владельцев, даты и ссылки, -z сжимает данные при передаче, --progress показывает ход копирования, -e ssh передаёт данные по SSH. Слэш в конце пути источника важен: с ним копируется содержимое папки, без него папка целиком создастся внутри целевой. Папка /var/www/site/ на новом сервере должна существовать, и пользователь deploy должен иметь право писать в неё.
Одна оговорка про владельцев. Прежних владельцев файлов rsync восстанавливает, только если на новом сервере он работает от root. При копировании под обычным пользователем, как в команде выше, все файлы на новом сервере будут принадлежать этому пользователю: у нас так и вышло, права и ссылки при этом сохранились. Если проекту нужны другие владельцы (например, www-data для сайта), назначьте их после копирования командой sudo chown -R.
Для входа по ключу ваш ключ должен быть на новом сервере: либо добавьте ключ старого сервера пользователю deploy, либо запускайте rsync с вашего компьютера. Повторный запуск той же команды добавит только изменения. Перед финальным переключением остановите запись на старом сервере и выполните её ещё раз.
Чтобы сначала посмотреть, что будет скопировано, добавьте ключ -n (пробный прогон): файлы не копируются, а только перечисляются.
3. Перенесите базу данных
MySQL и MariaDB
На старом сервере:
mysqldump --single-transaction -u appuser -p appdb > appdb.sqlmysqldump выгружает базу в текстовый файл с командами восстановления, --single-transaction делает согласованный снимок для таблиц InnoDB без блокировки сайта, -p спросит пароль. В новых версиях MariaDB команда называется mariadb-dump, параметры те же.
Скопируйте файл (rsync -az appdb.sql deploy@203.0.113.20:~/) и на новом сервере создайте базу и загрузите дамп:
sudo mysql -e "CREATE DATABASE appdb CHARACTER SET utf8mb4;"
mysql -u appuser -p appdb < appdb.sqlПервая команда создаёт пустую базу (пользователя и права создайте так же, как на старом сервере), вторая загружает в неё дамп.
PostgreSQL
На старом сервере:
sudo -u postgres pg_dump -Fc appdb > appdb.dumppg_dump выгружает базу, -Fc задаёт сжатый формат, подходящий для pg_restore. На новом сервере:
sudo -u postgres createdb appdb
sudo -u postgres pg_restore -d appdb --no-owner < appdb.dumpcreatedb создаёт пустую базу, pg_restore загружает в неё дамп, --no-owner не пытается назначать прежних владельцев объектов (роли, если они нужны, создайте заранее).
4. Перенесите тома Docker
Данные контейнеров лежат в томах. Остановите контейнеры, чтобы файлы не менялись, и на старом сервере упакуйте том (название app_data подставьте своё, список даёт docker volume ls):
docker compose stop
docker run --rm -v app_data:/data -v "$PWD":/backup alpine tar czf /backup/app_data.tgz -C /data .Вторая команда запускает временный контейнер Alpine, который упаковывает содержимое тома в архив в текущей папке. Такой же приём описан в статье про установку n8n. Скопируйте архив на новый сервер через rsync, затем распакуйте:
docker run --rm -v app_data:/data -v "$PWD":/backup alpine tar xzf /backup/app_data.tgz -C /dataТом app_data создастся сам, если его не было. Файл docker-compose.yml и .env скопируйте вместе с остальными файлами проекта, затем запустите docker compose up -d.
5. Проверьте до переключения
Запустите проект на новом сервере и проверьте его, не меняя DNS. Для сайта удобно временно прописать адрес нового сервера в файле hosts на своём компьютере: домен будет открываться с нового сервера только у вас. Пройдите главные сценарии: вход, формы, платежи, отправку почты. Проверьте, что задачи по расписанию (cron) и сертификаты настроены так же, как на старом сервере: бесплатный SSL на VPS.
6. Переключите DNS
Остановите запись на старом сервере (режим обслуживания, остановка бота), повторите rsync и дамп базы, загрузите свежую копию. Затем смените в панели DNS адрес в A-записи на адрес нового сервера. Благодаря низкому TTL большинство посетителей перейдёт за минуты, но часть кэшей может обновляться дольше.
Не удаляйте старый сервер сразу. Оставьте его выключенным или хотя бы с остановленными службами на несколько дней: если что-то пойдёт не так, вы вернёте старый адрес в DNS. Удалять можно после того, как новый сервер отработал полный цикл, включая ночные задачи и резервное копирование.
Что делать дальше
Если новый сервер ещё не выбран, откройте подбор VPS и сравните тарифы. Размер сервера удобно прикинуть по занятому месту и памяти старого: об этом в статье как понять, что серверу не хватает ресурсов. После переезда сразу настройте резервные копии.