MinIO na Ubuntu 24.04: konfiguracja magazynu S3

Co zapewnia własny magazyn obiektowy z MinIO

MinIO to samodzielnie hostowany magazyn obiektowy obsługujący API Amazon S3. Wystarczy wskazać restic lub dowolny zestaw SDK S3 na własny serwer, zmienić ustawienie endpointu i gotowe – można korzystać z codziennych operacji odczytu, zapisu, listowania obiektów oraz generowania linków presigned. Zgodność nie oznacza jednak identyczności. MinIO na przykład nie implementuje list kontroli dostępu (ACL) obiektów Amazon i twórcy oświadczyli, że nie mają takiego zamiaru. Aplikacja zależna od zachowania ACL wymaga zatem czegoś więcej niż tylko zmiany endpointu. Niniejszy przewodnik opisuje budowę pojedynczego węzła na Ubuntu 24.04: plik binarny skompilowany ze zweryfikowanego źródła, dedykowanego użytkownika systemowego, jednostkę systemd przechowującą poświadczenia root poza plikiem konfiguracyjnym oraz bucket, do którego restic wykonuje kopie zapasowe.

S3 (Simple Storage Service) to API oparte na HTTP, a nie system plików. Obiekt umieszcza się w buckecie pod określonym kluczem za pomocą operacji PUT, a następnie pobiera za pomocą GET. W standardowym buckecie nie ma możliwości zapisu częściowego ani zmiany nazwy. Wyjątkiem są bucket-y typu directory w klasie S3 Express One Zone, które posiadają własne wywołania typu append i rename, jednak jest to tylko jedna klasa pamięci i niniejszy przewodnik z niej nie korzysta. Narzędzia do backupu preferują standardowy model, ponieważ obiekt albo dotarł w całości, albo wcale.

Jeden węzeł przechowuje jedną kopię danych. Jest to kompromis, na który decyduje się użytkownik. W zamian za koszt VPS otrzymuje się endpoint S3 pod pełną kontrolą, ale przejmuje się również wszystkie zadania, które wcześniej wykonywał dostawca chmurowy: od wymiany uszkodzonego dysku po aktualizacje oprogramowania serwera. Sekcja pod koniec przewodnika jasno określa, kiedy taki kompromis jest opłacalny.

Stan wersji społecznościowej MinIO w październiku 2026 roku

Przed przystąpieniem do pracy należy zapoznać się z tą sekcją, ponieważ niedawno wprowadzono istotne zmiany. W maju 2025 roku z konsoli webowej wersji społecznościowej MinIO usunięto funkcje administracyjne. W przeglądarce dostępna jest obecnie jedynie przeglądarka obiektów, dlatego zarządzanie bucketami oraz kluczami dostępu odbywa się za pomocą klienta wiersza poleceń mc.

W późniejszym okresie 2025 roku MinIO zaprzestało publikowania skompilowanych binariów dla wersji społecznościowej. Zgodnie z plikiem README projektu, edycja społecznościowa jest dystrybuowana wyłącznie w formie kodu źródłowego, a od kwietnia 2026 roku repozytorium minio/minio zostało zarchiwizowane z notą THIS REPOSITORY IS NO LONGER MAINTAINED. Stary serwer pobierania również przestał udostępniać pliki dla wersji społecznościowej. Stan na 20 października 2026 roku: każda ścieżka dl.min.io, z której korzystał ten przewodnik w celu pobrania binariów serwera, klienta oraz plików sum kontrolnych, zwraca błąd 410 Gone, co jest celowym usunięciem, a nie awarią. Jedynym binarium mc dostępnym jeszcze na tym serwerze jest AIStor Client w ścieżce /aistor/mc/release/, który należy do linii komercyjnej. Strona pobierania w domenie min.io wymienia obecnie AIStor Server, AIStor Client, AIStor SDK oraz kilka dodatków AIStor, a także darmową wersję AIStor przeznaczoną dla programistów, badaczy i małych organizacji prowadzących samodzielne wdrożenia; brak jest tam wersji społecznościowej.

