VPS — не хранилище кода: как не потерять мини-приложение

Мини-приложение может работать на VPS, но его код не должен существовать только внутри этого сервера. Документация Beget показывает важное ограничение: автоматическая резервная копия VPS сохраняет файлы, но не гарантирует полноценное восстановление всей рабочей среды. Для базы данных нужны отдельные средства, а при удалении сервера доступ к его копиям может исчезнуть.

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

Что именно делает VPS для мини-приложения

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

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

Но «код работает на VPS» и «код надёжно хранится на VPS» — разные утверждения.

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

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

Документация Beget описывает автоматическое копирование файлов виртуальных выделенных серверов. Копии хранятся на отдельных серверах в другом дата-центре, а управлять ими можно в разделе Backup. Это полезный слой защиты, но не замена репозиторию и не универсальная копия приложения.

Почему резервная копия меняет расчёт стоимости и риска

На бумаге мини-приложение может состоять из нескольких файлов. На практике его работа зависит от большего набора элементов:

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

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

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

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

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

Как разделить код, данные и восстановление

Для мини-приложения удобно использовать три разных уровня хранения.

Что меняется	Почему важно бизнесу	Что проверить
Исходный код хранится вне VPS	Сервер можно заменить без потери проекта и истории изменений	Есть ли отдельный репозиторий и кто имеет к нему доступ
Рабочая версия запускается на VPS	Пользователь получает доступ к приложению через постоянно работающую среду	Понятно ли, какая версия сейчас запущена
Файлы VPS попадают в автоматические копии	Можно вернуть часть файлов после повреждения сервера	Какая дата последней копии, её размер и доступен ли режим восстановления
База данных копируется отдельно	Потеря файлов проекта не равна потере пользовательских данных	Где лежат копии базы и кто проверял их восстановление
Секреты и настройки описаны отдельно	Новый сервер можно настроить без поиска значений вручную	Есть ли безопасная инструкция без публикации ключей в коде
Полное восстановление проверено заранее	Команда знает реальное время простоя, а не предполагает его	Запускалось ли приложение после восстановления на тестовой копии

Это не требование конкретного провайдера, а рабочая модель управления риском. Документация Beget описывает возможности файлового резервного копирования VPS; разделение ответственности между репозиторием, сервером и базой — практический вывод для команды.

Код следует считать переносимым артефактом. VPS — среда его выполнения. Резервная копия — дополнительная защита среды и файлов. Если эти роли смешать, любое восстановление будет зависеть от того, насколько точно удалось сохранить внутреннее состояние одного сервера.

Что проверить до запуска, а не после сбоя

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

Эти сведения отвечают на базовый вопрос: «Есть ли копия?» Но владельцу приложения нужны более конкретные ответы:

Насколько свежей будет копия, если сбой произойдёт в рабочий день?
Что именно команда восстановит отдельными файлами?
Что произойдёт с базой данных?
Кто сможет выполнить восстановление?
Где взять код, настройки и инструкции, если сам VPS недоступен?
Сколько времени займёт повторный запуск приложения?

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

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

Где автоматическое восстановление не сработает

Файловая копия не включает ряд системных каталогов и файлов, среди них /boot, /tmp, /proc, /dev, /run, /sys, /var/cache, swapfile и отдельные компоненты гостевого агента VPS.

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

Есть два разных сценария сбоя.

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

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

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

Практическая схема для небольшой команды

Для мини-приложения без большого IT-отдела достаточно зафиксировать несколько правил.

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

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

База данных должна иметь собственную процедуру копирования и проверки. Файловая резервная копия VPS не заменяет такую процедуру — это прямо следует из ограничений Beget для сервисов, которым требуется специальный механизм резервирования.

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

Наконец, нужно определить владельца восстановления. Это может быть разработчик, системный администратор или подрядчик, но имя и порядок действий должны быть записаны. Фраза «разберёмся при необходимости» — не план восстановления.

Что сделать на этой неделе

Ниже — короткая проверка, которую может провести руководитель или операционный менеджер вместе с исполнителем.

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

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

Главная мысль не в выборе конкретного хостинга. Серверный код должен жить в управляемом репозитории, работать на VPS и восстанавливаться по проверенной процедуре. Только в таком разделении мини-приложение остаётся рабочим активом компании, а не единственной папкой на виртуальной машине.