Від Matt Connor 2026-07-30 · Оновлено 2026-08-01

MinIO на VPS: власне S3-сховище для restic

Q: Як підключити restic до MinIO як бекенда S3?

Установіть AWS_ACCESS_KEY_ID і AWS_SECRET_ACCESS_KEY, указавши ключ доступу MinIO та відповідний секретний ключ, а потім використайте рядок репозиторію у формі s3:https://s3.example.com/restic, де останній елемент шляху є назвою бакета. Спочатку створіть бакет за допомогою mc mb, оскільки ключ із дозволами лише для одного бакета не може створювати бакети. Перед завантаженням restic шифрує все власним паролем репозиторію, тому MinIO зберігає зашифровані дані й ніколи не отримує доступу до ваших файлів.

Налаштуйте MinIO на Ubuntu 24.04: перевірений бінарний файл, systemd без облікових даних у unit-файлі, mc, presigned URLs і backup для restic.

Verified Every command ran end-to-end on a fresh Ubuntu 24.04 server, July 30, 2026.

Що дає власне об’єктне сховище на базі MinIO

MinIO — це об’єктне сховище, яке працює на вашому сервері та підтримує Amazon S3 API. Спрямуйте restic або будь-який S3 SDK на власний сервер, змініть один параметр endpoint — і клієнт не помітить різниці. У цьому посібнику описано створення одного вузла на Ubuntu 24.04: перевірений бінарний файл, окремий системний користувач, модуль systemd, який не зберігає облікові дані root у файлі модуля, а також bucket, у який restic виконуватиме резервне копіювання.

S3 (simple storage service) — це HTTP API, а не файлова система. Ви виконуєте PUT об’єкта в bucket під певним ключем, а потім отримуєте його за допомогою GET. Частковий запис і перейменування не підтримуються. Інструментам резервного копіювання підходить така модель, оскільки об’єкт або записано повністю, або його не записано.

Один вузол зберігає одну копію ваших даних. Це компроміс, на який ви погоджуєтеся. Ви отримуєте контрольований S3 endpoint за ціною VPS, але також перебираєте на себе всі завдання, які раніше виконував хмарний провайдер: від заміни несправного диска до встановлення оновлень серверного програмного забезпечення. У розділі ближче до кінця прямо пояснено, коли такий компроміс є виправданим.

Стан MinIO community edition у липні 2026 року

Прочитайте цей розділ, перш ніж використовувати цю конфігурацію, оскільки нещодавно вона змінилася. У травні 2025 року MinIO вилучив функції адміністрування з вебконсолі у community edition. У браузері залишився переглядач об’єктів, тому керувати бакетами та ключами доступу тепер потрібно за допомогою клієнта командного рядка mc.

Пізніше у 2025 році MinIO припинив публікувати попередньо скомпільовані бінарні файли community edition. Тепер у README проєкту зазначено, що community edition поширюється лише у вигляді вихідного коду. Старі URL-адреси для завантаження досі працюють: станом на липень 2026 року вони надають серверну збірку RELEASE.2025-09-07T16-13-09Z і клієнтську збірку RELEASE.2025-08-13T08-35-41Z, а новіших збірок community edition не з’явилося. Отже, наведений нижче бінарний файл справжній і працює, але його версію зафіксовано. Виправлення безпеки, опубліковані після вересня 2025 року, до нього не входять.

Цей факт визначає подальшу конфігурацію. Саме тому MinIO тут прослуховує 127.0.0.1 і виходить в інтернет лише через проксі, який ви контролюєте. Якщо потрібно отримувати нові виправлення, зберіть MinIO з вихідного коду. У README постачальника наведено одну команду — go install github.com/minio/minio@latest. Для її виконання потрібен ланцюжок інструментів Go, а бінарний файл записується до ~/go/bin/minio. Установіть цей бінарний файл до /usr/local/bin/minio, і всі інші кроки в цьому посібнику залишаться без змін.

Встановлення двійкового файлу MinIO та перевірка завантаження

Завантажте зафіксований випуск і опубліковану контрольну суму для нього. Прапорець -f змушує curl завершуватися з помилкою в разі помилки HTTP, а не зберігати сторінку з помилкою під запитаним ім’ям. Інакше можна встановити сторінку 404, а потім дивуватися, чому вона не запускається.

