Бэкап и восстановление MinIO

MAATRIX

MinIO — это свой аналог S3 на собственном сервере: те же API-вызовы, что и у Amazon, но данные лежат там, где вы решили, и никто кроме вас не видит бакеты. Проблема в том, что «свой S3» означает и «свой бэкап» — никакой AWS не сохранит для вас 11 девяток надёжности по умолчанию. Разберём, как настроить резервное копирование MinIO и, что важнее, как реально восстановить данные, когда диск или весь сервер выйдет из строя.

Зачем вообще бэкапить объектное хранилище

Кажется, что MinIO и так надёжен: он использует erasure coding — данные и коды избыточности размазываются по нескольким дискам, и потеря одного-двух дисков не приводит к потере объектов. Это правда, но erasure coding защищает от отказа железа, а не от человеческих и логических ошибок. Он не спасёт, если кто-то выполнит mc rm --recursive не на том бакете, если приложение по багу перезапишет объекты мусором, если сломается конфигурация IAM и данные станут недоступны, или если сервер целиком украдут, сожгут или заблокирует провайдер.

Если вы уже выбираете, на чём вообще держать инфраструктуру бэкапов, стоит заранее прикинуть требования к диску и сети — этому посвящена отдельная статья про сервер под бэкапы и архив. Второй момент — erasure coding работает внутри одного развёртывания. Если у вас single-node MinIO с несколькими дисками на одной машине, отказ самой машины (материнская плата, блок питания, кража сервера) убивает все копии разом, сколько бы дисков ни было внутри. Резервная копия обязана жить физически в другом месте — на другом сервере, а лучше в другой локации.

Третье: в MinIO часто складывают то, ради чего его и заводили — бэкапы других систем (дампы PostgreSQL, снапшоты Docker volume, архивы логов). Если само хранилище бэкапов не бэкапится, вы получаете единую точку отказа для всей инфраструктуры резервного копирования.

Установка MinIO для production-сценария

Для теста хватает одного контейнера, но если вы уже думаете о бэкапах, разумно сразу поднимать конфигурацию, которую можно защитить. Минимальный рабочий вариант — Docker Compose с одним instance и несколькими дисками для erasure coding:

services:
  minio:
    image: minio/minio:latest
    command: server /data{1...4} --console-address ":9001"
    environment:
      MINIO_ROOT_USER: admin
      MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}
    volumes:
      - /mnt/disk1:/data1
      - /mnt/disk2:/data2
      - /mnt/disk3:/data3
      - /mnt/disk4:/data4
    ports:
      - "9000:9000"
      - "9001:9001"
    restart: unless-stopped

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

Ставим клиент mc — без него дальше никуда:

curl https://dl.min.io/client/mc/release/linux-amd64/mc \
  --create-dirs -o /usr/local/bin/mc
chmod +x /usr/local/bin/mc
mc alias set local http://127.0.0.1:9000 admin ${MINIO_ROOT_PASSWORD}
mc admin info local

Три уровня, которые нужно бэкапить

Люди, впервые настраивающие бэкап MinIO, обычно вспоминают только про объекты и забывают ещё про два слоя, без которых восстановленное хранилище окажется бесполезным:

• Данные (объекты в бакетах) — то, ради чего всё затевалось.
• Конфигурация и IAM — пользователи, политики доступа, ключи доступа сервисных аккаунтов, настройки репликации и жизненного цикла бакетов.
• Метаданные и версии объектов — если включено версионирование, важно не потерять историю версий, а не только последнюю.

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

mc admin config export local > minio-config-$(date +%F).json
mc admin policy list local --json > minio-policies-$(date +%F).json
mc admin user list local --json > minio-users-$(date +%F).json
mc admin cluster iam export local minio-iam-$(date +%F).zip

Последняя команда — cluster iam export — самая надёжная: она забирает пользователей, группы, политики и их привязки одним архивом, который потом импортируется командой mc admin cluster iam import.

Бэкап данных: mc mirror и репликация

Основной и самый простой способ скопировать содержимое бакетов — mc mirror. Он умеет копировать инкрементально, синхронизируя только изменения:

# зеркалирование в локальный каталог на другом диске/NAS
mc mirror --overwrite local/my-bucket /mnt/backup/my-bucket

# зеркалирование на другой MinIO/S3, например на сервере в другой локации
mc alias set remote https://backup.example.com admin ${REMOTE_PASSWORD}
mc mirror --overwrite --watch local/my-bucket remote/my-bucket-backup

