Voltar ao blog
Бэкапы Minecraft сервера: как не потерять данные при атаке

Бэкапы Minecraft сервера: как не потерять данные при атаке

Ваш Minecraft-сервер работает месяцами. Игроки строят города, прокачивают персонажей, экономика крутится. А потом приходит DDoS. Сервер падает в момент автосохранения. Java-процесс убит OOM-киллером на полуслове. Region-файлы записаны наполовину. Level.dat обнулился. И вот вы смотрите на 0-байтовые файлы в playerdata/ и понимаете: бэкапов нет.

Эта ситуация происходит регулярно. Администраторы тратят месяцы на развитие сервера, но забывают про бэкапы. Или делают их раз в неделю вручную. Или хранят на том же диске, что и сервер. Всё это равнозначно отсутствию бэкапов.

В этой статье разберём, как настроить надёжную систему резервного копирования для Minecraft-сервера. Без лишней теории, с конкретными скриптами и конфигами, которые можно скопировать и применить.

Почему бэкапы критически важны для MC-серверов

Minecraft-сервер хранит данные в файлах на диске. Мир, инвентари, достижения, статистика, конфиги плагинов, права доступа. Всё это обычные файлы в файловой системе, и они уязвимы.

Основные риски:

Краш во время записи. Minecraft периодически сохраняет мир на диск. Если сервер упал в этот момент (DDoS, OOM, kernel panic), файлы могут оказаться в невалидном состоянии. Region-файл, записанный наполовину, может привести к потере целой области 32x32 чанков. Это сотни часов работы игроков.

Повреждение level.dat. Этот файл содержит критическую информацию: мировое время, позицию спавна, генератор, гейм-правила. Без него сервер не запустится. Да, есть level.dat_old, но если и он повреждён, у вас проблемы.

Потеря playerdata. Файлы в world/playerdata/ хранят инвентарь, позицию, здоровье, опыт каждого игрока. Один 0-байтовый файл означает полную потерю прогресса конкретного человека.

Ошибки администратора. Случайный rm -rf, неудачное обновление плагина, тестирование на проде. Человеческий фактор убивает данные не реже атак.

Атаки на сервер. DDoS-атаки вызывают резкое падение TPS, перегрузку CPU и памяти. Когда сервер не справляется, ОС может убить Java-процесс. А если атакующий получил доступ через уязвимость в плагине, он может намеренно повредить данные.

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

Не всё на сервере одинаково важно. Вот приоритеты:

Критически важно

  • world/ (и все дополнительные миры: world_nether, world_the_end, миры плагинов)
  • world/playerdata/ - инвентари и прогресс игроков
  • world/advancements/ - достижения
  • world/stats/ - статистика игроков
  • plugins/ - конфиги и данные всех плагинов
  • server.properties, spigot.yml, paper-global.yml, paper-world-defaults.yml
  • ops.json, whitelist.json, banned-players.json, banned-ips.json
  • Базы данных MySQL/MariaDB (если плагины используют SQL)

Важно, но восстановимо

  • Jar-файлы сервера и плагинов - можно скачать заново
  • Логи - полезны для анализа, но не критичны для работы
  • Кэш и временные файлы - пересоздаются автоматически

Можно не бэкапить

  • .cache/, libraries/ - скачиваются при запуске
  • crash-reports/ - если вы уже проанализировали краши
  • Очень большие логи - занимают место в бэкапе без особой пользы

Правило 3-2-1

Золотой стандарт резервного копирования. Простое правило, которое работает:

  • 3 копии данных (оригинал + 2 бэкапа)
  • 2 разных типа носителей (локальный диск + облако, или SSD + HDD)
  • 1 копия в другом физическом месте (offsite)

Для Minecraft-сервера это означает:

  1. Оригинальные данные на сервере
  2. Локальный бэкап на отдельном диске или разделе
  3. Удалённый бэкап в облачном хранилище (S3, Backblaze B2, Google Drive)

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

Бэкап без остановки сервера: save-off / save-on

Главная проблема: нельзя просто копировать файлы работающего Minecraft-сервера. Если сервер записывает данные в тот момент, когда вы их копируете, бэкап может содержать несогласованные данные. Чанк записан наполовину, playerdata открыт на запись, level.dat в процессе обновления.