Kod źródłowy jest nadal dostępny i jest nowszy niż ostatnie binarne wydanie. Ostatnim wydaniem społecznościowym jest RELEASE.2025-10-15T17-29-55Z, opublikowane 16 października 2025 roku jako wydanie bezpieczeństwa: usuwa ono lukę eskalacji uprawnień poprzez obejście polityki sesji w kontach serwisowych i STS, a informacje o wydaniu zalecają wszystkim użytkownikom natychmiastową aktualizację. Ostatnim skompilowanym binarium była wersja z września 2025 roku, więc nigdy nie otrzymała ona tej poprawki. Niniejszy przewodnik opisuje kompilację wydania październikowego, a ze względu na archiwizację repozytorium, jest to również ostatnia poprawka, jaką otrzyma edycja społecznościowa.

Ten fakt determinuje dalszą część przewodnika. Jest to powód, dla którego MinIO w tym przypadku nasłuchuje na 127.0.0.1 i łączy się z Internetem wyłącznie za pośrednictwem kontrolowanego przez administratora proxy.

Instalacja pliku binarnego MinIO i weryfikacja pobierania

MinIO jest napisane w języku Go, a plik README producenta przewiduje budowanie za pomocą pojedynczego polecenia go install, które wymaga wersji Go 1.24 lub nowszej. Najpierw zainstaluj Go z oficjalnego archiwum tarball. W dniu 20 października 2026 r. bieżące stabilne wydanie na stronie go.dev/dl to go1.27.3, opublikowane 19 października 2026 r. z poprawką bezpieczeństwa dla pakietu crypto/x509, a poniższy skrót jest wartością opublikowaną na tej stronie dla archiwum linux-amd64. Jeśli wybierzesz nowszą wersję Go, pobierz jej skrót z tej samej strony. Flaga -f powoduje, że curl kończy się niepowodzeniem w przypadku błędu HTTP, zamiast zapisywać stronę błędu pod żądaną nazwą; w przeciwnym razie użytkownicy kończą z rozpakowaną stroną 404, zastanawiając się, dlaczego nie jest to archiwum.

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

Porównaj oba skróty, porównując wyłącznie wartości skrótów.

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

Należy jasno określić, co dowodzi ta kontrola. Zgodność dowodzi, że pobieranie zostało ukończone i plik nie został uszkodzony ani zmieniony podczas przesyłania. Nie dowodzi to, że producent jest godny zaufania. Jest to odrębny problem, którego nie rozwiązuje żadne polecenie 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

Teraz zbuduj finalne wydanie społecznościowe jako zwykły użytkownik. go install sprawdza każdy pobierany moduł, w tym kod źródłowy MinIO, względem publicznej bazy sum kontrolnych Go pod adresem sum.golang.org, więc zmodyfikowany lub podmieniony moduł przerywa budowanie błędem bezpieczeństwa zamiast utworzenia pliku binarnego.

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 wyświetla DEVELOPMENT.GOGET w miejscu, gdzie powinna znajdować się nazwa wydania, ponieważ go install nie stosuje flag budowania używanych przez producenta do oznaczania własnych plików binarnych. go version -m odczytuje informacje o module, które Go osadza w każdym pliku binarnym, a jego linia mod github.com/minio/minio wskazuje commit, który został zbudowany. Wartość Permission denied w tym miejscu oznacza błędny tryb, a command not found oznacza, że /usr/local/bin nie znajduje się w Twoim PATH. Jeśli VPS ma zbyt mało pamięci do kompilacji, uruchom to samo go install na innej maszynie z systemem Linux o tej samej architekturze i skopiuj plik binarny.

Tworzenie użytkownika systemowego i katalogu danych

MinIO przyjmuje pliki przesyłane przez sieć, dlatego nie powinien działać jako root. Należy utworzyć dla niego konto bez katalogu domowego i bez powłoki logowania.

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 tworzy konto systemowe z UID poniżej 1000, dzięki czemu konto nie znajduje się w zakresie używanym przez użytkowników. -M pomija tworzenie katalogu domowego, ponieważ konto, na które nigdy się nie loguje, nie wymaga takiego katalogu. Wynik należy sprawdzić za pomocą id minio-user oraz stat -c '%U %a' /var/lib/minio, które powinno wypisać minio-user 750.

Katalog danych musi być zapisywalny przez tego użytkownika, a nie tylko dostępny do odczytu. Przy pierwszym uruchomieniu MinIO tworzy w woluminie katalog .minio.sys, w którym przechowuje własną konfigurację. Dlatego katalog należący do root powoduje zakończenie działania MinIO podczas uruchamiania komunikatem kończącym się wartością permission denied. Ta sama zasada dotyczy każdej usługi uruchamianej w ten sposób. Szczegółowo opisano ją w użytkownikach usług z minimalnymi uprawnieniami na VPS.

