Автобэкапы игрового сервера: настройка расписания

MAATRIX GAMES

Рано или поздно с любым игровым сервером случается что-то нехорошее: битый чанк после падения питания, неудачный апдейт мода, который убивает сохранение, гриферы, добравшиеся до основной базы, или банальное «зачем-то удалил не ту папку в 3 часа ночи». Если бэкапов нет — вы теряете часы или месяцы прогресса игроков и объясняете это в дискорде сообщества. Ниже — рабочая схема автобэкапа, которая одинаково годится для Minecraft, Rust, ARK, ущемлённого в память CS2-сервера или чего угодно ещё: что копировать, как это автоматизировать через cron, сколько версий хранить и почему копия должна лежать не там же, где сам сервер.

Что реально нужно бэкапить

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

Критично, бэкапить каждый раз:

• Файлы мира/сохранения — world/ в Minecraft, *.sav в ARK (SavedArks/), папка сохранения в Rust (server.map, *.sav, *.db в server/<identity>/), сейв-файлы survival-игр вроде Valheim или Project Zomboid.
• Базы данных, если сервер их использует — экономика на плагинах, статистика, инвентари игроков (SQLite-файлы или дамп MySQL/PostgreSQL, если БД внешняя).
• Конфигурация сервера — server.properties, permissions.yml, конфиги плагинов/модов, whitelist/ban-листы.

Желательно, но можно бэкапить реже:

• Сами файлы плагинов и модов (plugins/, mods/) — их несложно переустановить заново, но если сборка кастомная и собиралась руками, проще иметь копию.
• Логи — обычно не критичны, но иногда нужны для разбора инцидента (кто и когда что сломал).

Не нужно бэкапить:

• Сами исполняемые файлы игрового сервера (jar, бинарники) — их всегда можно скачать заново.
• Кэши, временные файлы, logs/latest.log и подобное — это просто мёртвый вес в архиве.

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

Скрипт бэкапа через tar и cron

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

#!/bin/bash
# backup-server.sh — бэкап игрового сервера

SERVER_DIR="/home/gameserver/data"      # где лежат файлы сервера
BACKUP_DIR="/home/gameserver/backups"   # куда складывать архивы
DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_NAME="backup_${DATE}.tar.gz"

mkdir -p "$BACKUP_DIR"

# Архивируем только нужное: мир, конфиги, плагины — без логов и кэша
tar -czf "$BACKUP_DIR/$BACKUP_NAME" \
    -C "$SERVER_DIR" \
    world world_nether world_the_end \
    server.properties permissions.yml \
    plugins/*/config.yml \
    2>> "$BACKUP_DIR/backup.log"

if [ $? -eq 0 ]; then
    echo "$(date): бэкап успешно создан — $BACKUP_NAME" >> "$BACKUP_DIR/backup.log"
else
    echo "$(date): ОШИБКА при создании бэкапа" >> "$BACKUP_DIR/backup.log"
fi

Для Rust список путей будет другим — там нужна папка server/<identity> целиком (в ней и мир, и сейвы, и БД плагинов Oxide/uMod, если вы их уже поставили — см. установку Oxide/uMod). Для ARK — ShooterGame/Saved/SavedArks/. Суть скрипта не меняется, меняются только пути.

Сделайте скрипт исполняемым и добавьте в crontab:

chmod +x /home/gameserver/backup-server.sh
crontab -e

Строка для ежесуточного бэкапа в 4 утра (обычно время наименьшей нагрузки на сервере):

0 4 * * * /home/gameserver/backup-server.sh

Для активных PvP-серверов с частым вайпом или высоким риском потери прогресса имеет смысл гонять бэкап чаще — например каждые 6 часов:

0 */6 * * * /home/gameserver/backup-server.sh