Решение: команды save-off и save-on.

#!/bin/bash
# minecraft-backup.sh - бэкап без остановки сервера
# Требует: screen или tmux с сессией minecraft

SERVER_DIR="/opt/minecraft"
BACKUP_DIR="/backup/minecraft"
SCREEN_NAME="minecraft"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
BACKUP_FILE="$BACKUP_DIR/mc-backup-$DATE.tar.gz"

# Создаем директорию для бэкапов
mkdir -p "$BACKUP_DIR"

# Уведомляем игроков
screen -S "$SCREEN_NAME" -p 0 -X stuff "say Backup starting in 10 seconds...$(printf '\r')"
sleep 10

# Отключаем автосохранение
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-off$(printf '\r')"
sleep 1

# Принудительно сохраняем текущее состояние
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-all$(printf '\r')"
sleep 5

# Создаем архив
tar -czf "$BACKUP_FILE" \
    -C "$SERVER_DIR" \
    world/ \
    world_nether/ \
    world_the_end/ \
    plugins/ \
    server.properties \
    spigot.yml \
    paper-global.yml \
    ops.json \
    whitelist.json \
    banned-players.json \
    banned-ips.json \
    2>/dev/null

# Включаем автосохранение обратно
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-on$(printf '\r')"

# Уведомляем игроков
screen -S "$SCREEN_NAME" -p 0 -X stuff "say Backup complete!$(printf '\r')"

echo "Backup created: $BACKUP_FILE ($(du -sh "$BACKUP_FILE" | cut -f1))"

Алгоритм простой: отключаем автосохранение, делаем финальный save-all, копируем файлы, включаем автосохранение. Между save-off и save-on файлы мира не изменяются, и мы получаем консистентный снимок.

Важный момент: не забудьте включить save-on. Если скрипт упадёт с ошибкой после save-off, автосохранение останется выключенным, и при следующем краше вы потеряете все изменения с момента последнего save-all. Добавьте trap:

# Добавьте в начало скрипта после переменных
trap 'screen -S "$SCREEN_NAME" -p 0 -X stuff "save-on$(printf '\r')"' EXIT

Теперь save-on выполнится в любом случае, даже если скрипт прервался.

Инструменты: rsync, rclone, borgbackup

rsync: базовый инструмент

rsync копирует только изменившиеся файлы. Для ежедневных бэкапов больших миров это экономит время и трафик.

#!/bin/bash
# rsync-backup.sh - инкрементальный бэкап через rsync

SERVER_DIR="/opt/minecraft"
BACKUP_DIR="/backup/minecraft/latest"
LOG="/var/log/mc-backup.log"

# Используем rsync для копирования только изменённых файлов
rsync -a --delete \
    --exclude='.cache/' \
    --exclude='libraries/' \
    --exclude='logs/*.gz' \
    --exclude='crash-reports/' \
    "$SERVER_DIR/" "$BACKUP_DIR/"

echo "$(date '+%Y-%m-%d %H:%M:%S') rsync backup completed" >> "$LOG"

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

borgbackup: дедупликация и шифрование

borgbackup (borg) создаёт инкрементальные бэкапы с дедупликацией. Если у вас мир на 10 ГБ, но за день изменилось только 200 МБ чанков, borg сохранит только эти 200 МБ. При этом каждый бэкап выглядит как полная копия и восстанавливается независимо.

# Инициализация репозитория (один раз)
borg init --encryption=repokey /backup/borg-mc

# Создание бэкапа
borg create \
    --stats \
    --compression zstd,3 \
    --exclude '*.log.gz' \
    --exclude '.cache' \
    --exclude 'libraries' \
    /backup/borg-mc::mc-{now:%Y-%m-%d_%H-%M} \
    /opt/minecraft/world \
    /opt/minecraft/plugins \
    /opt/minecraft/server.properties \
    /opt/minecraft/ops.json \
    /opt/minecraft/whitelist.json

# Автоматическая ротация
borg prune \
    --keep-hourly=6 \
    --keep-daily=7 \
    --keep-weekly=4 \
    --keep-monthly=6 \
    /backup/borg-mc

