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

Бэкап на том же сервере — это не бэкап

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

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

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

Правило 3-2-1 существует не как теоретическая рекомендация, а как ответ на конкретные и регулярно повторяющиеся сценарии потери данных: минимум три копии данных, на двух разных типах носителей, и хотя бы одна копия физически в другом месте.

Общепринятый принцип организации резервного копирования

Вынос копий за пределы сервера решает обе проблемы одним и тем же способом: даже если сервер полностью недоступен или скомпрометирован, копия в независимом хранилище остаётся нетронутой и доступной для восстановления на новом сервере с нуля. Эта статья разбирает, как организовать такой вынос через S3-совместимое объектное хранилище — от базового понимания технологии до полной автоматизации через cron.

Что такое S3-совместимое объектное хранилище

Amazon S3 (Simple Storage Service) задал стандарт API для объектного хранилища, который впоследствии переняли десятки других провайдеров, — отсюда термин «S3-совместимое»: хранилище, работающее по тому же протоколу и с теми же понятиями, что оригинальный сервис Amazon, но у другого провайдера и часто по другой цене.

В отличие от привычного диска сервера, где данные организованы в виде дерева файлов и папок, объектное хранилище устроено плоско: есть «бакет» (bucket) — контейнер верхнего уровня, и внутри него «объекты» (objects) — сами файлы, каждый с уникальным ключом (key), который внешне может выглядеть как путь с папками, но фактически является просто строкой-идентификатором без реальной файловой иерархии на диске.

Доступ к хранилищу происходит не через SSH или монтирование диска, а через HTTP-запросы к API конкретного провайдера, подписанные парой ключ доступа / секретный ключ (access key и secret key) — эта пара действует как логин и пароль конкретно для операций с хранилищем, отдельно от паролей или SSH-ключей к самим серверам.

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

Инструмент для синхронизации: rclone или aws-cli

Для переноса файлов между сервером и объектным хранилищем чаще всего используют одну из двух консольных утилит. aws-cli — официальный инструмент от Amazon, разумный выбор, если хранилище полностью совместимо с оригинальным API S3 и не требуется поддержка других типов облачных хранилищ.

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

apt install rclone -y
rclone version

Дальнейшие примеры в статье используют rclone именно из-за этой универсальности, но все описанные принципы — хранение ключей отдельно от скрипта, политика хранения, автоматизация через cron — одинаково применимы и к aws-cli с поправкой на синтаксис конкретных команд.

Настройка доступа без ключей внутри скрипта

Главное правило безопасной работы с любым облачным API — секретный ключ никогда не должен быть виден в тексте самого скрипта резервного копирования, в истории команд шелла или, тем более, попасть в систему контроля версий вместе с кодом проекта.

rclone решает это через отдельный конфигурационный файл, создаваемый один раз интерактивной командой rclone config, где для каждого хранилища заводится именованный «remote» — ключи хранятся в этом файле, а не в аргументах команды.

rclone config
# в интерактивном мастере: n (новый remote) → имя, например s3backup
# тип: s3 (или конкретный S3-совместимый провайдер из списка)
# access_key_id и secret_access_key вводятся здесь, не в командной строке

Итоговый файл конфигурации по умолчанию лежит в ~/.config/rclone/rclone.conf — стоит явно ограничить права доступа к нему, чтобы прочитать его мог только владелец процесса резервного копирования, а не любой пользователь сервера.

chmod 600 ~/.config/rclone/rclone.conf

Альтернативный подход, удобный для контейнеризированных окружений или CI/CD, — передавать ключи через переменные окружения (RCLONE_CONFIG_S3BACKUP_ACCESS_KEY_ID и аналогичные), которые задаются на уровне системы или секретного хранилища оркестратора, а не хранятся ни в файле, ни в самом скрипте.

Первая синхронизация: rclone sync и rclone copy

Когда remote настроен, отправка локальной папки с бэкапами в хранилище сводится к одной команде — но важно осознанно выбрать между copy и sync, поскольку у них разное поведение при удалении файлов.

rclone copy /var/backups/site s3backup:my-backups-bucket/site --progress

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

rclone sync /var/backups/site s3backup:my-backups-bucket/site --backup-dir s3backup:my-backups-bucket/deleted --progress

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

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

Объектное хранилище оплачивается по факту занимаемого объёма — без ограничения на срок хранения количество бэкапов и, соответственно, счёт за хранилище будут расти бессрочно, даже если реальная потребность — иметь возможность откатиться на пару недель назад, а не хранить историю всего проекта с первого дня.

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

rclone delete s3backup:my-backups-bucket/site --min-age 30d

У большинства провайдеров объектного хранилища есть и встроенный механизм жизненного цикла (lifecycle policy), настраиваемый в панели управления или через API самого хранилища, а не на стороне сервера, — правило вида «удалять объекты в этой папке через 30 дней после создания» выполняется автоматически внутри самого хранилища, независимо от того, отработал ли вообще скрипт на сервере в этот день.

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