Umieść dane uwierzytelniające root w pliku środowiskowym

Dane uwierzytelniające root zapewniają dostęp do każdego zasobnika, dlatego nie powinny znajdować się w pliku jednostki, który jest czytelny dla wszystkich użytkowników. Najpierw utwórz plik z właściwymi uprawnieniami, a dopiero potem zapisz do niego dane. Dzięki temu hasło ani przez chwilę nie będzie znajdować się w pliku czytelnym dla innych użytkowników.

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 skraca istniejący plik zamiast tworzyć go ponownie, dlatego uprawnienia pozostają ustawione na 600, a właścicielem nadal jest root. Jest to działanie zamierzone. systemd odczytuje EnvironmentFile jako root, zanim obniży uprawnienia do User=. Konto usługi nie musi więc odczytywać własnych danych uwierzytelniających. Po uruchomieniu usługi należy potwierdzić ten stan za pomocą sudo -u minio-user cat /etc/default/minio. To polecenie musi wyświetlić Permission denied.

Przed uruchomieniem usługi należy znać dwa zachowania MinIO. Jeśli w środowisku nie ma MINIO_ROOT_USER ani MINIO_ROOT_PASSWORD, MinIO nie odmawia uruchomienia. Uruchamia się ze standardowymi, opisanymi w dokumentacji danymi uwierzytelniającymi minioadmin:minioadmin. Jest to pierwsza para sprawdzana przez skanery, a usługa podczas tego działania wygląda na całkowicie sprawną. Hasło krótsze niż 8 znaków jest natomiast odrzucane. MinIO kończy działanie podczas uruchamiania i wyświetla błąd informujący, że dane uwierzytelniające są nieprawidłowe, ponieważ klucz dostępu musi mieć co najmniej 3 znaki, a klucz tajny co najmniej 8 znaków.

MINIO_VOLUMES to ścieżka danych, a MINIO_OPTS zawiera flagi. Powiązanie z 127.0.0.1 oznacza, że nic spoza tego VPS nie może jeszcze uzyskać dostępu do API S3. Jest to właściwe ustawienie domyślne. Dostęp należy otworzyć celowo później, za pośrednictwem proxy z certyfikatem.

Tworzenie jednostki systemd

Utworzyć /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

Na początku EnvironmentFile nie ma -. Jest to celowe, a nie błąd. Z myślnikiem systemd ignoruje brakujący plik i mimo to uruchamia MinIO. Usunięty plik lub błędna ścieżka powodują więc bez ostrzeżenia uruchomienie serwera z użyciem minioadmin:minioadmin. Bez myślnika brakujący plik powoduje niepowodzenie jednostki, zanim MinIO zostanie uruchomione, a journalctl -u minio wyświetla Failed to load environment files: No such file or directory. Jednostkę, która odmawia uruchomienia, łatwiej zauważyć niż serwer po cichu akceptujący hasło domyślne.

$MINIO_VOLUMES i $MINIO_OPTS pozostają celowo nieujęte w cudzysłowy, ponieważ systemd dzieli nieujęte w cudzysłowy zmienne według białych znaków na osobne argumenty. W ten sposób cztery słowa w MINIO_OPTS stają się czterema argumentami dla minio server. LimitNOFILE=65536 zwiększa limit deskryptorów plików, ponieważ każde otwarte połączenie i każdy otwarty plik danych zajmuje jeden deskryptor, a domyślna wartość 1024 wyczerpuje się pod obciążeniem.

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 powinno wyświetlić active, a punkt końcowy kondycji powinien zwrócić 200. journalctl -u minio -n 20 --no-pager wyświetla adres API, na którym serwer nasłuchuje. Jeśli jednostka jest ciągle uruchamiana ponownie, systemd rezygnuje i zapisuje w dzienniku Start request repeated too quickly. Oznacza to, że MinIO kończy działanie przy każdej próbie. Przyczyna jest wyświetlana w wierszach poprzedzających ten komunikat, dlatego należy czytać w górę.

