MinIO на VPS: власне S3-сховище на Ubuntu 24.04

Що дає self-hosted object storage з MinIO

MinIO — це self-hosted object storage, який підтримує Amazon S3 API. Спрямуйте restic або S3 SDK на власний сервер, змініть один параметр endpoint — і для звичайного читання, запису, перегляду об’єктів та роботи з presigned links цього достатньо. Сумісність, однак, не означає ідентичну реалізацію. Наприклад, MinIO не реалізує object ACLs Amazon, і його maintainers заявили, що не планують цього робити. Тому застосунку, який залежить від поведінки ACL, недостатньо лише нового endpoint. У цьому посібнику створюється один вузол на Ubuntu 24.04: binary, скомпільований із перевіреного source code, виділений system user, unit systemd, який не зберігає root credentials у unit file, і bucket, у який restic записує резервні копії.

S3 (simple storage service) — це HTTP API, а не файлова система. Ви виконуєте PUT об’єкта в bucket за key, а потім GET цього об’єкта. У стандартному bucket немає часткового запису та перейменування. Винятком є directory buckets Amazon S3 Express One Zone, які мають власні виклики append і rename, але це окремий storage class, і в цьому посібнику він не використовується. Backup tools зручно працюють за стандартною моделлю, оскільки об’єкт або записано повністю, або його не записано.

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

Стан community edition MinIO станом на жовтень 2026 року

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

Пізніше, у 2025 році, MinIO припинив публікувати попередньо скомпільовані community binaries. У README проєкту зазначено, що community edition поширюється лише у вигляді вихідного коду, а з квітня 2026 року репозиторій minio/minio заархівовано з повідомленням THIS REPOSITORY IS NO LONGER MAINTAINED. Старий сервер завантажень також припинив обслуговувати community files. Станом на 20 жовтня 2026 року кожен шлях dl.min.io, з якого цей посібник раніше завантажував server binary, client binary і файли контрольних сум, повертає 410 Gone. Це навмисне вилучення, а не збій. Єдиний mc binary, який досі доступний на цьому сервері, — AIStor Client за адресою /aistor/mc/release/; він належить до комерційної лінійки. На сторінці завантажень min.io тепер перелічено AIStor Server, AIStor Client, AIStor SDK і кілька AIStor add-ons, а також безкоштовний рівень AIStor, який описано як призначений для розробників, дослідників і невеликих організацій, що запускають standalone deployments. Community build там немає.

Вихідний код досі доступний, і він новіший за останній binary. Фінальний community release — RELEASE.2025-10-15T17-29-55Z, опублікований 16 жовтня 2025 року як security release. Він усуває підвищення привілеїв через обхід session policy у service accounts і STS. У release notes усім користувачам рекомендовано негайно оновитися. Останнім попередньо скомпільованим binary була збірка за вересень 2025 року, тому це виправлення до неї не потрапило. Цей посібник компілює жовтневий release, а оскільки репозиторій заархівовано, це також останнє виправлення, яке отримає community edition.

Цей факт визначає подальшу структуру посібника. Саме тому MinIO тут прослуховує 127.0.0.1, а доступ до інтернету отримує лише через проксі, який ви контролюєте.

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

MinIO написано мовою Go, а README постачальника збирає його однією командою go install, для якої потрібен Go 1.24 або новіша версія. Спочатку встановіть Go з офіційного tarball. Станом на 20 October 2026 поточний стабільний реліз на go.dev/dl — go1.27.3. Його випущено 19 October 2026 із виправленням безпеки в пакеті crypto/x509. Хеш нижче опубліковано на цій сторінці для архіву linux-amd64. Якщо виберете новішу версію Go, візьміть її хеш із тієї самої сторінки. Прапорець -f змушує curl завершуватися з помилкою HTTP замість збереження сторінки помилки під вказаним ім’ям. Інакше можна розпакувати сторінку 404 і дивуватися, чому це не архів.