Преимущества borg для Minecraft:

  • Дедупликация: одинаковые чанки не дублируются между бэкапами
  • Сжатие zstd: быстрое и эффективное для бинарных данных
  • Шифрование: бэкапы зашифрованы, ключ хранится локально
  • Точечное восстановление: можно восстановить один файл из любого бэкапа

rclone: отправка в облако

rclone работает с десятками облачных хранилищ. Настройте его один раз и используйте для offsite-бэкапов.

# Настройка (интерактивно, один раз)
rclone config

# Пример конфига для Backblaze B2 (~/.config/rclone/rclone.conf)
# [b2-backup]
# type = b2
# account = YOUR_KEY_ID
# key = YOUR_APP_KEY

# Синхронизация бэкапа в облако
rclone sync /backup/minecraft b2-backup:mc-server-backup \
    --transfers=4 \
    --checkers=8 \
    --fast-list \
    --log-file=/var/log/rclone-backup.log \
    --log-level=NOTICE

# Для Google Drive:
# rclone sync /backup/minecraft gdrive:mc-backup

Backblaze B2 стоит $0.005/ГБ в месяц. Для среднего Minecraft-сервера с миром в 5-10 ГБ это около $0.05 в месяц. Минимальные затраты ради безопасности данных.

Автоматизация через cron

Бэкап, который нужно запускать вручную, не будет запускаться. Автоматизируйте всё.

# Открываем crontab
crontab -e

# Локальный бэкап каждые 4 часа
0 */4 * * * /opt/scripts/minecraft-backup.sh >> /var/log/mc-backup.log 2>&1

# Отправка в облако раз в сутки в 4 утра
0 4 * * * /opt/scripts/cloud-upload.sh >> /var/log/mc-cloud-backup.log 2>&1

# Полный бэкап с borgbackup каждое воскресенье в 5 утра
0 5 * * 0 /opt/scripts/borg-backup.sh >> /var/log/mc-borg.log 2>&1

# Очистка старых бэкапов раз в неделю
0 6 * * 1 /opt/scripts/backup-cleanup.sh >> /var/log/mc-cleanup.log 2>&1

Полный скрипт, объединяющий все этапы:

#!/bin/bash
# full-backup-pipeline.sh
# Полный пайплайн: save-off -> бэкап -> borg -> rclone -> save-on

set -euo pipefail

SERVER_DIR="/opt/minecraft"
BACKUP_DIR="/backup/minecraft"
BORG_REPO="/backup/borg-mc"
SCREEN_NAME="minecraft"
RCLONE_REMOTE="b2-backup:mc-server-backup"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
LOG="/var/log/mc-backup-pipeline.log"

log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') $1" >> "$LOG"
}

# Гарантируем включение save-on при любом исходе
trap 'screen -S "$SCREEN_NAME" -p 0 -X stuff "save-on$(printf "\r")" 2>/dev/null; log "save-on restored (trap)"' EXIT

log "=== Backup pipeline started ==="

# 1. Отключаем автосохранение
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-off$(printf '\r')"
sleep 1
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-all$(printf '\r')"
sleep 5
log "save-off + save-all done"

# 2. rsync в локальную директорию
rsync -a --delete \
    --exclude='.cache/' \
    --exclude='libraries/' \
    --exclude='logs/*.gz' \
    "$SERVER_DIR/" "$BACKUP_DIR/latest/"
log "rsync completed"

# 3. Включаем автосохранение (чем раньше, тем лучше)
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-on$(printf '\r')"
log "save-on restored"

# 4. borgbackup из локальной копии (сервер уже работает нормально)
borg create \
    --stats \
    --compression zstd,3 \
    "$BORG_REPO"::mc-"$DATE" \
    "$BACKUP_DIR/latest/" 2>> "$LOG"
log "borg backup created"

# 5. borg prune
borg prune \
    --keep-hourly=6 \
    --keep-daily=7 \
    --keep-weekly=4 \
    --keep-monthly=3 \
    "$BORG_REPO" 2>> "$LOG"
log "borg prune completed"

# 6. rclone в облако (самая долгая операция)
rclone sync "$BACKUP_DIR/latest/" "$RCLONE_REMOTE" \
    --transfers=4 \
    --fast-list 2>> "$LOG"
