Резервное копирование в облако: rclone и S3-совместимые хранилища

MAATRIX GAMES

Локальный бэкап на том же диске, где крутится сервер — это не бэкап, а иллюзия бэкапа. Диск хостера умер, аккаунт заблокировали, злоумышленник получил root и стёр всё подчистую вместе со снапшотами — и привет, вайп мира, который игроки строили полгода. Разберём, как настроить rclone так, чтобы копии архивов сами улетали в отдельное S3-совместимое хранилище, шифровались перед отправкой и не занимали место бесконечно.

Зачем нужен offsite-бэкап отдельно от локального

Локальные бэкапы на том же сервере закрывают только один сценарий — откат после кривого обновления мода или случайного /clear не туда. Они не спасают, если:

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

Правило простое: минимум одна копия бэкапа должна физически лежать не там, где сервер, и не под тем же провайдером. S3-совместимое хранилище (Backblaze B2, Wasabi, Selectel S3, Yandex Object Storage, self-hosted MinIO на другой машине) для этого подходит идеально — дешёвое хранение, простой API, и rclone умеет говорить с любым из них одинаково.

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

Выбираем S3-совместимое хранилище

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

Конкретные цены и лимиты у провайдеров меняются, поэтому перед выбором проверяйте актуальный тариф на сайте провайдера — не полагайтесь на цифры из старых статей, они устаревают быстро. Технически для наших целей подойдёт любой провайдер с S3 API: дальше вся настройка одинаковая, меняются только endpoint и ключи доступа.

Устанавливаем и настраиваем rclone

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

curl https://rclone.org/install.sh | sudo bash
rclone version

Дальше настраиваем remote — интерактивный мастер:

rclone config

Выбираем n (new remote), даём имя, например gamebackup, тип s3, провайдера — либо конкретного из списка (Backblaze, Wasabi, Yandex и т.д.), либо Other для любого S3-совместимого. Дальше мастер спросит access key и secret key (создаются в панели провайдера отдельно под rclone, не переиспользуйте ключ от других сервисов), регион и endpoint. Типичные endpoint'ы для примера (проверяйте актуальные в документации провайдера):

• Backblaze B2: s3.us-west-002.backblazeb2.com (регион зависит от бакета)
• Wasabi: s3.wasabisys.com
• Yandex Object Storage: storage.yandexcloud.net
• Selectel S3: s3.ru-1.storage.selcloud.ru

Итоговый remote можно проверить прямо в конфиге (~/.config/rclone/rclone.conf, у root — /root/.config/rclone/rclone.conf):

[gamebackup]
type = s3
provider = Other
access_key_id = ВАШ_КЛЮЧ
secret_access_key = ВАШ_СЕКРЕТ
endpoint = s3.example-provider.com
region = auto

Проверяем связь:

rclone lsd gamebackup:
rclone mkdir gamebackup:myserver-backups

Если бакет создаётся и виден — remote настроен. Дальше можно закрывать доступ к самому конфигу от посторонних (chmod 600 ~/.config/rclone/rclone.conf) — там лежат ключи в открытом виде.

Шифруем архивы перед отправкой в облако

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

Вариант 1 — шифрование архива через GPG перед загрузкой. Просто и понятно, не требует специального remote:

tar -czf - /home/gameserver/world | \
  gpg --symmetric --cipher-algo AES256 --batch --yes \
  --passphrase-file /root/.backup_pass \
  -o /home/gameserver/backups/world-$(date +%F).tar.gz.gpg

Файл /root/.backup_pass с паролем держите вне директории бэкапов, с правами 600, и сохраните копию пароля отдельно (в менеджере паролей) — потеряете его, и зашифрованный архив станет бесполезным набором байт.

Вариант 2 — crypt-remote rclone. rclone умеет шифровать «на лету» при загрузке в облачный remote, без промежуточного файла:

rclone config
# n → имя crypt-gamebackup → тип: crypt
# remote: gamebackup:myserver-backups (тот S3-remote, что настроили выше)
# filename encryption: standard
# задаём пароль и (опционально) пароль на структуру имён

После этого rclone copy /local/backups/ crypt-gamebackup: шифрует и имена файлов, и содержимое — в бакете провайдера видны только нечитаемые blob'ы. Этот вариант удобнее для автоматизации, потому что не нужен отдельный шаг с gpg в скрипте.

Скрипт бэкапа и автоматизация через cron

Собираем всё в один скрипт: локальный архив (мир + конфиги + база плагинов, если она в файлах) → загрузка в облако → лог.

#!/bin/bash
# /opt/scripts/backup-to-cloud.sh
set -euo pipefail

SRC="/home/gameserver/server"
LOCAL_BACKUP_DIR="/home/gameserver/backups"
DATE=$(date +%F_%H%M)
ARCHIVE="$LOCAL_BACKUP_DIR/backup-$DATE.tar.gz"
REMOTE="gamebackup:myserver-backups"

mkdir -p "$LOCAL_BACKUP_DIR"

tar -czf "$ARCHIVE" -C "$SRC" world world_nether world_the_end plugins config

rclone copy "$ARCHIVE" "$REMOTE/" \
  --transfers 4 --checkers 8 --fast-list \
  --log-file /var/log/backup-cloud.log --log-level INFO

echo "$(date): backup $ARCHIVE uploaded to $REMOTE" >> /var/log/backup-cloud.log

Делаем исполняемым и добавляем в cron (ежедневно в 4 утра, когда онлайн обычно минимальный):

chmod +x /opt/scripts/backup-to-cloud.sh
crontab -e

0 4 * * * /opt/scripts/backup-to-cloud.sh >> /var/log/backup-cloud.log 2>&1

Если сервер на Minecraft и используете плагин автосохранения — перед архивированием стоит на секунду выключить автосейв командой через RCON (save-off), сделать save-all, снять архив, включить обратно (save-on) — так снижается риск захватить мир в момент записи чанка. Подробнее про сами команды и подключение — в статье про RCON-подключение и основные команды.

Ротация старых копий и проверка восстановления

Без ротации бакет будет расти бесконечно и счёт за хранение — тоже. rclone умеет удалять по возрасту файла прямо в облаке:

rclone delete gamebackup:myserver-backups --min-age 30d

Это удалит в remote всё старше 30 дней. Для более гибкой схемы (например, хранить последние 7 ежедневных + последние 4 недельных) проще держать отдельные подпапки (daily/, weekly/) и класть в weekly/ архив раз в неделю отдельной cron-задачей, а --min-age для каждой папки настраивать свой.

У многих провайдеров есть ещё и lifecycle-правила на стороне бакета (настраиваются в панели провайдера) — они надёжнее скриптовой ротации, потому что срабатывают, даже если cron на сервере перестал запускаться.

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

rclone copy gamebackup:myserver-backups/backup-2026-08-01.tar.gz /tmp/restore-test/
cd /tmp/restore-test && tar -tzf backup-2026-08-01.tar.gz | head

Проверка целостности между локальной и облачной копией:

rclone check /home/gameserver/backups gamebackup:myserver-backups

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

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