Автобэкапы игрового сервера — что и как часто сохраняется

MAATRIX GAMES

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

Что сохраняется в автобэкапе

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

• Файлы мира/сохранения — world и парные world_nether/world_the_end в Minecraft, SavedArks в ARK: Survival и ARK: Survival Ascended, сейв-папка Rust с *.map/*.sav, файлы прогресса в Valheim, Project Zomboid, 7 Days to Die и других survival-играх.
• Базы данных плагинов и модов — SQLite-файлы экономики, статистики, кланов, а также локальные дампы, если БД плагина хранится не во внешнем MySQL/PostgreSQL, а прямо на сервере.
• Конфигурационные файлы — server.properties, permissions.yml, конфиги плагинов и модов, whitelist и ban-листы, серверные пресеты запуска.
• Сами файлы плагинов/модов — plugins/, mods/, addons/, потому что автобэкап не разбирает содержимое папки по важности, он копирует директорию как есть.

Что автобэкап не трогает и не должен трогать: логи (logs/latest.log и подобное) и временный кэш обычно исключаются на уровне снятия копии, чтобы не раздувать архив мёртвым весом, который всё равно ничего не даст при восстановлении. Если у вас внешняя база данных (отдельный managed MySQL, не тот, что живёт на самом инстансе игрового сервера) — она в автобэкап игрового сервера не попадает, это отдельный ресурс со своим циклом резервного копирования. Подробнее о настройке БД под плагины — в статье про MySQL для игровых плагинов.

Периодичность: как часто снимается копия

По умолчанию автобэкап на хостинге работает по расписанию — ежедневный снимок в фиксированное окно (обычно ночные часы по времени локации сервера, когда нагрузка на инстанс минимальна и меньше риск зацепить активную запись в файл сохранения). Для большинства проектов — Minecraft-сервер на 5-20 игроков, RP-сервер FiveM, кооперативный Valheim или Palworld на компанию друзей — суточной периодичности достаточно: в худшем случае откат откинет вас на несколько часов, а не на дни.

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

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

Сколько точек восстановления хранится

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

Панель хранит несколько последних точек восстановления — конкретное число зависит от тарифа, актуальный лимит для своего плана смотрите в разделе бэкапов личного кабинета. Практический вывод: если проблему заметили не в первый час, а через день-другой, не хватайтесь сразу за последний бэкап — сначала посмотрите список доступных точек и выберите ту, что снята до момента, когда всё пошло не так.

Ручной бэкап перед рискованной операцией

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

Кнопка ручного бэкапа находится в том же разделе панели, что и автоматическое расписание — «Создать бэкап сейчас» или аналогичная по смыслу. Разница с автоматическим снимком только в моменте запуска: вручную вы решаете, когда именно нужна точка отсчёта, а не ждёте следующего ночного окна. Это особенно важно, если операция потенциально ломает сохранение необратимо — например, смена мод-сборки на модпак с другим набором ID блоков/предметов, где откат «на файлах» уже не всегда тривиален.

Практика простая:

1. Перед обновлением/установкой — ручной бэкап через панель.
2. Выполняете операцию (обновление ядра сервера, установка мода, правка конфига).
3. Проверяете, что сервер поднялся и работает штатно.
4. Если что-то пошло не так — откат к точке, снятой на шаге 1, а не к случайному автоматическому снимку из истории.

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

Восстановление из бэкапа через панель

Откат к сохранённой точке делается без консоли и без ручной распаковки архивов — весь процесс идёт через веб-интерфейс:

1. Раздел Бэкапы в панели управления сервером.
2. Список доступных точек восстановления с датой и временем снятия — выбираете нужную.
3. Кнопка Восстановить — панель сама останавливает сервер, разворачивает выбранную копию поверх текущих файлов и запускает сервер обратно.
4. Дожидаетесь статуса «Запущен» и проверяете, что мир/сохранение открылось корректно, инвентари и экономика на месте.

Всё, что нужно от вас — выбрать точку и подтвердить действие; последовательность «остановить → распаковать → запустить» панель берёт на себя. Это заметно проще и надёжнее, чем восстановление руками через SSH, где легко ошибиться с правами на файлы или структурой папок при распаковке архива не в то место — этот процесс подробно (и с типичными граблями) разобран в статье про восстановление сервера из бэкапа на практике, если у вас VPS без готовой панели бэкапов и приходится делать это вручную.

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

Когда встроенного автобэкапа недостаточно

Автобэкап на хостинге закрывает базовый и самый частый сценарий — «что-то сломалось, нужно откатиться на несколько часов/дней назад». Но у него есть разумные границы, о которых стоит знать заранее, а не в момент, когда что-то пошло не так:

• Хранится ограниченное число точек. Если инцидент обнаружен спустя недели (редко, но бывает — например, экономика плагина медленно расползалась и заметили это не сразу), нужной точки в истории может уже не оказаться.
• Копия живёт на инфраструктуре хостинга. Для большинства случаев (падение сервиса, ошибка администрирования, баг мода) этого достаточно. Но принцип «3-2-1» (минимум 3 копии, на 2 разных носителях, 1 копия вне основной инфраструктуры) для по-настоящему важных проектов — например, крупного комьюнити-сервера с многолетней историей — предполагает ещё и независимую копию за пределами хостинга.
• Автобэкап не заменяет мониторинг. Он не покажет, что сервер лагает или что TPS просел — это отдельная задача, для модовых сборок разобранная в статье про оптимизацию модов и TPS на Minecraft-сервере.

Если хочется дополнительного контроля — забирать копии автобэкапа во внешнее хранилище (S3-совместимое, Google Drive, второй сервер) — это уже надстройка поверх встроенного механизма, а не его замена. Для тех, кто хочет более гибкую схему хранения с ротацией по дням/неделям/месяцам или свой скрипт вместо панели, есть отдельный разбор настройки расписания автобэкапа через cron — пригодится, если нужен полный контроль над тем, что и куда копируется, за рамками встроенного функционала панели.

Частые вопросы