cd /tmp
REL=RELEASE.2025-09-07T16-13-09Z
curl -fsSL "https://dl.min.io/server/minio/release/linux-amd64/archive/minio.$REL" -o minio
curl -fsSL "https://dl.min.io/server/minio/release/linux-amd64/archive/minio.$REL.sha256sum" -o minio.sha256sum

Порівняйте два хеші. Порівнюйте лише хеші.

published=$(awk '{print $1}' minio.sha256sum)
downloaded=$(sha256sum minio | awk '{print $1}')
[ "$published" = "$downloaded" ] && echo "checksum ok"

Не використовуйте тут sha256sum -c minio.sha256sum. Мітка, записана після хешу у цьому файлі, — minio.RELEASE.2025-09-07T16-13-09Z, а завантаження ми зберегли як minio, тому -c шукає файл, якого не існує. Команда повідомляє No such file or directory, а потім WARNING: 1 listed file could not be read. Це виглядає як пошкоджене завантаження, але ним не є. Мітка — лише ім’я. Гарантію забезпечує саме хеш.

Чітко визначте, що доводить ця перевірка. Двійковий файл і хеш отримано від того самого постачальника через те саме з’єднання, тому збіг доводить, що завантаження завершено, а дані не було пошкоджено або змінено під час передавання. Це не доводить, що постачальнику можна довіряти. Це інша проблема, і жодна команда sha256sum не може її розв’язати.

sudo install -o root -g root -m 755 minio /usr/local/bin/minio
minio --version

minio --version виводить minio version RELEASE.2025-09-07T16-13-09Z, а потім кілька рядків зі відомостями про збірку. Permission denied тут означає, що режим задано неправильно, а command not found — що /usr/local/bin немає у вашому PATH.

Створіть системного користувача та каталог даних

MinIO приймає завантаження з мережі, тому його не слід запускати від імені root. Створіть для нього обліковий запис без домашнього каталогу та оболонки входу.

sudo groupadd -r minio-user
sudo useradd -M -r -g minio-user -s /usr/sbin/nologin minio-user
sudo mkdir -p /var/lib/minio/data
sudo chown -R minio-user:minio-user /var/lib/minio
sudo chmod 750 /var/lib/minio

-r створює системний обліковий запис із UID, меншим за 1000, тому він не належить до діапазону, призначеного для користувачів. -M не створює домашній каталог, оскільки обліковому запису, який ніколи не виконує вхід, немає чого там зберігати. Перевірте результат за допомогою id minio-user і stat -c '%U %a' /var/lib/minio, яка має вивести minio-user 750.

Користувач має мати права на запис до каталогу даних, а не лише на читання. Під час першого запуску MinIO створює каталог .minio.sys усередині тому для зберігання власної конфігурації. Тому каталог, власником якого є root, спричиняє завершення роботи MinIO під час запуску з повідомленням, що закінчується на permission denied. Це саме правило застосовується до кожної служби, яку ви запускаєте таким способом. Докладніше про це див. у матеріалі системні користувачі з мінімальними привілеями на VPS.

Помістіть облікові дані root у файл середовища

Облікові дані root відкривають доступ до кожного bucket, тому їм не місце у файлі unit, доступному для читання всім користувачам. Спочатку створіть файл із правильними правами доступу, а потім запишіть у нього дані. Так пароль не перебуватиме у файлі, доступному для читання, навіть короткий час.

sudo install -o root -g root -m 600 /dev/null /etc/default/minio
printf 'MINIO_ROOT_USER=minio-root\nMINIO_ROOT_PASSWORD=%s\nMINIO_VOLUMES="/var/lib/minio/data"\nMINIO_OPTS="--address 127.0.0.1:9000 --console-address 127.0.0.1:9001"\n' "$(openssl rand -base64 24)" | sudo tee /etc/default/minio > /dev/null
sudo sed -n 's/^MINIO_ROOT_PASSWORD=//p' /etc/default/minio

tee очищає наявний файл, а не створює його заново, тому права доступу залишаються 600, а власником залишається root. Це зроблено навмисно. systemd читає EnvironmentFile від імені root, перш ніж скинути привілеї до User=. Тому обліковому запису служби не потрібно читати власні облікові дані. Після запуску служби перевірте це за допомогою sudo -u minio-user cat /etc/default/minio. Ця команда має вивести Permission denied.