log "rclone sync completed"

log "=== Backup pipeline finished ==="

Обратите внимание: save-on включается сразу после rsync, а не в конце скрипта. borgbackup и rclone работают уже с локальной копией, и серверу не нужно ждать их завершения. Окно save-off минимально.

Инкрементальные vs полные бэкапы

Полный бэкап копирует всё каждый раз. Просто, надежно, но занимает много места и времени. Мир на 20 ГБ = 20 ГБ каждый бэкап.

Инкрементальный бэкап копирует только то, что изменилось с прошлого раза. Быстро, экономно, но для восстановления нужна вся цепочка бэкапов.

Оптимальная стратегия для Minecraft:

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

borgbackup решает эту задачу автоматически. Каждый бэкап технически инкрементальный (хранит только новые блоки данных), но при восстановлении выглядит как полный. Лучшее из двух миров.

Ротация и политика хранения

Бесконечно хранить все бэкапы не получится. Нужна ротация. Типичная политика для Minecraft-сервера:

  • Последние 24 часа: бэкап каждые 4 часа (6 копий)
  • Последняя неделя: ежедневный бэкап (7 копий)
  • Последний месяц: еженедельный бэкап (4 копии)
  • Последние 3 месяца: ежемесячный бэкап (3 копии)

Итого: ~20 точек восстановления, покрывающих 3 месяца истории.

Скрипт ротации для tar-бэкапов:

#!/bin/bash
# backup-rotation.sh - удаление старых бэкапов

BACKUP_DIR="/backup/minecraft"

# Удаляем бэкапы старше 7 дней (кроме воскресных)
find "$BACKUP_DIR" -name "mc-backup-*.tar.gz" -mtime +7 \
    -not -name "*_Sun_*" -delete

# Удаляем воскресные бэкапы старше 30 дней
find "$BACKUP_DIR" -name "*_Sun_*.tar.gz" -mtime +30 -delete

# Показываем использование диска
echo "Backup space usage:"
du -sh "$BACKUP_DIR"

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

Бэкап баз данных MySQL/MariaDB

Если ваши плагины используют SQL (LuckPerms, ShopGUI+, CMI, Dynmap, Plan), файловый бэкап не захватит базу данных. Нужен отдельный дамп.

#!/bin/bash
# mysql-backup.sh - дамп базы данных

DB_NAME="minecraft"
DB_USER="mc_backup"
DB_PASS="secure_password_here"
BACKUP_DIR="/backup/mysql"
DATE=$(date +%Y-%m-%d_%H-%M-%S)

mkdir -p "$BACKUP_DIR"

# Создаем дамп с блокировкой таблиц (консистентный снимок)
mysqldump \
    --user="$DB_USER" \
    --password="$DB_PASS" \
    --single-transaction \
    --routines \
    --triggers \
    "$DB_NAME" | gzip > "$BACKUP_DIR/mc-db-$DATE.sql.gz"

echo "Database backup: $BACKUP_DIR/mc-db-$DATE.sql.gz"

# Удаляем дампы старше 14 дней
find "$BACKUP_DIR" -name "mc-db-*.sql.gz" -mtime +14 -delete

Флаг --single-transaction критически важен. Он создаёт консистентный снимок базы без блокировки таблиц. Без него дамп может содержать данные из разных моментов времени (одна таблица обновилась, пока другая ещё дампилась).

Добавьте этот скрипт в пайплайн бэкапа, запускайте перед бэкапом файлов, и включите SQL-дамп в borgbackup.

Тестирование бэкапов: бэкап без теста = нет бэкапа

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

Тестируйте восстановление регулярно. Раз в месяц минимум.

#!/bin/bash
# test-restore.sh - проверка восстановления из бэкапа

TEST_DIR="/tmp/mc-restore-test"
BORG_REPO="/backup/borg-mc"

# Очищаем тестовую директорию
rm -rf "$TEST_DIR"
mkdir -p "$TEST_DIR"

# Восстанавливаем последний бэкап
LATEST=$(borg list "$BORG_REPO" --last 1 --format '{archive}')
echo "Restoring: $LATEST"

borg extract "$BORG_REPO"::"$LATEST" --target "$TEST_DIR"

