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

MAATRIX GAMES

Автобэкапы настроены, они честно капают в хранилище каждую ночь — а потом сервер падает, мир корраптится после кривого мода, или админ сам случайно затирает spawn-чанк командой /fill. И тут выясняется, что процесс восстановления никто ни разу не пробовал руками. Разбираем по шагам, как поднять сервер из архива бэкапа так, чтобы не превратить одну проблему в две.

Почему нельзя восстанавливать «на живую»

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

Причина в том, что игровой процесс держит открытые файловые дескрипторы на файлы сохранений и продолжает в них писать, пока вы туда же льёте архив. Для Minecraft это означает риск повредить region-файлы (.mca) прямо во время записи — получите ChunkException или тихую потерю чанков, которая всплывёт через неделю. Для баз данных (Rust, ARK, FiveM с MySQL) — рассинхрон между .db-файлом на диске и тем, что процесс считает текущим состоянием в памяти.

Поэтому порядок всегда такой:

1. Остановить процесс сервера (не kill -9, а штатная остановка — stop в консоли или systemctl stop <service>, чтобы движок успел закрыть файлы и сбросить буферы).
2. Убедиться, что процесс реально завершился (ps aux | grep java для Minecraft, pgrep RustDedicated для Rust и так далее — пустой вывод означает, что процесс закрылся).
3. Только после этого работать с файлами.

Если сервер запущен через панель (Pterodactyl, AMP или похожую), остановка делается кнопкой в интерфейсе — панель сама пришлёт корректный сигнал завершения, ждать нужно до статуса «offline», а не «stopping».

Куда девать текущее состояние перед восстановлением

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

Правильный подход — переименовать, а не удалить:

cd /home/container   # или путь к рабочей директории сервера
mv world world_broken_2026-08-29
mv world_nether world_nether_broken_2026-08-29
mv world_the_end world_the_end_broken_2026-08-29

Для Rust это будет папка server/<identity>/, для ARK — ShooterGame/Saved/SavedArks/, для Valheim — файлы .db/.fwl в .config/unity3d/IronGate/Valheim/worlds_local/. Принцип один: старое состояние не выбрасывается сразу, а откладывается в сторону с понятным именем и датой. Через день-два, когда убедитесь, что восстановление прошло успешно и ничего ценного в старой папке не осталось, можно удалить её вручную.

Распаковка архива бэкапа

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

tar -xzvf backup-2026-08-28-0300.tar.gz -C /home/container/

Флаг -C указывает целевую директорию — так архив распакуется именно туда, куда нужно, а не в текущую рабочую папку консоли. Если бэкап хранит структуру относительно корня сервера (то есть внутри архива уже лежит world/, server.properties, ops.json), этого достаточно. Если архив был снят точечно только по папке мира (без общих конфигов), распаковывайте прицельно:

tar -xzvf backup-2026-08-28-0300.tar.gz -C /home/container/ world/ world_nether/ world_the_end/

Для бэкапов из панели с готовым интерфейсом восстановления (та же Pterodactyl хранит бэкапы через свой backend и умеет накатывать их кнопкой «Restore») процесс проще — панель сама остановит сервер, распакует архив и подтвердит завершение. Но даже там не помешает вручную свериться, что размер распакованных файлов адекватен ожидаемому — резкое расхождение в размере обычно значит, что бэкап снят в неудачный момент или архив неполный.

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

Проверка целостности перед запуском

Перед тем как стартовать сервер, стоит проверить, что архив распаковался целиком и файлы не битые. Несколько простых проверок:

• Целостность самого архива — если у вас остался архив (не удаляйте его до успешного запуска), проверьте его тестовым чтением без распаковки: tar -tzvf backup-2026-08-28-0300.tar.gz > /dev/null. Если команда завершилась с ошибкой вроде Unexpected EOF in archive, архив повреждён и распаковывать его не стоит — берите более раннюю копию.
• Размер файлов — сверьте размер распакованной папки мира с тем, что было раньше (du -sh world/). Пустой или подозрительно маленький результат — верный признак, что бэкап снят не в тот момент или процесс бэкапа сам прервался.
• Для баз данных — если сервер использует MySQL/SQLite (FiveM, некоторые модпаки Rust с экономикой через плагины), стоит попробовать открыть дамп локально или прогнать sqlite3 <файл> "PRAGMA integrity_check;" перед тем, как база окажется под нагрузкой живого сервера.
• Права доступа — после распаковки архива права на файлы иногда меняются (особенно если бэкап снимался под root, а сервер работает от отдельного пользователя). Проверьте ls -la и при необходимости верните владельца: chown -R gameserver:gameserver world/. Забытый шаг с правами — частая причина, почему сервер после «успешного» восстановления не стартует вообще, просто не может открыть файлы на запись.

Запуск и проверка что мир загрузился корректно

Запускайте сервер и сразу идите в лог, не переключайтесь на что-то другое, пока не увидите строку про успешную загрузку мира. Для Minecraft это что-то вроде Done (X.XXXs)! For help, type "help" в консоли — без ошибок Exception loading chunk перед этой строкой. Если видите поток предупреждений про повреждённые чанки, лучше сразу останавливать сервер и не давать игрокам заходить — иначе они своими действиями (например, генерацией новых чанков рядом с битыми) усложнят последующее восстановление.

Дальше стоит зайти на сервер самому, до того как открывать доступ игрокам:

• Проверить, что спавн и ключевые постройки на месте, а не откатились на несколько дней назад.
• Прогнать команду проверки состояния — для Minecraft это /forge tps или встроенный tps у Paper/Spigot, чтобы убедиться, что сервер не тормозит из-за поломанных чанков.
• Для Rust/ARK — проверить, что персонажи игроков (или хотя бы структуры) не потерялись, зайдя под тестовым аккаунтом или через админ-команды осмотра карты.
• Свериться со списком модов/плагинов — после восстановления архива иногда выясняется, что бэкап снимался до установки последнего мода, и сервер стартует без него. Если работаете с модами на Minecraft, стоит свериться с гайдом по оптимизации модов и TPS на Minecraft-сервере — там же разобрано, как быстро найти виновника лагов после любого изменения набора модов.

Только после этих проверок стоит объявлять игрокам, что сервер снова доступен.

Откат к более раннему бэкапу при повторном сбое

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

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

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

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

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

Тестируйте восстановление заранее, а не в момент аварии

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

Раз в месяц-два стоит устраивать себе тренировку: взять свежий бэкап, развернуть его на тестовом экземпляре сервера (отдельный порт, отдельная директория — благо большинство хостингов позволяют поднять второй временный сервер на пробу) и пройти весь процесс от остановки до успешного захода в мир. Это займёт от силы 20–30 минут, зато вы точно будете знать:

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

Аналогичная логика касается и голосовых/вспомогательных сервисов — если у вас параллельно поднят сервер Discord-бота или TeamSpeak для команды, их конфиги и базы тоже стоит проверять на восстанавливаемость, а не только основной игровой сервер.

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