cd /tmp
GOVER=go1.27.3
curl -fsSL "https://go.dev/dl/$GOVER.linux-amd64.tar.gz" -o go.tar.gz

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

published=65efbc80fdc1fa2cd2631cad5b481777a68e8725f34e89f50fc6ac714e379b40
downloaded=$(sha256sum go.tar.gz | awk '{print $1}')
[ "$published" = "$downloaded" ] && echo "checksum ok"

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

sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go.tar.gz
export PATH=$PATH:/usr/local/go/bin
go version

Тепер зберіть фінальний community release від імені звичайного користувача. go install перевіряє кожен завантажений модуль, зокрема власний вихідний код MinIO, за допомогою загальнодоступної бази контрольних сум Go за адресою sum.golang.org. Тому змінений або підмінений модуль зупиняє збирання з помилкою безпеки, а не призводить до створення бінарного файлу.

go install github.com/minio/minio@RELEASE.2025-10-15T17-29-55Z
sudo install -o root -g root -m 755 ~/go/bin/minio /usr/local/bin/minio
minio --version
go version -m /usr/local/bin/minio | head -n 3

minio --version виводить DEVELOPMENT.GOGET замість назви релізу, оскільки go install не застосовує прапорці збирання, які постачальник використовував для маркування власних бінарних файлів. go version -m читає відомості про модуль, які Go вбудовує в кожен бінарний файл, а його рядок mod github.com/minio/minio містить назву коміту, з якого виконано збирання. Значення Permission denied тут означає, що режим неправильний, а command not found — що /usr/local/bin немає у вашому PATH. Якщо VPS має недостатньо пам’яті для компіляції, виконайте ту саму go install на іншій машині Linux із такою самою архітектурою та скопіюйте бінарний файл.

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

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 завершує роботу під час запуску з помилкою про недійсні облікові дані, оскільки ключ доступу має містити щонайменше 3 символи, а секретний ключ — щонайменше 8.

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

Створіть unit 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. Без дефіса відсутній файл зупиняє unit до запуску MinIO, а journalctl -u minio показує Failed to load environment files: No such file or directory. Unit, який відмовляється запускатися, набагато легше помітити, ніж сервер, що непомітно приймає пароль за замовчуванням.

$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, на якій сервер приймає з’єднання. Якщо unit постійно перезапускається, systemd припиняє спроби та записує Start request repeated too quickly. Це означає, що MinIO завершує роботу під час кожної спроби. Причину наведено в рядках перед цим повідомленням, тому перегляньте журнал вище.

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

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

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

dl.min.io і далі постачає бінарний файл mc, але це не community-версія. Старий community-шлях, https://dl.min.io/client/mc/release/linux-amd64/mc, повертає 410 Gone. Тепер MinIO пропонує там AIStor Client за адресою https://dl.min.io/aistor/mc/release/linux-amd64/mc. У довіднику AIStor CLI цей клієнт описано як такий, що має ексклюзивні функції для ліцензованих розгортань AIStor Server. У довіднику нічого не сказано про використання цього клієнта з community-сервером, тому в цьому посібнику використовується community-клієнт. Репозиторій minio/mc заархівовано з July 2026, тому зберіть його останній реліз, RELEASE.2025-08-13T08-35-41Z, за допомогою того самого Go toolchain. База даних контрольних сум також містить цей завантажуваний файл.

go install github.com/minio/mc@RELEASE.2025-08-13T08-35-41Z
sudo install -o root -g root -m 755 ~/go/bin/mc /usr/local/bin/mc

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

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 зберігає alias в ~/.mc/config.json у вигляді звичайного тексту, тому ці облікові дані містяться в домашньому каталозі користувача, який виконав команду. Виконання mc від імені sudo поміщає облікові дані root у /root/.mc/config.json. Залиште root alias в одному обліковому записі адміністратора, а для кожного застосунку створіть власний ключ.