# Проверяем критические файлы
echo "=== Checking critical files ==="

# level.dat
if [ -f "$TEST_DIR/latest/world/level.dat" ]; then
    SIZE=$(stat -c%s "$TEST_DIR/latest/world/level.dat")
    if [ "$SIZE" -gt 100 ]; then
        echo "[OK] level.dat ($SIZE bytes)"
    else
        echo "[FAIL] level.dat too small ($SIZE bytes)"
    fi
else
    echo "[FAIL] level.dat missing!"
fi

# Region files
REGION_COUNT=$(find "$TEST_DIR/latest/world/region/" -name "*.mca" 2>/dev/null | wc -l)
EMPTY_REGIONS=$(find "$TEST_DIR/latest/world/region/" -name "*.mca" -empty 2>/dev/null | wc -l)
echo "[INFO] Region files: $REGION_COUNT total, $EMPTY_REGIONS empty"

# Player data
PLAYER_COUNT=$(find "$TEST_DIR/latest/world/playerdata/" -name "*.dat" 2>/dev/null | wc -l)
EMPTY_PLAYERS=$(find "$TEST_DIR/latest/world/playerdata/" -name "*.dat" -empty 2>/dev/null | wc -l)
echo "[INFO] Player data: $PLAYER_COUNT total, $EMPTY_PLAYERS empty"

# Plugin configs
PLUGIN_COUNT=$(find "$TEST_DIR/latest/plugins/" -maxdepth 1 -type d 2>/dev/null | wc -l)
echo "[INFO] Plugin directories: $PLUGIN_COUNT"

# Проверяем server.properties
if [ -f "$TEST_DIR/latest/server.properties" ]; then
    echo "[OK] server.properties present"
else
    echo "[FAIL] server.properties missing!"
fi

# Проверяем ops.json
if [ -f "$TEST_DIR/latest/ops.json" ]; then
    echo "[OK] ops.json present"
else
    echo "[WARN] ops.json missing"
fi

# Очистка
rm -rf "$TEST_DIR"
echo "=== Restore test complete ==="

Запускайте этот скрипт автоматически раз в неделю и отправляйте результат себе в Discord/Telegram. Если тест провалился, вы узнаете об этом до того, как бэкап реально понадобится.

Быстрое восстановление после атаки

DDoS-атака повредила данные. Игроки ждут. Каждая минута простоя стоит аудитории. Вот пошаговый план быстрого восстановления:

# 1. Останавливаем сервер (если ещё работает)
screen -S minecraft -p 0 -X stuff "stop$(printf '\r')"
sleep 10

# 2. Перемещаем повреждённые данные (не удаляем!)
mv /opt/minecraft/world /opt/minecraft/world_corrupted_$(date +%Y%m%d)

# 3. Восстанавливаем из последнего бэкапа

# Вариант A: из rsync-копии (самый быстрый)
cp -a /backup/minecraft/latest/world /opt/minecraft/world

# Вариант B: из borg
borg extract /backup/borg-mc::ARCHIVE_NAME \
    --target /opt/minecraft \
    latest/world

# Вариант C: из tar-архива
tar -xzf /backup/minecraft/mc-backup-LATEST.tar.gz \
    -C /opt/minecraft world/

# 4. Восстанавливаем базу данных (если нужно)
gunzip < /backup/mysql/mc-db-LATEST.sql.gz | mysql minecraft

# 5. Проверяем права доступа
chown -R minecraft:minecraft /opt/minecraft/world

# 6. Запускаем сервер
screen -S minecraft -X stuff "/opt/minecraft/start.sh$(printf '\r')"

Из rsync-копии восстановление занимает минуты. Из borg с дедупликацией чуть дольше, но всё равно быстро. Из облачного бэкапа может потребоваться время на скачивание, поэтому локальная копия критически важна.

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

Безопасность бэкапов

Бэкап содержит всё: конфиги с паролями от БД, RCON-пароли, токены API плагинов. Если кто-то получит доступ к бэкапу, он получит полный контроль над сервером.

Шифрование

borgbackup поддерживает шифрование из коробки. При инициализации репозитория с --encryption=repokey все данные шифруются AES-256.