Важный нюанс: если игровой сервер во время архивации активно пишет в файлы сохранения (частый случай для БД-подобных сейвов), лучше сначала аккуратно приостановить запись. Во многих играх есть команда save-off/save-all (Minecraft: save-all flush, затем можно временно отключить автосейв командой save-off и включить обратно save-on после архивации) — это снижает риск получить битый архив на активном сервере. Не у всех игр это доступно, поэтому альтернатива — снапшот файловой системы (LVM/ZFS snapshot), если хостинг это поддерживает, либо просто смириться с минимальным риском при коротком tar (обычно счёт идёт на секунды).

Ротация: сколько бэкапов хранить

Бэкапы, которые копятся бесконечно, рано или поздно забивают весь диск, и сервер падает уже не из-за геймплея, а из-за банального No space left on device. Нужна ротация — автоматическое удаление старых копий.

Простейший вариант — удалять всё старше N дней командой find, добавленной прямо в скрипт бэкапа:

# Хранить бэкапы только за последние 7 дней
find "$BACKUP_DIR" -name "backup_*.tar.gz" -mtime +7 -delete

Более гибкая схема — не просто «7 дней», а разная плотность хранения: последние 7 дневных копий, плюс 4 еженедельных, плюс пара месячных для дальней истории. Реализуется через отдельные подпапки и отдельные cron-задачи (ежедневный скрипт кладёт файл в daily/, а по воскресеньям отдельное задание копирует свежий дневной бэкап в weekly/). Для небольшого игрового сервера это часто избыточно — 7-14 дневных копий обычно достаточный компромисс между надёжностью и местом на диске, но если сервер важный (комьюнити-проект с сотнями часов прогресса), лишняя пара уровней ротации того стоит.

Пример полной ротации по трём уровням:

# daily: последние 7
find "$BACKUP_DIR/daily" -name "*.tar.gz" -mtime +7 -delete
# weekly: последние 4 (28 дней)
find "$BACKUP_DIR/weekly" -name "*.tar.gz" -mtime +28 -delete
# monthly: последние 6 (180 дней)
find "$BACKUP_DIR/monthly" -name "*.tar.gz" -mtime +180 -delete

Почему копия должна лежать не на том же сервере

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

Правильная схема — бэкап всегда должен «уезжать» на другую машину или во внешнее хранилище. Варианты:

• rsync на другой сервер/VPS — самый простой способ, если у вас есть второй сервер (например, домашний NAS или второй арендованный VPS):

rsync -avz --delete /home/gameserver/backups/ user@backup-host:/storage/gameserver-backups/

• rclone в облако (S3-совместимое хранилище, Backblaze B2, Yandex Object Storage и т.д.) — удобно, когда своего второго сервера нет:

rclone copy /home/gameserver/backups/ remote:gameserver-backups --min-age 1h

• scp/SFTP по расписанию — вариант попроще для разовой синхронизации без установки дополнительных утилит.

Добавьте команду синхронизации отдельной строкой в crontab сразу после задачи бэкапа (с задержкой в 10-15 минут, чтобы архивация точно успела завершиться):

0 4 * * * /home/gameserver/backup-server.sh
15 4 * * * rsync -avz /home/gameserver/backups/ user@backup-host:/storage/gameserver-backups/

Простое правило «3-2-1»: минимум 3 копии данных, на 2 разных носителях, 1 из них — вне основного сервера. Для домашнего или небольшого проекта это может звучать избыточно, но стоимость лишнего места на удалённом хранилище несравнима со стоимостью полной потери прогресса игроков.

Проверка, что бэкап реально восстанавливается

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

Проверяйте восстановление регулярно, хотя бы раз в месяц. Процедура простая:

1. Разверните тестовый сервер (можно временный, на пару часов) — например на другом порту той же машины или на отдельной дешёвой VPS.
2. Распакуйте туда свежий бэкап:

mkdir -p /tmp/restore-test
tar -xzf /home/gameserver/backups/backup_2026-08-28_04-00.tar.gz -C /tmp/restore-test

1. Запустите на этих файлах игровой сервер и убедитесь, что мир реально открывается, игроки на месте, экономика/инвентари не побиты.
2. Удалите тестовое окружение.

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

Собираем всё вместе: чек-лист рабочей схемы

Итоговая схема автобэкапа, которая закрывает все пункты выше:

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

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