Aby zapewnić większą izolację, dodać ProtectSystem=full i ProtectHome=true do sekcji [Service]. Oba ustawienia wymagają przestrzeni nazw montowania udostępnianych przez jądro hosta. W przypadku wirtualizacji kontenerowej współdzielącej jądro hosta, takiej jak OpenVZ lub LXC, mogą one zakończyć się niepowodzeniem, a jednostka zgłosi wtedy status=226/NAMESPACE. Usunięcie tych dwóch wierszy pozwala ją uruchomić. Sama jednostka jest standardową jednostką, a usługi i czasomierze systemd na VPS obejmują pozostałe dyrektywy.

Instalacja mc i weryfikacja pełnego cyklu zapisu i odczytu

Klient MinIO to mc. Nie należy instalować go za pomocą apt install mc. Ten pakiet to Midnight Commander, menedżer plików niezwiązany z MinIO.

dl.min.io nadal udostępnia binaria mc, ale nie te przeznaczone dla społeczności. Stara ścieżka społecznościowa, https://dl.min.io/client/mc/release/linux-amd64/mc, odpowiada 410 Gone. MinIO oferuje tam obecnie AIStor Client pod adresem https://dl.min.io/aistor/mc/release/linux-amd64/mc, co potwierdza dokumentacja AIStor CLI, wskazując na funkcjonalność dostępną wyłącznie dla licencjonowanych wdrożeń AIStor Server. Dokumentacja ta nie wspomina o użyciu tego klienta z serwerem społecznościowym, dlatego niniejszy poradnik korzysta z klienta społecznościowego. Repozytorium minio/mc zostało zarchiwizowane w lipcu 2026 roku, dlatego należy zbudować jego ostatnie wydanie, RELEASE.2025-08-13T08-35-41Z, przy użyciu tego samego łańcucha narzędzi Go. Baza sum kontrolnych obejmuje również ten plik.

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

Zarejestruj serwer jako alias, a następnie prześlij obiekt.

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 powinno wyświetlić hello.txt wraz z rozmiarem, a mc cat powinno wypisać hello object storage. Ten pełny cykl zapisu i odczytu jest rzeczywistym dowodem działania serwera, ponieważ wykonuje te same podpisane żądania S3, co każdy inny klient. mc admin info local wyświetla status serwera, jeśli wymagana jest dodatkowa weryfikacja.

Wykonaj teraz jeszcze jeden test, dopóki zasób jest pusty.

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

To polecenie musi zakończyć się niepowodzeniem. Jeśli zakończy się sukcesem, plik środowiskowy nie został wczytany przez proces, a serwer działa na domyślnych poświadczeniach. Należy to naprawić przed wykonaniem jakichkolwiek innych działań na maszynie.

mc przechowuje aliasy w ~/.mc/config.json w postaci czystego tekstu, więc te poświadczenia znajdują się w katalogu domowym użytkownika, który uruchomił polecenie. Uruchomienie mc jako sudo umieszcza poświadczenia root w /root/.mc/config.json. Alias root należy zachować na jednym koncie administratora, a każdej aplikacji przydzielić własny klucz.

Udostępnianie pojedynczego obiektu za pomocą presigned URL

Presigned URL to zwykły odnośnik HTTPS z dołączonym podpisem oraz czasem wygaśnięcia. Każda osoba posiadająca ten link może pobrać dany obiekt bez konieczności posiadania konta czy klienta.

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

Dane wyjściowe zawierają X-Amz-Signature oraz X-Amz-Expires w ciągu zapytania. Dwie kwestie często zaskakują użytkowników. Link jest tworzony na podstawie punktu końcowego w użytym aliasie, więc alias na 127.0.0.1 generuje link, który może otworzyć tylko ta maszyna: dla linków przeznaczonych do wysyłki należy utworzyć drugi alias na publicznej nazwie hosta. Ponadto nie istnieje funkcja unieważniania pojedynczych linków. Podpis pozostaje ważny do momentu wygaśnięcia lub usunięcia bądź zmiany klucza, którym został podpisany. W przypadku linku podpisanego poświadczeniami root oznacza to konieczność ich rotacji, dlatego krótkie wygaśnięcie jest jedynym praktycznym mechanizmem kontroli. Siedem dni to maksymalny czas dozwolony przez format podpisu S3.

Nadaj restic własny klucz i bucket