Для tar-архивов используйте gpg:

# Шифрование бэкапа
tar -czf - /opt/minecraft/world /opt/minecraft/plugins | \
    gpg --symmetric --cipher-algo AES256 \
    --output /backup/mc-encrypted-$(date +%Y%m%d).tar.gz.gpg

# Расшифровка
gpg --decrypt /backup/mc-encrypted-20260403.tar.gz.gpg | \
    tar -xzf - -C /opt/minecraft

Контроль доступа

# Ограничиваем доступ к директории бэкапов
chmod 700 /backup/minecraft
chown root:root /backup/minecraft

# Для rclone конфига (содержит ключи облачных хранилищ)
chmod 600 ~/.config/rclone/rclone.conf

Отдельный пользователь для бэкапов

Создайте отдельного пользователя с минимальными правами:

# Создаем пользователя для бэкапов
useradd -r -s /bin/bash -d /backup mc-backup

# Даём read-only доступ к данным сервера
setfacl -R -m u:mc-backup:rx /opt/minecraft
setfacl -R -d -m u:mc-backup:rx /opt/minecraft

# Даём полный доступ к директории бэкапов
chown -R mc-backup:mc-backup /backup/minecraft

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

Плагины для бэкапов

Если вы не хотите возиться с bash-скриптами, есть плагины, которые делают бэкапы из Minecraft.

DriveBackupV2

Автоматически бэкапит в Google Drive, OneDrive или FTP. Настройка через конфиг:

# plugins/DriveBackupV2/config.yml
backup-schedule:
  cron: "0 */6 * * *"  # Каждые 6 часов
backup-list:
  - path: "world"
    format: "zip"
  - path: "plugins"
    format: "zip"
google-drive:
  enabled: true
keep-count: 10

eBackup

Лёгкий плагин для локальных бэкапов с поддержкой FTP/SFTP:

# plugins/eBackup/config.yml
backup:
  interval: 240  # минуты
  format: tar.gz
  worlds: true
  plugins: true
  max-backups: 20

Плагины удобны для небольших серверов. Но для серьёзной инфраструктуры лучше использовать системные инструменты (borg + rclone + cron). Они работают на уровне ОС, не зависят от состояния Java-процесса, и дают полный контроль над процессом.

Offsite-хранилище: куда отправлять бэкапы

Amazon S3 / S3-совместимые

# rclone.conf для Wasabi (S3-совместимый, дешевле AWS)
# [wasabi]
# type = s3
# provider = Wasabi
# access_key_id = YOUR_KEY
# secret_access_key = YOUR_SECRET
# endpoint = s3.eu-central-1.wasabisys.com

rclone sync /backup/minecraft wasabi:mc-backup-bucket

Backblaze B2

Самый бюджетный вариант. $0.005/ГБ хранение, $0.01/ГБ загрузка, первые 10 ГБ бесплатно.

rclone sync /backup/minecraft b2-backup:mc-server-backup \
    --fast-list \
    --transfers=4

Google Drive (через rclone)

15 ГБ бесплатно. Для небольшого сервера этого достаточно.

rclone sync /backup/minecraft gdrive:mc-backup \
    --drive-chunk-size=64M

Рекомендация: начните с Backblaze B2. Минимальная стоимость, высокая надёжность, хорошая скорость. Для большинства Minecraft-серверов месячный счёт будет меньше $1.

Мониторинг бэкапов

Бэкапы бесполезны, если они тихо ломаются. Добавьте мониторинг:

#!/bin/bash
# check-backup-health.sh

BACKUP_DIR="/backup/minecraft/latest"
MAX_AGE_HOURS=6
DISCORD_WEBHOOK="https://discord.com/api/webhooks/YOUR_WEBHOOK"

# Проверяем возраст последнего бэкапа
LATEST_MOD=$(stat -c %Y "$BACKUP_DIR/world/level.dat" 2>/dev/null || echo 0)
NOW=$(date +%s)
AGE_HOURS=$(( (NOW - LATEST_MOD) / 3600 ))

if [ "$AGE_HOURS" -gt "$MAX_AGE_HOURS" ]; then
    curl -s -H "Content-Type: application/json" \
        -d "{\"content\":\"[ALERT] MC backup is $AGE_HOURS hours old (max: $MAX_AGE_HOURS). Check backup system!\"}" \
        "$DISCORD_WEBHOOK"