Перед запуском MinIO потрібно знати про дві його особливості. Якщо в середовищі немає MINIO_ROOT_USER і MINIO_ROOT_PASSWORD, MinIO не відмовляється запускатися. Він запускається з документованими обліковими даними за замовчуванням minioadmin:minioadmin. Це перша пара, яку перевіряє будь-який сканер, і під час цього MinIO виглядає повністю справним. Натомість пароль довжиною менше 8 символів відхиляється: MinIO завершує роботу під час запуску з помилкою про недійсні облікові дані, оскільки access key має містити щонайменше 3 символи, а secret key — щонайменше 8.

MINIO_VOLUMES — це шлях до даних, а MINIO_OPTS містить прапори. Прив’язка до 127.0.0.1 означає, що S3 API поки що недоступний із-за меж цього VPS. Це правильне значення за замовчуванням. Пізніше ви навмисно відкриєте доступ до нього через proxy із сертифікатом.

Напишіть модуль systemd

Створіть /etc/systemd/system/minio.service:

[Unit]
Description=MinIO object storage
Documentation=https://github.com/minio/minio
Wants=network-online.target
After=network-online.target

[Service]
User=minio-user
Group=minio-user
EnvironmentFile=/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_VOLUMES $MINIO_OPTS
Restart=always
RestartSec=5
LimitNOFILE=65536
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

На початку EnvironmentFile немає -. Це зроблено навмисно, а не через помилку. Дефіс змушує systemd ігнорувати відсутній файл і все одно запускати MinIO. Тому видалений файл або неправильно вказаний шлях непомітно залишає сервер запущеним із minioadmin:minioadmin. Без дефіса відсутній файл призводить до помилки модуля ще до запуску MinIO, а journalctl -u minio показує Failed to load environment files: No such file or directory. Модуль, який відмовляється запускатися, набагато легше помітити, ніж сервер, що непомітно приймає пароль за замовчуванням.

$MINIO_VOLUMES і $MINIO_OPTS навмисно не взято в лапки, оскільки systemd розділяє незакриті лапками змінні за пробілами на окремі аргументи. Так чотири слова в MINIO_OPTS перетворюються на чотири аргументи для minio server. LimitNOFILE=65536 збільшує ліміт файлових дескрипторів, оскільки кожне відкрите з’єднання та кожен відкритий файл даних використовує один дескриптор, а стандартного значення 1024 недостатньо під навантаженням.

sudo systemctl daemon-reload
sudo systemctl enable --now minio
systemctl is-active minio
curl -fsS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:9000/minio/health/live

is-active має вивести active, а health endpoint має відповісти 200. journalctl -u minio -n 20 --no-pager показує адресу API, на якій сервер очікує з’єднань. Якщо модуль постійно перезапускається, systemd припиняє спроби та записує Start request repeated too quickly. Це означає, що MinIO завершує роботу під час кожної спроби. Причину наведено в рядках перед цим повідомленням, тому перегляньте журнал вище.

Для додаткової ізоляції додайте ProtectSystem=full і ProtectHome=true до секції [Service]. Для обох параметрів потрібні простори імен монтування, підтримувані ядром хоста. У контейнерній віртуалізації зі спільним ядром хоста, наприклад OpenVZ або LXC, вони можуть спричинити помилку, після чого модуль повідомляє status=226/NAMESPACE. Видаліть ці два рядки, і модуль запуститься. Сам модуль є звичайним, а в матеріалі системні служби й таймери systemd на VPS описано решту директив.

Встановіть mc і перевірте повний цикл

Клієнт MinIO — це mc. Не встановлюйте його за допомогою apt install mc. Цей пакет містить Midnight Commander, файловий менеджер, не пов’язаний із MinIO.

cd /tmp
curl -fsSL https://dl.min.io/client/mc/release/linux-amd64/mc -o mc
curl -fsSL https://dl.min.io/client/mc/release/linux-amd64/mc.sha256sum -o mc.sha256sum
[ "$(awk '{print $1}' mc.sha256sum)" = "$(sha256sum mc | awk '{print $1}')" ] && echo "checksum ok"
sudo install -o root -g root -m 755 mc /usr/local/bin/mc

Зареєструйте сервер як псевдонім, а потім перемістіть через нього об’єкт.

MINIO_PASS=$(sudo sed -n 's/^MINIO_ROOT_PASSWORD=//p' /etc/default/minio)
mc alias set local http://127.0.0.1:9000 minio-root "$MINIO_PASS"
mc mb local/backups
echo "hello object storage" > /tmp/hello.txt
mc cp /tmp/hello.txt local/backups/hello.txt
mc ls local/backups
mc cat local/backups/hello.txt