Надати один об’єкт за 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. Окремої кнопки для відкликання посилання немає. Підпис залишається дійсним, доки не завершиться його строк дії або доки ключ, яким його підписано, не буде видалено чи змінено. Для посилання, підписаного root credentials, це означає їх ротацію. Тому практичним засобом контролю є короткий строк дії. Максимальний строк, який допускає формат підпису S3, становить 7 днів.

Надайте 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 block.

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. Інакше nginx відхилить будь-яке більше завантаження з помилкою 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

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

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

Одновузлове розгортання тут означає один диск. Тому в ньому немає ані паритету, ані другої копії даних, а довговічність кожного об’єкта визначається довговічністю диска одного VPS. Власна документація MinIO, яка після вилучення розміщеної документації спільноти в October 2025 залишилася лише у вигляді вихідного коду в репозиторії minio/docs, описує standalone-розгортання як призначене для початкової розробки та оцінювання і зазначає, що MinIO не рекомендує його для production. Для bucket можна увімкнути object locking, але на одному VPS це лише забороняє видалення через S3 API. Будь-хто, хто має root на машині, усе одно може видалити файли з диска. Тому не обіцяйте для такої конфігурації незмінну політику зберігання.

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

Обирайте managed S3, коли цього вимагає договір або регулятор, зокрема для object lock чи довговічності в кількох регіонах. Також це варто зробити, якщо ви не хочете отримувати сповіщення о 03:00 через переповнений диск. Заморожений код — ще одна важлива причина. Станом на 20 October 2026 edition для спільноти заархівовано, його більше не підтримують, а його останній release, RELEASE.2025-10-15T17-29-55Z, — це версія, яку збирає цей посібник. Після неї виправлень не буде. Її використання означає прийняття цього обмеження або перехід на комерційну лінійку MinIO AIStor чи на інше self-hosted сховище, з яким можна ознайомитися в порівнянні альтернатив self-hosted MinIO.

Варто окремо визначити межу, про яку часто запитують. Object storage — не database. У стандартному bucket кожен запис замінює весь об’єкт. Навіть append-виклик, який Amazon додав для S3 Express One Zone, лише дописує дані в кінець. Тому live SQL-файл у S3 bucket працює повільно й ненадійно. Зберігайте database на локальному диску, а резервну копію створюйте в bucket. Такий поділ описано в матеріалі запуск SQLite у production на VPS.

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

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

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

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 у блоці server.

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

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

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

FAQ

Чи достатньо single-node MinIO для реальних резервних копій?

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

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

Ви зустрінете цей файл лише в копії, збереженій раніше, оскільки dl.min.io повертала 410 Gone для кожного community binary і файла контрольної суми під час перевірки 20 October 2026. Позначка після хешу всередині цього файла містить назву релізу, наприклад minio.RELEASE.2025-09-07T16-13-09Z, тоді як завантажений файл зазвичай називається minio. sha256sum -c шукає файл із назвою, записаною у файлі контрольної суми, не знаходить його та повідомляє No such file or directory і WARNING: 1 listed file could not be read. Завантаження виконано правильно. Безпосередньо порівняйте рядки хешів і проігноруйте позначку, оскільки вона не має безпекового значення.

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

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

Як підключити restic до MinIO як S3 backend?

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

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

TLS (transport layer security) потрібен, якщо клієнт працює не на тій самій машині, оскільки без нього кожен об’єкт передається мережею у відкритому вигляді разом з access key ID і підписом запиту. Сам secret key ніколи не залишає клієнта, оскільки під час S3 signing він локально використовується лише для обчислення цього підпису. Проте будь-хто на шляху передавання може прочитати ваші дані та повторно надіслати перехоплений запит, доки чинна його мітка часу. Proxy на port 443 із сертифікатом від certbot — найпростіший спосіб увімкнути TLS. Крім того, поновлення сертифіката не потрібно виконувати в MinIO. MinIO також може самостійно завершувати TLS, якщо вказати --certs-dir на directory, що містить public.crt і private.key. У такому разі service account має отримати доступ на читання до поновленого private key, а це додаткова робота заради того самого результату.