Флаг --watch держит процесс живым и досылает изменения по мере их появления — удобно для непрерывной репликации, но обычно это выносят в systemd-сервис, а не запускают вручную. Для регулярного snapshot-бэкапа проще и предсказуемее ставить mc mirror в cron без --watch, раз в час или раз в сутки в зависимости от того, сколько данных вы готовы потерять:

# /etc/cron.d/minio-backup
0 * * * * root /usr/local/bin/mc mirror --overwrite --remove local/prod-bucket /mnt/backup/prod-bucket >> /var/log/minio-backup.log 2>&1

Флаг --remove синхронизирует и удаления — если объект удалили в источнике, он удалится и в копии. Это то, что нужно для точного зеркала, но не для защиты от случайного удаления: если кто-то по ошибке снесёт бакет, --remove снесёт его и в бэкапе на следующем запуске. Для защиты от такого сценария нужны версионирование и object lock — ниже.

Более production-подход — встроенная bucket replication MinIO: сервер сам асинхронно реплицирует новые объекты на другой MinIO-инстанс без внешнего cron-процесса.

mc admin bucket remote add local/my-bucket \
  https://accessKey:secretKey@backup.example.com/my-bucket-backup \
  --service replication

mc replicate add local/my-bucket --remote-bucket my-bucket-backup
mc replicate status local/my-bucket

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

Версионирование и object lock как страховка от человеческого фактора

Версионирование объектов защищает именно от того, от чего не защищает erasure coding, — от перезаписи и удаления по ошибке. Включается на уровне бакета:

mc version enable local/my-bucket

После этого удаление объекта не стирает данные физически, а ставит delete-маркер; предыдущую версию можно вернуть:

mc ls --versions local/my-bucket/important-file.pdf
mc undo local/my-bucket/important-file.pdf

Для по-настоящему критичных данных (например, бухгалтерских архивов или бэкапов баз данных, которые нельзя изменить задним числом) добавляют object lock в режиме compliance — тогда объект физически нельзя удалить или перезаписать до истечения срока хранения, даже с root-ключами:

mc mb --with-lock local/archive-bucket
mc retention set --default COMPLIANCE "30d" local/archive-bucket

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

Восстановление: от одного объекта до целого кластера

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

Восстановить один объект или версию — самый частый случай, обычно решается версионированием без обращения к внешнему бэкапу:

mc ls --versions local/my-bucket/config.json
mc cp local/my-bucket/config.json/versions/<version-id> local/my-bucket/config.json

Восстановить бакет целиком из внешней копии — если данные испорчены логически (не сбой диска, а плохой деплой или атака), реплика на том же кластере тоже испорчена. Тянем из независимой резервной копии:

mc mirror --overwrite /mnt/backup/my-bucket local/my-bucket-restored
# проверили содержимое — переключили приложение на новый бакет,
# либо восстановили поверх старого после чистки

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

Восстановить весь сервер после потери железа — самый тяжёлый случай. Порядок такой: поднимаете новый MinIO с тем же MINIO_ROOT_USER/MINIO_ROOT_PASSWORD (или новыми — тогда придётся переиздать ключи приложениям), заливаете объекты через mc mirror из резервной копии, импортируете IAM:

mc admin cluster iam import local minio-iam-2026-08-20.zip
mc mirror /mnt/backup/prod-bucket local/prod-bucket
mc admin info local

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

Мониторинг здоровья и деградации дисков

Бэкап без мониторинга состояния кластера — это бэкап, о необходимости которого вы узнаете постфактум. MinIO отдаёт метрики в формате Prometheus и умеет показывать состояние erasure set прямо из CLI:

mc admin info local
mc admin heal local --scan normal

mc admin heal запускает фоновую проверку и восстановление повреждённых объектов за счёт erasure coding — полезно гонять по расписанию на больших хранилищах, а не только после явного сбоя диска. Метрики стоит завести в существующий стек мониторинга: если в инфраструктуре уже есть связка Prometheus и Grafana, MinIO подключается туда как ещё один target без лишней возни — эндпоинт метрик отдаётся по адресу /minio/v2/metrics/cluster.

Отдельно стоит мониторить сам процесс бэкапа: cron-задача может годами тихо падать с ошибкой доступа, а вы узнаете об этом только когда понадобится восстановление. Простое решение — писать в лог и проверять код возврата, либо завести пинг на внешний сервис вроде healthchecks.io после каждого успешного mc mirror.

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