mc ls має показати hello.txt із його розміром, а mc cat має вивести hello object storage. Це справжнє підтвердження працездатності сервера, оскільки команда виконує ті самі підписані запити S3, що й будь-який інший клієнт. mc admin info local виводить стан сервера, якщо потрібна додаткова перевірка.

Тепер виконайте ще одну перевірку, поки сервер залишається порожнім.

mc alias set defaultcheck http://127.0.0.1:9000 minioadmin minioadmin

Ця команда має завершитися помилкою. Якщо вона виконується успішно, файл середовища не було передано процесу, і сервер працює з обліковими даними за замовчуванням. Виправте це, перш ніж хтось інший почне використовувати сервер.

mc зберігає псевдоніми у ~/.mc/config.json у відкритому тексті, тому ці облікові дані містяться в домашньому каталозі користувача, який виконав команду. Виконання mc від імені sudo зберігає облікові дані root у /root/.mc/config.json. Зберігайте псевдонім root в обліковому записі одного адміністратора, а для кожної програми створіть власний ключ.

Надати один об’єкт за допомогою presigned URL

Presigned URL — це звичайне HTTPS-посилання з підписом і строком дії. Будь-хто, хто має це посилання, може отримати цей об’єкт без облікового запису та клієнта.

mc share download --expire 12h local/backups/hello.txt

У результаті в рядку запиту містяться X-Amz-Signature і X-Amz-Expires. Є два моменти, які часто дивують користувачів. Посилання формується з endpoint вказаного вами alias, тому alias на 127.0.0.1 створює посилання, яке може відкрити лише цей комп’ютер. Створіть другий alias для вашого загальнодоступного hostname, якщо плануєте надсилати посилання іншим. Кнопки відкликання немає. Підпис залишається дійсним до завершення строку дії, тому короткий строк дії — єдиний доступний вам засіб контролю. Сім днів — максимальний строк, дозволений форматом підпису S3.

Надайте restic окремий ключ і bucket

Облікові дані root дають змогу читати та видаляти всі bucket, тому завдання резервного копіювання не повинно їх використовувати. Створіть bucket, політику з обмеженням для цього bucket і користувача, який не матиме жодних інших дозволів.

mc mb local/restic
cat > /tmp/restic-rw.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": ["arn:aws:s3:::restic"]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::restic/*"]
    }
  ]
}
EOF
RESTIC_KEY=$(openssl rand -base64 24)
mc admin policy create local restic-rw /tmp/restic-rw.json
mc admin user add local restic-backup "$RESTIC_KEY"
mc admin policy attach local restic-rw --user restic-backup

