Переезд с Render на VPS: приложение, PostgreSQL и загруженные файлы

MAATRIX · 17 октября 2026 · 8 мин чтения

Самый неприятный вариант переезда выглядит убедительно: сайт открывается, вход работает, в таблицах видны пользователи. Через некоторое время клиент пытается скачать старый документ и получает ошибку. Запись о файле успешно переехала, сам файл остался на прежнем диске. Это типичная ловушка миграции приложения, в котором код, база и загрузки хранятся в разных местах.

У Render эти части представлены отдельными ресурсами. Чтобы перенести проект на VPS, нужно составить реестр данных, восстановить их согласованную копию и только затем переключить посетителей. Разберём маршрут для приложения с PostgreSQL, постоянным диском и фоновым работником. Если каких-то компонентов в вашем проекте нет, соответствующий этап можно пропустить.

Инвентаризация: что исчезнет при отключении Render

Откройте проект и выпишите веб-сервисы, базы, фоновые процессы, расписания и постоянные диски. Для каждого ресурса зафиксируйте команду запуска, версию среды, переменные и связи. Проверьте также сервисы, созданные давно и не попавшие в текущую схему развёртывания: забытый работник иногда продолжает выполнять важную операцию раз в месяц.

Разделите данные на три категории. Пересоздаваемые — исходники, зависимости и результаты сборки. Рабочие — записи пользователей, документы, очередь заданий. Исторические — журналы операций и архивы, которые нужны для расследований или внутреннего учёта. Для каждой категории назначьте способ переноса и срок хранения.

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

Репозиторий — отправная точка, но не архив проекта

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

На тестовом сервере сначала соберите приложение без рабочих данных. Ошибки отсутствующих библиотек, несовместимой версии языка и неверного пути проще исправлять отдельно от восстановления базы. Запуск должен быть воспроизводимым: повторное развёртывание из того же коммита даёт ту же версию приложения.

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

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

PostgreSQL: восстановление должно состояться до дня переезда

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

Для переноса подготовьте совместимую логическую выгрузку. Запишите версию PostgreSQL, расширения, роли и размер базы. Восстановите копию в отдельную тестовую базу на VPS. Если инструмент сообщает об ошибках владельцев или отсутствующих расширениях, разберите их: успешное завершение части операций не означает полноценного восстановления.

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

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

Перенос диска без рассинхронизации с базой

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

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

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

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

Фоновый работник должен переехать последним в своей цепочке

В Render фоновые процессы оформляются отдельными сервисами; их назначение описано в руководстве Background Workers. На VPS им тоже нужен собственный управляемый процесс с журналами, перезапуском и доступом к очереди.

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

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

Для теста создайте безопасное задание, остановите процесс в контролируемый момент и проверьте повторный запуск. Не используйте реальный платёж или письмо клиенту как материал для эксперимента. У тестового окружения должны быть собственные ключи внешних сервисов и понятные адреса получателей.

Переключение: домен, письма и вебхуки

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

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

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

План отката должен учитывать свежие данные на VPS. Если после переключения появились заказы, возврат на старую базу без переноса этих записей приведёт к потерям. Иногда безопаснее исправить новую площадку, чем автоматически нажать условную кнопку «назад».

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

Выберите один старый документ с известным владельцем и один недавно загруженный файл. До копирования запишите размер, идентификатор записи и ожидаемый доступ. После переноса скачайте оба через приложение, сравните содержимое и попробуйте открыть их другим тестовым пользователем. Затем замените один файл штатным способом и проверьте, что интерфейс показывает новую версию. Так одновременно проверяются связь базы с диском, права процесса и авторизация. Отдельно удалите тестовую запись и убедитесь, что приложение следует своей политике очистки файлов. Если старый объект сохраняется намеренно для истории, это должно быть отражено в расчёте места и сроках хранения, а не обнаружено случайно через несколько месяцев.

Ресурсы и обслуживание после Render

Для пилота приложения с PostgreSQL и одним лёгким работником можно рассматривать MAATRIX Heka Standard с 4 vCPU и 8 ГБ памяти. Небольшому сервису без тяжёлой базы может подойти Uab Start. Это начальная гипотеза: её проверяют по памяти, времени ответа и длительности очереди на реальных задачах.

Ubuntu или Debian выбирайте по совместимости библиотек и привычному способу сопровождения. Дисковое пространство рассчитайте отдельно: рабочие данные, файлы, временная выгрузка, журналы и запас на обновление. Каталог, заполненный почти полностью, превращает обычное обслуживание в игру на ловкость.

После переезда настройте внешнюю резервную копию и проверку восстановления. Следите за заполнением диска, ошибками приложения и накоплением задач. VPS MAATRIX даст площадку для самостоятельного размещения; порядок обновлений, копирования и реакции на сбой нужно закрепить в вашей рабочей инструкции.

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