Poświadczenia root pozwalają odczytywać i usuwać każdy bucket, dlatego zadanie tworzenia kopii zapasowej nie może ich używać. Należy utworzyć bucket, zasadę dostępu ograniczoną do tego bucketa oraz użytkownika, który nie otrzyma żadnych innych uprawnień.

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 udostępnia wbudowaną zasadę readwrite, dzięki której można byłoby użyć o jedną komendę mniej. Przyznaje ona jednak pełny dostęp do każdego bucketa na serwerze. W powyższej zasadzie nazwa bucketa występuje celowo dwa razy: raz jako arn:aws:s3:::restic, aby możliwe było wyświetlanie zawartości bucketa, oraz raz jako arn:aws:s3:::restic/* dla obiektów znajdujących się w tym buckecie. W S3 bucket i jego obiekty są oddzielnymi zasobami, dlatego zasada zawierająca tylko jeden z nich kończy się błędem, który może wyglądać jak problem z klientem.

Przed użyciem należy sprawdzić ograniczenie.

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

Pierwszy ls kończy się powodzeniem, a drugi kończy się błędem Access Denied. Nieprzetestowana zasada jest tylko przypuszczeniem.

Następnie należy wskazać bucket w restic. restic odczytuje poświadczenia S3 ze standardowych zmiennych środowiskowych AWS, dlatego nie jest potrzebny plik poświadczeń specyficzny dla 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 żąda hasła do repozytorium. Hasło szyfruje repozytorium, dlatego MinIO przechowuje wyłącznie szyfrogram, a utrata hasła oznacza utratę kopii zapasowej. Zadanie uruchomione przez timer systemd nie ma terminala, w którym można wpisać hasło, dlatego w przypadku zaplanowanych kopii zapasowych należy ustawić RESTIC_PASSWORD_FILE na plik z uprawnieniami 600.

Jedna zasada dotycząca lokalizacji ma większe znaczenie niż wszystkie powyższe komendy. Repozytorium restic na tym samym VPS co chronione dane chroni przed błędnym rm, ale przed niczym więcej. Węzeł MinIO powinien znajdować się na innym komputerze, najlepiej w innym regionie. kopie zapasowe restic na VPS opisuje planowanie i przechowywanie kopii na podstawie tej konfiguracji.

Terminowanie TLS za pomocą nginx

MinIO działa na localhost, dlatego nginx stanowi publiczny interfejs. Najpierw wystaw certyfikat zgodnie z opisem w Certyfikaty Let's Encrypt za pomocą certbot i nginx, a następnie użyj tego bloku serwera.

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;
    }
}

Kilka z tych wierszy ma kluczowe znaczenie. client_max_body_size 0 usuwa domyślny limit rozmiaru treści wynoszący 1 MB. Bez tego limitu każdy większy upload jest odrzucany za pomocą 413 Request Entity Too Large, zanim MinIO w ogóle otrzyma żądanie. proxy_request_buffering off przekazuje upload bezpośrednio dalej, ponieważ domyślna konfiguracja najpierw zapisuje całe żądanie w pliku tymczasowym. Duży obiekt wymaga wtedy dwukrotnie większej ilości miejsca na dysku. proxy_set_header Host $http_host jest mniej oczywiste: podpis S3 obejmuje nagłówek Host, dlatego proxy, które go przepisuje, powoduje niepowodzenie każdego żądania z komunikatem SignatureDoesNotMatch, mimo że access log pokazuje prawidłowo odebrane żądanie.

Należy również przekazać MinIO jego publiczną nazwę, aby generowane przez nie odnośniki wskazywały proxy, a nie localhost.

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

Reguły zapory pozostają ograniczone do minimum. Należy zezwolić na SSH i HTTPS, a dla portów 9000 i 9001 nie definiować żadnej reguły. Adres powiązany z 127.0.0.1 jest nieosiągalny z innego komputera niezależnie od konfiguracji zapory. Polecenia opisano w Podstawy konfiguracji zapory ufw na VPS.

Kiedy pojedynczy węzeł MinIO jest wystarczający, a kiedy potrzebne jest prawdziwe S3

Pojedynczy węzeł oznacza tutaj jeden dysk, co oznacza brak parzystości i brak drugiej kopii wewnątrz wdrożenia. Trwałość każdego obiektu jest równa trwałości pojedynczego dysku VPS. Dokumentacja samego MinIO, która od czasu usunięcia hostowanej dokumentacji społecznościowej w październiku 2025 roku istnieje wyłącznie jako kod źródłowy w repozytorium minio/docs, opisuje wdrożenie typu standalone jako przeznaczone do wczesnych prac rozwojowych i ewaluacji. MinIO nie zaleca stosowania go w środowiskach produkcyjnych. Blokadę obiektów (object locking) można włączyć dla bucketa, ale na pojedynczym VPS chroni ona jedynie przed usunięciem przez API S3. Każdy użytkownik z uprawnieniami root na maszynie może nadal usunąć pliki z dysku, dlatego nie należy obiecywać nikomu niezmiennej polityki retencji w tej konfiguracji.

Jest to dobre rozwiązanie jako cel dla restic na drugim serwerze VPS w innym regionie oraz jako endpoint S3 do prac programistycznych i artefaktów CI, gdzie utrata bucketa oznacza jedynie konieczność ponownego zbudowania danych. Jest to również rozsądny wybór dla plików przesyłanych przez użytkowników w małych aplikacjach, pod warunkiem posiadania planu odzyskiwania danych i jego faktycznego przetestowania.

Należy wybrać zarządzane S3, gdy umowa lub regulator wymaga blokady obiektów (object lock) lub trwałości międzyregionalnej, albo gdy woli się nie być osobą wzywaną o 03:00 z powodu zapełnienia dysku. Zamrożony kod to kolejny uczciwy powód. Na dzień 20 października 2026 roku edycja społecznościowa jest zarchiwizowana i nie jest już utrzymywana, a jej ostatnie wydanie, RELEASE.2025-10-15T17-29-55Z, jest tym, które kompiluje niniejszy przewodnik. Żadne błędy po tej wersji nie zostaną naprawione, więc korzystanie z niej oznacza akceptację tego stanu lub przejście na komercyjną linię AIStor od MinIO bądź inne rozwiązanie self-hosted, które porównuje alternatywy dla self-hosted MinIO.

Warto zaznaczyć jedną granicę, ponieważ często pojawia się ona w pytaniach. Pamięć obiektowa nie jest bazą danych. W standardowym buckecie każdy zapis zastępuje cały obiekt, a nawet wywołanie append dodane przez Amazon dla S3 Express One Zone jedynie dopisuje dane na końcu, więc aktywny plik SQL na buckecie S3 jest wolny i niebezpieczny. Bazę danych należy przechowywać na lokalnym dysku i wykonywać jej kopie zapasowe do bucketa: uruchamianie SQLite na produkcji na VPS opisuje ten podział.

Tryby awarii i komunikaty błędów

Jednostka kończy działanie natychmiast po systemctl enable --now. Przeczytaj journalctl -u minio -n 30 --no-pager. Komunikat Failed to load environment files: No such file or directory oznacza, że /etc/default/minio nie istnieje lub ścieżka do niego w pliku jednostki jest błędna. Komunikat kończący się permission denied oznacza, że konto usługi nie ma uprawnień do zapisu w katalogu danych; sprawdź, czy polecenie stat -c '%U' /var/lib/minio/data zwraca minio-user.

minioadmin:minioadmin nadal loguje się do systemu. Plik środowiskowy nie został wczytany przez proces. Upewnij się, że jednostka zawiera EnvironmentFile=/etc/default/minio, wykonaj sudo systemctl daemon-reload, a następnie zrestartuj usługę. MinIO odczytuje poświadczenia administratora tylko podczas uruchamiania, więc edycja pliku bez restartu nie przynosi efektu.

Address already in use podczas startu. Inny proces zajmuje port 9000. Zidentyfikuj go za pomocą sudo ss -ltnp | grep :9000 przed zmianą portu MinIO.

Przesyłanie plików powyżej 1 MB kończy się niepowodzeniem przez proxy. nginx zwrócił 413 Request Entity Too Large, a żądanie nie dotarło do MinIO. Ustaw client_max_body_size 0 w bloku serwera.

SignatureDoesNotMatch. Klucz tajny jest nieprawidłowy lub element pośredniczący między klientem a MinIO zmodyfikował nagłówek Host, który jest objęty sygnaturą.

RequestTimeTooSkewed. Zegar na kliencie lub serwerze jest nieprawidłowy. Każde podpisane żądanie S3 zawiera znacznik czasu, a MinIO, podobnie jak Amazon S3, odrzuca żądania z podpisem, jeśli znacznik czasu różni się o więcej niż 15 minut od czasu serwera. W przypadku linków z wstępnie podpisanym dostępem sprawdzany jest czas wygaśnięcia. Sprawdź timedatectl i upewnij się, że synchronizacja czasu jest aktywna.

Access Denied dla istniejącego zasobnika. Klucz jest ograniczony do innego zasobnika. Wyświetl rzeczywiste uprawnienia polityki za pomocą mc admin policy info local restic-rw i porównaj nazwę zasobnika w liniach zasobów.

FAQ

Czy MinIO w konfiguracji jednowęzłowej wystarcza do tworzenia rzeczywistych kopii zapasowych?

Jest to rozwiązanie wystarczające jako cel dla restic, o ile działa na maszynie oddzielonej od chronionych danych. Nie jest to jednak wystarczające rozwiązanie jako jedyna kopia. Wdrożenie na pojedynczym dysku nie zapewnia parzystości, więc wewnątrz MinIO nie istnieje druga kopia danych. Jeśli dysk VPS ulegnie awarii, obiekty zostaną utracone. Należy utrzymywać drugi cel w innej lokalizacji i przynajmniej raz przetestować przywracanie danych z obu lokalizacji, aby upewnić się, że proces jest poprawny.

Dlaczego sha256sum -c kończy się niepowodzeniem przy pliku sumy kontrolnej MinIO?

Z tym plikiem można się spotkać tylko w przypadku kopii zapisanej wcześniej, ponieważ dl.min.io odpowiedziało 410 Gone dla każdego binarnego pliku społecznościowego oraz pliku sumy kontrolnej podczas weryfikacji w dniu 20 października 2026. Etykieta po skrócie wewnątrz tego pliku wskazuje wydanie, na przykład minio.RELEASE.2025-09-07T16-13-09Z, podczas gdy pobrany plik zazwyczaj nazywa się minio. sha256sum -c szuka pliku o nazwie zapisanej wewnątrz pliku sumy kontrolnej, nie znajduje go i zgłasza No such file or directory oraz WARNING: 1 listed file could not be read. Pobieranie przebiegło poprawnie. Należy porównać ciągi skrótów bezpośrednio i zignorować etykietę, która nie ma znaczenia dla bezpieczeństwa.

Gdzie podziała się konsola administracyjna MinIO?

W maju 2025 roku MinIO usunęło funkcje administracyjne z konsoli wersji społecznościowej, pozostawiając w interfejsie WWW jedynie przeglądarkę obiektów. Wiadra (buckets) i użytkownicy są teraz zarządzani za pomocą klienta mc przy użyciu poleceń takich jak mc admin user add oraz mc admin policy attach. Jest to zamierzona ścieżka w wersji społecznościowej, a nie obejście problemu, dlatego niniejszy przewodnik wykonuje wszystkie operacje z poziomu wiersza poleceń.

Jak wskazać restic na MinIO jako backend S3?

Należy ustawić AWS_ACCESS_KEY_ID oraz AWS_SECRET_ACCESS_KEY na klucz dostępu MinIO i jego sekret, a następnie użyć ciągu repozytorium w formacie s3:https://s3.example.com/restic, gdzie ostatni element ścieżki to nazwa wiadra. Wiadro należy utworzyć wcześniej za pomocą mc mb, ponieważ klucz ograniczony do jednego wiadra nie posiada uprawnień do tworzenia nowych wiader. restic szyfruje wszystko własnym hasłem repozytorium przed wysyłką, więc MinIO przechowuje szyfrogram i nigdy nie widzi plików użytkownika.

Czy muszę uruchamiać MinIO za nginx?

TLS (transport layer security) jest wymagany, gdy klient nie znajduje się na tej samej maszynie. Bez niego każdy obiekt przesyłany jest przez sieć otwartym tekstem, wraz z identyfikatorem klucza dostępu i sygnaturą żądania. Sam klucz sekretny nigdy nie opuszcza klienta, ponieważ podpisywanie S3 wykorzystuje go tylko lokalnie do obliczenia sygnatury, jednak każda osoba na trasie przesyłu może odczytać dane i powtórzyć przechwycone żądanie, dopóki jego znacznik czasu jest ważny. Proxy na porcie 443 z certyfikatem od certbot to najprostszy sposób na uzyskanie TLS, który dodatkowo separuje proces odnawiania certyfikatów od MinIO. MinIO może również samodzielnie terminować TLS, jeśli wskaże się --certs-dir na katalog zawierający public.crt oraz private.key, jednak wtedy konto usługi wymaga uprawnień do odczytu odnowionego klucza prywatnego, co stanowi dodatkową pracę przy tym samym rezultacie.