fi

# Проверяем размер бэкапа (слишком маленький = что-то не так)
WORLD_SIZE=$(du -sm "$BACKUP_DIR/world/" 2>/dev/null | cut -f1)
if [ "${WORLD_SIZE:-0}" -lt 100 ]; then
    curl -s -H "Content-Type: application/json" \
        -d "{\"content\":\"[ALERT] MC world backup is only ${WORLD_SIZE}MB. Expected >100MB. Possible backup failure!\"}" \
        "$DISCORD_WEBHOOK"
fi

Добавьте в cron: 0 */2 * * * /opt/scripts/check-backup-health.sh. Если бэкап не обновлялся дольше 6 часов или мир подозрительно маленький, вы получите уведомление в Discord.

DDoS и бэкапы: как защитить данные при атаке

DDoS-атака создаёт идеальные условия для потери данных. Сервер перегружен, TPS падает до нуля, OOM-киллер может убить Java в любой момент. Если в этот момент шло автосохранение, данные повредятся.

Что делать:

  1. Настройте защиту от DDoS. Сервисы вроде MineGuard фильтруют атаки до того, как трафик дойдёт до сервера. Нет перегрузки, нет крашей, нет повреждений.

  2. Увеличьте частоту бэкапов при угрозе. Если ваш сервер регулярно атакуют, настройте бэкапы каждые 2 часа вместо 4. Максимальная потеря данных (RPO) сократится вдвое.

  3. Не полагайтесь только на автосохранение. Autosave в Minecraft не заменяет бэкапы. Autosave перезаписывает те же файлы. Если они повредились, autosave запишет повреждённую версию поверх нормальной.

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

Подробнее о восстановлении после атак читайте в нашей статье о восстановлении после DDoS. А о базовой защите сервера расскажет чеклист безопасности на 2026 год.

Чеклист: настройка бэкапов за 30 минут

Если вы дочитали до сюда и у вас до сих пор нет бэкапов, вот план на 30 минут:

  1. [5 мин] Создайте директорию /backup/minecraft и скрипт minecraft-backup.sh из этой статьи
  2. [3 мин] Добавьте скрипт в cron (каждые 4 часа)
  3. [5 мин] Установите borgbackup (apt install borgbackup) и инициализируйте репозиторий
  4. [5 мин] Установите rclone (apt install rclone) и настройте Backblaze B2 (бесплатно до 10 ГБ)
  5. [5 мин] Настройте скрипт отправки в облако и добавьте в cron
  6. [5 мин] Запустите первый бэкап вручную и убедитесь, что всё работает
  7. [2 мин] Настройте мониторинг (Discord webhook при ошибке)

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

Proteja Seu Servidor de Ataques DDoS

Proteção gratuita com configuração em 5 minutos. 1 TB de tráfego incluso.

Experimentar Grátis

Artigos Relacionados

Minecraft сервер лагает: DDoS или проблемы сервера?

Minecraft сервер лагает: DDoS или проблемы сервера?

Твой Minecraft сервер начал лагать, игроки жалуются, а ты не понимаешь - это атака или что-то на сервере сломалось? Разбираемся, как отличить DDoS от серверных проблем.

XDP и eBPF: фильтрация пакетов нового поколения для игровых серверов

XDP и eBPF: фильтрация пакетов нового поколения для игровых серверов

Как XDP и eBPF позволяют фильтровать пакеты на уровне драйвера сетевой карты, обрабатывая 14+ миллионов пакетов в секунду на одном ядре. Почему iptables слишком медленный для современных DDoS-атак и как программируемая фильтрация меняет защиту игровых серверов.

Layer 4 vs Layer 7 DDoS-атаки - в чём разница и почему это важно

Layer 4 vs Layer 7 DDoS-атаки - в чём разница и почему это важно

Разбираем OSI-модель простым языком, объясняем разницу между L3/L4 и L7 атаками на примерах из игрового мира: SYN flood, UDP flood, HTTP flood, бот-джойны и крафтинг невалидных пакетов. Почему для реальной защиты нужны оба уровня.