К списку статей DevOps и Инфраструктура

Построение отказоустойчивой системы бэкапов в S3 облако с ротацией и шифрованием

Опубликовано: 25.09.2026 в 12:23

Почему бэкапы на том же сервере — это иллюзия безопасности, и как сделать правильно

Хранить резервные копии базы данных на том же жестком диске, где крутится сам сайт — критическая ошибка. В случае сбоя файловой системы, компрометации root-доступа или физической поломки RAID-массива в дата-центре вы потеряете и продакшн, и бэкапы одновременно. Профессиональный подход к надежности данных требует соблюдения правила «3-2-1»: три копии, на двух разных носителях, одна из которых хранится на удаленной независимой платформе. Настроим автоматическую выгрузку зашифрованных бэкапов в изолированное S3-облако с ротацией по принципу дедупликации поколений (Grandfather-Father-Son).

Архитектура резервного копирования с ротацией

Мы не можем бесконечно копить ежедневные архивы — дисковое пространство в S3 не бесплатно. Нам нужен строгий алгоритм ротации (например, хранить последние 7 ежедневных бэкапов, 4 еженедельных и 3 ежемесячных). Все старые архивы должны удаляться автоматически. Перед отправкой в облако данные обязательно сжимаются утилитой gzip и шифруются симметричным ключом gpg, чтобы даже при компрометации облачного провайдера злоумышленники не получили доступ к вашей базе.

Схема резервного копирования с шифрованием в облако — 💡 Рис 1. Схема бэкапов в облако

Шаг 1: Bash-скрипт автоматического создания, шифрования и отправки бэкапа

Используем встроенную утилиту aws-cli, настроенную на работу с S3-совместимым хранилищем (Yandex Cloud / Selectel / AWS), для безопасной пакетной выгрузки данных.

bash

#!/bin/bash
# /usr/local/bin/backup-to-s3.sh

DB_NAME="isitreal_db"
BACKUP_DIR="/tmp/backups"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
PASSPHRASE="Ваш_Сверхнадежный_Ключ_Шифрования"

mkdir -p $BACKUP_DIR

# 1. Дамп базы данных и сжатие
mysqldump -u root -p"DB_PASSWORD" $DB_NAME | gzip > $BACKUP_DIR/$DB_NAME_$TIMESTAMP.sql.gz

# 2. Симметричное шифрование архива через GPG
gpg --batch --yes --passphrase "$PASSPHRASE" -c $BACKUP_DIR/$DB_NAME_$TIMESTAMP.sql.gz

# 3. Отправка зашифрованного файла (.gpg) в облако S3
aws s3 cp $BACKUP_DIR/$DB_NAME_$TIMESTAMP.sql.gz.gpg s3://isitreal-backups/daily/

# 4. Зачистка временных локальных файлов на сервере
rm -rf $BACKUP_DIR/*

Шаг 2: Настройка автоматического удаления старых копий через S3 Lifecycle

Вместо написания сложных скриптов удаления, мы перекладываем задачу ротации на само облако. Для этого в панели S3-провайдера настраивается Lifecycle Policy (политика жизненного цикла объектов).

json

{
  "Rules": [
    {
      "ID": "DeleteOldDailyBackups",
      "Status": "Enabled",
      "Filter": { "Prefix": "daily/" },
      "Expiration": { "Days": 7 }
    }
  ]
}

Итоги и резюме

Гарантия восстановления бизнеса

Наличие такой автоматизированной системы сводит риски потери данных к нулю. Даже при полном уничтожении основного сервера, развертывание проекта на новом железе займет минимум времени: достаточно развернуть чистую ОС, установить Docker, скачать зашифрованный бэкап из S3, расшифровать его одной командой gpg --decrypt и импортировать базу обратно. Главное — раз в квартал проводить тестовое восстановление, чтобы быть уверенным в валидности архивов.

Была ли полезна статья?

Оценки помогают мне понимать, какие темы вам наиболее интересны.

Чтобы оценить, войдите или зарегистрируйтесь.