Полная автоматизация через cron

Ручной запуск команд синхронизации рано или поздно приведёт к пропущенному бэкапу именно перед инцидентом — задачу нужно оформить в единый скрипт и поставить на выполнение по расписанию через cron, подробно этот механизм разобран в отдельной статье базы знаний.

#!/bin/bash
set -e
DATE=$(date +%F)
BACKUP_DIR="/var/backups/site"
mkdir -p "$BACKUP_DIR"

mysqldump -u backup_user -p"$(cat /root/.secrets/mysql_pw)" mydb | gzip > "$BACKUP_DIR/db-$DATE.sql.gz"
tar -czf "$BACKUP_DIR/files-$DATE.tar.gz" /var/www/example.ru

rclone copy "$BACKUP_DIR" s3backup:my-backups-bucket/site --min-age 1m
rclone delete s3backup:my-backups-bucket/site --min-age 30d

find "$BACKUP_DIR" -mtime +2 -delete

0 3 * * * /usr/local/bin/backup-to-s3.sh >> /var/log/backup-to-s3.log 2>&1

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

Флаг --min-age 1m у rclone copy в примере выше страхует от отправки в хранилище файла, который ещё дозаписывается tar или mysqldump в этот самый момент, — операция синхронизации подхватит файл только через минуту после его последнего изменения, когда запись гарантированно завершена.

Дополнительное шифрование перед отправкой

Большинство провайдеров объектного хранилища шифруют данные на своей стороне (at rest), но это защищает только от доступа к физическим дискам провайдера — не от компрометации самой учётной записи в хранилище или ошибки конфигурации бакета, сделавшей его случайно публичным.

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

gpg --batch --yes --passphrase-file /root/.secrets/backup-gpg-pass -c "$BACKUP_DIR/db-$DATE.sql.gz"

У rclone есть и собственный механизм — remote типа crypt, оборачивающий любой другой remote прозрачным шифрованием и расшифровкой на лету, что удобнее ручного вызова gpg для каждого файла, но требует отдельной настройки и хранения ключа шифрования rclone так же аккуратно, как и ключей доступа к самому хранилищу.

Тестовое восстановление: единственное реальное доказательство

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

rclone copy s3backup:my-backups-bucket/site/db-2026-10-12.sql.gz /tmp/restore-test/
gunzip -t /tmp/restore-test/db-2026-10-12.sql.gz && echo "архив не повреждён"

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

Разумная практика — включить такую тестовую проверку в календарь как отдельную регулярную задачу (например, раз в месяц), а не полагаться на то, что кто-то вспомнит о ней сам в спокойное время, когда для этого нет явного повода.

Типичные ошибки при переносе бэкапов в объектное хранилище

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

Использование rclone sync без понимания разницы с copy — при определённой последовательности локальной очистки и отправки в хранилище можно неожиданно удалить историю бэкапов раньше срока, который задан политикой хранения.

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

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

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

Чек-лист настройки резервного копирования в S3-совместимое хранилище

Шаг 1. Заведите отдельный бакет для бэкапов у провайдера объектного хранилища и получите пару ключей доступа именно для этой задачи, отдельно от других интеграций.

Шаг 2. Настройте rclone или aws-cli с хранением ключей в защищённом конфигурационном файле (права 600) или переменных окружения, никогда не в самом скрипте.

Шаг 3. Напишите единый скрипт, который создаёт дамп базы данных и архив файлов, отправляет их в хранилище и только после подтверждения успеха чистит устаревшие локальные копии.

Шаг 4. Настройте политику хранения — либо через встроенный lifecycle хранилища, либо командой удаления старых объектов внутри своего же скрипта, желательно оба варианта параллельно.

Шаг 5. Поставьте скрипт на выполнение через cron с перенаправлением вывода в лог-файл, чтобы результат каждого запуска можно было проверить постфактум.

Шаг 6. Запланируйте регулярную (например, ежемесячную) проверку через фактическое тестовое восстановление на отдельном сервере — без неё все предыдущие шаги остаются непроверенным предположением.

Итог: перенос ответственности за сохранность на отдельную инфраструктуру

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

Ключевые практические моменты — хранить ключи доступа отдельно от кода скрипта, осознанно выбирать между copy и sync, настроить политику хранения, чтобы старые копии не накапливали бесконечные расходы, и обязательно проверять восстановление на практике, а не полагаться на факт наличия файлов в хранилище. Если настройка автоматического резервного копирования кажется отдельным проектом, на который жалко тратить время, — оставьте заявку внизу страницы, настроим отправку бэкапов в объектное хранилище под конкретный стек вашего проекта.

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