MinIO має вбудовану політику readwrite, завдяки якій можна було б виконати на одну команду менше. Вона надає повний доступ до всіх bucket на сервері. У наведеній вище політиці bucket навмисно вказано двічі: один раз як arn:aws:s3:::restic, щоб працювало перелічення bucket, і один раз як arn:aws:s3:::restic/* для об’єктів усередині нього. У S3 bucket і його об’єкти є окремими ресурсами, тому політика, у якій указано лише один із них, завершується помилкою, що виглядає як несправність клієнта.

Перевірте це обмеження, перш ніж покладатися на нього.

mc alias set resticuser http://127.0.0.1:9000 restic-backup "$RESTIC_KEY"
mc ls resticuser/restic
mc ls resticuser/backups

Перша команда ls виконується успішно, а друга завершується помилкою Access Denied. Неперевірена політика є лише припущенням.

Тепер налаштуйте restic для роботи з bucket. restic читає облікові дані S3 зі стандартних змінних середовища AWS, тому окремий файл облікових даних для restic не потрібен.

sudo apt install -y restic
export AWS_ACCESS_KEY_ID=restic-backup
export AWS_SECRET_ACCESS_KEY="$RESTIC_KEY"
restic -r s3:http://127.0.0.1:9000/restic init
restic -r s3:http://127.0.0.1:9000/restic backup /etc
restic -r s3:http://127.0.0.1:9000/restic snapshots

restic init запитує пароль репозиторію. Цей пароль шифрує репозиторій, тому MinIO зберігає лише зашифровані дані. У разі втрати пароля резервну копію буде втрачено. Процес, запущений таймером systemd, не має термінала для введення пароля, тому для запланованих резервних копій укажіть RESTIC_PASSWORD_FILE як файл із режимом 600.

Є одне правило розміщення, важливіше за будь-яку наведену вище команду. Репозиторій restic на тому самому VPS, що й дані, які він захищає, захистить від пошкодженого rm, але не від інших проблем. Вузол MinIO має бути на іншій машині, бажано в іншому регіоні. У матеріалі резервні копії restic на VPS описано планування та зберігання резервних копій на основі цієї конфігурації.

Завершення TLS через nginx

MinIO працює на localhost, тому nginx є зовнішньою точкою доступу. Спочатку випустіть сертифікат, як описано в Сертифікати Let's Encrypt за допомогою certbot і nginx, а потім використайте цей блок сервера.

server {
    listen 443 ssl;
    server_name s3.example.com;

    ignore_invalid_headers off;
    client_max_body_size 0;
    proxy_buffering off;
    proxy_request_buffering off;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_connect_timeout 300;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        chunked_transfer_encoding off;
        proxy_pass http://127.0.0.1:9000;
    }
}

Деякі з цих рядків критично важливі. client_max_body_size 0 скасовує стандартне обмеження розміру тіла запиту в 1 MB. Інакше будь-яке більше завантаження відхиляється з помилкою 413 Request Entity Too Large, ще до того як MinIO отримує запит. proxy_request_buffering off передає завантаження безпосередньо далі, оскільки за замовчуванням весь запит спочатку записується в тимчасовий файл. Тому для великого об’єкта потрібно вдвічі більше дискового простору. proxy_set_header Host $http_host — найменш очевидний параметр: підпис S3 охоплює заголовок Host. Якщо проксі змінює цей заголовок, кожен запит завершується помилкою SignatureDoesNotMatch, хоча в журналі доступу видно, що звичайний запит надійшов.

Також повідомте MinIO його публічне ім’я, щоб створені ним посилання вказували на проксі, а не на localhost.

echo 'MINIO_SERVER_URL=https://s3.example.com' | sudo tee -a /etc/default/minio
sudo systemctl restart minio

Налаштування брандмауера залишається мінімальним. Дозвольте SSH і HTTPS, а для портів 9000 і 9001 не створюйте жодного правила, оскільки адреса, прив’язана до 127.0.0.1, недоступна з іншої машини незалежно від налаштувань брандмауера. У Основи ufw на VPS наведено відповідні команди.

Коли достатньо MinIO на одному вузлі, а коли потрібен справжній S3

Один вузол тут означає один диск без надлишковості. Власна документація MinIO описує таку конфігурацію як придатну для тестування та невеликих робочих навантажень без вимог до доступності. У розгортанні немає другої копії даних, тому довговічність кожного об’єкта визначається довговічністю диска одного VPS. Функції, які потребують розподіленого бекенда з кодуванням стирання, зокрема реплікація бакетів і блокування об’єктів, призначені для розгортань із кількома дисками. Тому не обіцяйте незмінну політику зберігання даних у такій конфігурації.

Це хороший варіант як ціль для restic на другому VPS в іншому регіоні, а також як S3 endpoint для розробки та артефактів CI, коли втрата бакета означає лише необхідність повторно виконати збірку. Такий варіант також прийнятний для завантажень користувачів у невеликому застосунку, якщо ви відповідаєте за план відновлення та фактично перевірили відновлення з резервної копії.

Обирайте керований S3, коли контракт або регулятор вимагає блокування об’єктів чи довговічності в кількох регіонах, або коли ви не хочете отримувати сповіщення о 03:00 через заповнений диск. Інша вагома причина — зафіксована збірка. Станом на July 2026 попередньо скомпільований бінарний файл спільноти датований September 2025 і не отримує виправлень. Отже, його запуск означає прийняття цього обмеження або самостійне збирання з вихідного коду та супровід відповідно до змін у проєкті.

Варто окремо зазначити межу, про яку часто запитують. Об’єктне сховище не є базою даних. Кожен запис замінює весь об’єкт, тому робота з активним файлом SQL у бакеті S3 буде повільною та небезпечною. Зберігайте базу даних на локальному диску, а резервні копії записуйте в бакет: запуск SQLite у production на VPS описує такий поділ.

Типові причини збоїв і повідомлення, які ви побачите

Модуль завершується з помилкою одразу після systemctl enable --now. Перегляньте journalctl -u minio -n 30 --no-pager. Failed to load environment files: No such file or directory означає, що /etc/default/minio відсутній або його шлях у модулі вказано неправильно. Повідомлення, яке закінчується на permission denied, означає, що обліковий запис служби не має дозволу на запис до каталогу даних. Перевірте, чи виводить stat -c '%U' /var/lib/minio/data значення minio-user.

minioadmin:minioadmin і далі виконує вхід. Файл середовища не було передано процесу. Переконайтеся, що модуль містить EnvironmentFile=/etc/default/minio, виконайте sudo systemctl daemon-reload, а потім перезапустіть службу. MinIO зчитує кореневі облікові дані один раз під час запуску, тому редагування цього файлу без перезапуску нічого не змінює.

Address already in use під час запуску. Інший процес використовує порт 9000. Знайдіть його за допомогою sudo ss -ltnp | grep :9000, перш ніж змінювати порт MinIO.

Передавання файлів розміром понад 1 MB через проксі завершується помилкою. nginx повернув 413 Request Entity Too Large, і MinIO не отримав запит. Установіть client_max_body_size 0 у блоці сервера.

SignatureDoesNotMatch. Або секретний ключ неправильний, або компонент між клієнтом і MinIO змінив заголовок Host, який охоплює підпис.

RequestTimeTooSkewed. Годинник на клієнті або сервері показує неправильний час. Кожен запит S3 містить часову мітку, і система відхиляє запити за межами 15-хвилинного інтервалу. Перевірте timedatectl і переконайтеся, що синхронізація часу активна.

Access Denied для бакета, який, як ви знаєте, існує. Ключ обмежено іншим бакетом. Виведіть дозволи, які фактично надає політика, за допомогою mc admin policy info local restic-rw і порівняйте назву бакета в рядках ресурсу.

FAQ

Чи достатньо MinIO з одним вузлом для справжніх резервних копій?

Цього достатньо як цілі restic, запущеної на окремій машині від даних, які вона захищає. Але цього недостатньо як єдиної копії. Розгортання з одним диском не має паритету, тому всередині MinIO немає другої копії. Якщо цей диск VPS втратить дані, об’єкти буде втрачено. Зберігайте другу ціль в іншому місці та хоча б один раз відновіть дані з обох цілей, щоб переконатися, що процес працює.

Чому `sha256sum -c` не працює з файлом контрольної суми MinIO?

Тому що мітка після хешу в цьому файлі містить назву релізу — minio.RELEASE.2025-09-07T16-13-09Z, тоді як завантажений файл зазвичай називається minio. sha256sum -c шукає файл із назвою, записаною у файлі контрольної суми, не знаходить його та повідомляє No such file or directory і WARNING: 1 listed file could not be read. Завантаження виконано правильно. Порівняйте рядки хешів безпосередньо та проігноруйте мітку, оскільки вона не має значення для безпеки.

Куди зникла вебконсоль адміністрування MinIO?

У травні 2025 року MinIO вилучив функції адміністрування з консолі community edition, залишивши у вебінтерфейсі браузер об’єктів. Керування бакетами та користувачами тепер виконується за допомогою клієнта mc, використовуючи такі команди, як mc admin user add і mc admin policy attach. Це підтримуваний спосіб у community edition, а не обхідне рішення, тому в цьому посібнику всі дії виконуються з командного рядка.

Як підключити restic до MinIO як бекенда S3?

Установіть AWS_ACCESS_KEY_ID і AWS_SECRET_ACCESS_KEY, указавши ключ доступу MinIO та відповідний секретний ключ, а потім використайте рядок репозиторію у формі s3:https://s3.example.com/restic, де останній елемент шляху є назвою бакета. Спочатку створіть бакет за допомогою mc mb, оскільки ключ із дозволами лише для одного бакета не може створювати бакети. Перед завантаженням restic шифрує все власним паролем репозиторію, тому MinIO зберігає зашифровані дані й ніколи не отримує доступу до ваших файлів.

Чи потрібно запускати MinIO за nginx?

TLS (захист транспортного рівня) потрібен, якщо клієнт працює не на тій самій машині, оскільки облікові дані S3 і дані об’єктів передаються всередині запиту. Проксі на порту 443 із сертифікатом від certbot — найпростіший спосіб це налаштувати. Сертифікати при цьому оновлюються окремо від MinIO. MinIO також може сам завершувати TLS, якщо вказати --certs-dir на каталог із public.crt і private.key, але тоді обліковому запису служби потрібен доступ на читання до оновленого закритого ключа. Це створює додаткову роботу заради того самого результату.

#minio#s3#object-storage#self-hosted #vps