MinIO VPS 自架 S3 物件儲存教學

MinIO 自架物件儲存提供的功能

MinIO 是支援 Amazon S3 API 的自架物件儲存。將 restic 或 S3 SDK 指向自己的伺服器，只需變更一項 endpoint 設定，就能處理日常的物件讀取、寫入、列出及 presigned link。相容不代表完全相同。例如，MinIO 未實作 Amazon 的物件 ACL，維護者也表示無意支援。因此，依賴 ACL 行為的應用程式不只需要更換 endpoint。本指南會在 Ubuntu 24.04 上建立單一節點：使用通過驗證來源編譯的 binary、專用 system user、將 root 憑證排除在 unit file 外的 systemd unit，以及讓 restic 備份資料的 bucket。

S3（simple storage service）是 HTTP API，而不是檔案系統。您會在 bucket 中使用 key 以 PUT 寫入物件，再以 GET 取回；在標準 bucket 中，物件無法部分寫入，也不能重新命名。Amazon 的 S3 Express One Zone directory bucket 是例外，具備自己的 append 和 rename 呼叫；但那是單一儲存類別，本指南不依賴這些功能。備份工具偏好標準模型，因為物件不是完整到達，就是未能到達。

單一節點只保留資料的一份副本。這就是您所做的取捨。您只需支付 VPS 的費用，就能取得自行控制的 S3 endpoint；同時也必須自行處理雲端服務供應商原本負責的所有工作，從更換故障磁碟到修補伺服器軟體。本指南接近結尾的章節會直接說明這項取捨何時合理。

2026 年 10 月 MinIO 社群版的狀態

請先閱讀本節，再依此進行建置，因為近期狀態已有變更。2025 年 5 月，MinIO 從社群版的 Web 主控台移除了管理功能。瀏覽器中保留的只是物件瀏覽器，因此現在必須改用 mc 命令列用戶端管理儲存貯體與存取金鑰。

2025 年稍後，MinIO 停止發布預先編譯的社群版二進位檔。專案 README 表示，社群版僅以原始碼形式散布；自 2026 年 4 月起，minio/minio 儲存庫也已依 THIS REPOSITORY IS NO LONGER MAINTAINED 的公告封存。舊下載伺服器同樣已停止提供社群版檔案。截至 2026 年 10 月 20 日，本指南過去用於下載的每個 dl.min.io 路徑，包括伺服器二進位檔、用戶端二進位檔及其 checksum 檔案，皆回應 410 Gone。這是刻意移除，不是服務中斷。該伺服器上唯一仍存在的 mc 二進位檔，是位於 /aistor/mc/release/ 的 AIStor Client，屬於商業產品線。min.io 的下載頁面目前列出 AIStor Server、AIStor Client、AIStor SDK 及數個 AIStor 附加元件，另有一個免費的 AIStor 方案，說明其目標對象是執行獨立部署的開發人員、研究人員及小型組織；頁面上已沒有社群版建置。

原始碼仍然存在，版本也比最後一個二進位檔新。最後一個社群版版本是 RELEASE.2025-10-15T17-29-55Z，於 2025 年 10 月 16 日發布，屬於安全性版本：修正服務帳號與 STS 中，透過工作階段原則繞過機制造成的權限提升問題。版本資訊建議所有使用者立即升級。最後一個預先編譯的二進位檔是 2025 年 9 月的建置，因此未包含這項修正。本指南會編譯 10 月版本；由於儲存庫已封存，這也是社群版最後能取得的修正。

這項事實會影響本指南的其餘內容。因此，本文中的 MinIO 會監聽 127.0.0.1，並且只透過由你控管的代理連線至網際網路。

安裝 MinIO 二進位檔並驗證下載內容

MinIO 以 Go 撰寫，供應商 README 使用單一 go install 命令進行建置，且需要 Go 1.24 或更新版本。請先從官方 tarball 安裝 Go。在 20 October 2026，go.dev/dl 上的目前穩定版本為 go1.27.3。該版本於 19 October 2026 發布，修正了 crypto/x509 套件的安全性問題。以下雜湊值是該頁面針對 linux-amd64 archive 發布的值。若選用較新的 Go 版本，請從同一頁面取得對應的雜湊值。-f 旗標會讓 curl 在 HTTP 錯誤時失敗，而不是將錯誤頁面以指定的檔名儲存。否則解開 404 頁面後，便會疑惑它為何不是 archive。

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

現在以一般使用者身分建置最終的社群版本。go install 會將其下載的每個模組，包括 MinIO 自身的原始碼，與 Go 的公開 checksum database 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 行會列出你所建置的 commit。此處若顯示 Permission denied，表示模式不正確；顯示 command not found，則表示 /usr/local/bin 不在你的 PATH 上。若 VPS 的記憶體不足以完成編譯，請在相同架構的另一台 Linux 電腦上執行相同的 go install，再將二進位檔複製過來。

建立系統使用者與資料目錄

MinIO 接受來自網路的上傳，因此不應以 root 身分執行。為它建立沒有家目錄且沒有登入 shell 的帳戶。

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 file 中。請先以正確的模式建立檔案，再寫入內容。如此一來，密碼不會有任何時刻存在於可讀取的檔案中。

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 會在降低權限至 User= 之前，以 root 身分讀取 EnvironmentFile，因此服務帳戶不需要讀取自己的憑證。服務啟動後，使用 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 儲存 flags。繫結至 127.0.0.1 表示 VPS 外部目前無法連線至 S3 API，這是適當的預設設定。之後再透過持有憑證的 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 中的 4 個字詞會成為 minio server 的 4 個引數的原因。LimitNOFILE=65536 會提高檔案描述元上限，因為每個開啟的連線和資料檔案都會占用 1 個描述元，而預設值 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，而健康狀態端點應回應 200。journalctl -u minio -n 20 --no-pager 會顯示伺服器正在監聽的 API 位址。如果單元持續重新啟動，systemd 會放棄並記錄 Start request repeated too quickly。這表示 MinIO 每次嘗試都會結束執行；原因會顯示在該訊息上方的幾行，因此請向上查看。

若要進一步隔離，請將 ProtectSystem=full 和 ProtectHome=true 加入 [Service] 區段。兩者都需要主機核心提供 mount namespace。在共用主機核心的容器虛擬化環境中，例如 OpenVZ 或 LXC，這些設定可能會失敗，單元隨後會回報 status=226/NAMESPACE。移除這兩行後即可啟動。此單元本身是一般單元，而 VPS 上的 systemd 服務與計時器涵蓋其餘指示詞。

安裝 mc 並驗證完整往返

MinIO client 是 mc。不要使用 apt install mc 安裝它。該套件是 Midnight Commander，是與 MinIO 無關的檔案管理器。

dl.min.io 仍提供 mc binary，但不是社群版。舊的社群版路徑 https://dl.min.io/client/mc/release/linux-amd64/mc 會回應 410 Gone。MinIO 目前在該處提供的是 https://dl.min.io/aistor/mc/release/linux-amd64/mc 的 AIStor Client；AIStor CLI 參考文件指向此用戶端，並說明它具備僅供授權 AIStor Server 部署使用的專屬功能。該參考文件沒有說明可將其用於社群版伺服器，因此本指南仍使用社群版 client。minio/mc repository 自 July 2026 起已封存，因此請使用相同的 Go toolchain 建置其最後版本 RELEASE.2025-08-13T08-35-41Z。checksum database 也涵蓋此下載項目。

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，然後透過它傳送一個 object。

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。這趟往返才是伺服器正常運作的實際證明，因為它會發出其他 client 都會發出的相同簽署 S3 requests。若要再次確認，mc admin info local 會輸出伺服器狀態。

現在再執行一項檢查，此時主機仍是空的。

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

此命令必須失敗。若命令成功，表示環境檔未傳遞給 process，而伺服器正使用預設 credentials。先修正此問題，再讓其他任何內容接觸這台主機。

mc 會以純文字將 aliases 儲存在 ~/.mc/config.json，因此這些 credentials 會留在執行該命令之使用者的 home directory 中。以 sudo 執行 mc 會將 root credentials 放入 /root/.mc/config.json。將 root alias 保留給一個管理員帳號，並為每個應用程式建立專屬 key。

使用預簽署 URL 提供單一物件

預簽署 URL 是附帶簽章與到期時間的標準 HTTPS 連結。任何取得連結的人，都能在不需帳號或用戶端的情況下擷取該物件。

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

輸出內容會在查詢字串中包含 X-Amz-Signature 與 X-Amz-Expires。其中有兩點常讓人意外。連結會依據所使用別名中的端點建立，因此在 127.0.0.1 上的別名會產生只有這台機器能開啟的連結；如果要傳送連結，請在公開主機名稱上建立第二個別名。其次，系統沒有針對單一連結的撤銷按鈕。簽章會持續有效，直到到期，或簽署該連結的金鑰遭到移除或變更為止。若連結是使用 root 憑證簽署，這代表必須輪替 root 憑證。因此，設定較短的到期時間是實際可行的控制方式。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 policy。使用它可以少執行一個命令，但它會授予對伺服器上所有 bucket 的完整存取權。上方的 policy 刻意將 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 而失敗。未經測試的 policy 只是猜測。

現在讓 restic 使用這個 bucket。restic 會從標準 AWS 環境變數讀取 S3 憑證，因此不需要 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 會要求輸入 repository 密碼。該密碼會加密 repository，因此 MinIO 只會儲存密文；遺失密碼也會遺失備份。由 systemd timer 啟動的執行工作沒有終端機可供輸入，因此請將 RESTIC_PASSWORD_FILE 設為 mode 600 的檔案，以用於排程備份。

有一項儲存位置規則比上述任何命令都重要。將 restic repository 放在與受保護資料相同的 VPS 上，只能讓您避免不良的 rm，無法避免其他問題。MinIO 節點應位於不同的機器上，最好位於不同的 region。VPS 上的 restic 備份說明如何在此基礎上設定排程和保留策略。

使用 nginx 終止 TLS

MinIO 位於 localhost，因此 nginx 是對外服務介面。請先依照 使用 certbot 和 nginx 取得 Let's Encrypt 憑證 簽發憑證，然後使用以下伺服器區塊。

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 請求本文大小限制，否則任何較大的上傳都會在 MinIO 收到請求前，先因 413 Request Entity Too Large 而遭拒絕。proxy_request_buffering off 會直接串流上傳內容，因為預設設定會先將整個請求寫入暫存檔，而大型物件會因此需要兩倍的磁碟空間。proxy_set_header Host $http_host 是較容易忽略的設定：S3 簽章會涵蓋 Host 標頭，因此 Proxy 若改寫該標頭，所有請求都會因 SignatureDoesNotMatch 而失敗，即使存取日誌顯示請求已正常送達。

另外，請告知 MinIO 其對外公開名稱，讓它產生的連結指向 Proxy，而不是 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 的位址無論防火牆設定為何，都無法從其他機器連線。VPS 上的 ufw 防火牆基本設定 說明所需的命令。

單節點 MinIO 何時已足夠，以及何時應選用真正的 S3

這裡的單節點代表只有一個磁碟，因此部署中沒有同位元檢查，也沒有第二份副本；每個物件的耐久性都取決於單一 VPS 磁碟。自 2025 年 10 月託管的社群文件撤下後，MinIO 的官方文件僅以原始碼形式存在於 minio/docs repository 中。該文件將獨立部署定位為早期開發與評估用途，並表示 MinIO 不建議在 production 中使用。您可以為 bucket 開啟 object locking，但在單一 VPS 上，它只能阻止透過 S3 API 刪除物件。任何擁有該機器 root 權限的人，仍可直接移除磁碟上的檔案，因此不要對這個架構承諾不可變的保留政策。

它適合作為另一個 region 中第二台 VPS 的 restic 目標，也適合作為開發工作與 CI artifact 的 S3 endpoint；在這些情境中，遺失 bucket 的代價只是重新建置，沒有其他影響。對小型應用程式的使用者上傳而言，這個架構也可以接受，前提是您負責復原計畫，並且確實測試過還原流程。

當合約或監管機構要求 object lock 或 multi-region durability，或您不想在 03:00 因磁碟已滿而收到告警時，請選擇 managed S3。程式碼停止維護也是一個必須正視的原因。截至 2026 年 10 月 20 日，community edition 已封存且不再維護；其最後一個 release 為 RELEASE.2025-10-15T17-29-55Z，本指南編譯的就是這個版本。之後不會再有任何修正，因此使用它就代表接受這項限制；另一個選擇是改用 MinIO 的 commercial AIStor 產品線，或其他 self-hosted store。self-hosted MinIO 替代方案比較了這些選項。

有一項界線值得特別說明，因為這個問題經常出現。Object storage 不是 database。在標準 bucket 中，每次寫入都會取代整個物件；即使 Amazon 為 S3 Express One Zone 新增的 append 呼叫，也只會將資料附加到末端。因此，把正在使用的 SQL 檔案放在 S3 bucket 上既慢又不安全。請將 database 保存在 local disk，再備份到 bucket：在 VPS 上於 production 執行 SQLite說明了這種分工。

失效情況與您會看到的訊息

執行 systemctl enable --now 後 unit 立即失敗。 讀取 journalctl -u minio -n 30 --no-pager。Failed to load environment files: No such file or directory 表示 unit 中缺少 /etc/default/minio，或其路徑拼寫錯誤。若訊息以 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。變更 MinIO 的連接埠前，先使用 sudo ss -ltnp | grep :9000 找出該程序。

透過代理上傳超過 1 MB 的檔案時失敗。 nginx 回應了 413 Request Entity Too Large，而 MinIO 從未收到請求。請在 server block 中設定 client_max_body_size 0。

SignatureDoesNotMatch。 可能是 secret key 錯誤，或用戶端與 MinIO 之間的某個元件改寫了 Host 標頭；該標頭包含在簽章中。

RequestTimeTooSkewed。 用戶端或伺服器的時鐘不正確。每個已簽章的 S3 請求都會攜帶時間戳記。MinIO 與 Amazon S3 一樣，會拒絕時間戳記與自身時鐘相差超過 15 分鐘的標頭簽章請求。Presigned link 則會依其到期時間檢查。檢查 timedatectl，並確認時間同步功能正在運作。

在您確定存在的 bucket 上出現 Access Denied。 該 key 的作用範圍是另一個 bucket。使用 mc admin policy info local restic-rw 輸出 policy 實際允許的內容，並比對 resource 行中的 bucket 名稱。

FAQ

單一節點的 MinIO 足以用於正式備份嗎？

如果將其作為 restic 的目標，且部署在與受保護資料不同的機器上，則已足夠。但它不足以作為唯一的備份副本。單一磁碟部署沒有任何 parity，因此 MinIO 內部沒有第二份副本；如果該 VPS 磁碟遺失資料，物件也會一併遺失。請在其他位置保留第二個目標，並至少從兩個目標各還原一次，以確認還原流程可正常運作。

為什麼 sha256sum -c 在 MinIO 的 checksum 檔案上會失敗？

只有在較早儲存的副本中，才會遇到該檔案，因為截至 20 October 2026，dl.min.io 在檢查每個 community binary 與 checksum 檔案時，對所有項目都回應 410 Gone。該檔案中 hash 後方的標籤會標示 release，例如 minio.RELEASE.2025-09-07T16-13-09Z；下載的檔案通常則稱為 minio。sha256sum -c 會尋找 checksum 檔案內指定名稱的檔案，但找不到，因此回報 No such file or directory 與 WARNING: 1 listed file could not be read。下載內容沒有問題。請直接比較 hash 字串並忽略標籤，因為標籤不具安全意義。

MinIO 的管理 Web console 到哪裡去了？

MinIO 在 May 2025 從 community edition console 移除管理功能，只在 Web 介面保留物件瀏覽器。現在請使用 mc client 管理 buckets 與 users，例如執行 mc admin user add 和 mc admin policy attach。這是 community edition 的預期操作方式，不是替代方案，因此本指南全部透過命令列完成。

如何將 restic 指向 MinIO，作為 S3 backend？

將 AWS_ACCESS_KEY_ID 與 AWS_SECRET_ACCESS_KEY 設為 MinIO access key 及其 secret，然後使用格式為 s3:https://s3.example.com/restic 的 repository 字串，其中最後一個路徑元素是 bucket 名稱。請先使用 mc mb 建立 bucket，因為限制在單一 bucket 的 key 沒有建立 bucket 的權限。restic 會在上傳前使用自己的 repository password 加密所有資料，因此 MinIO 儲存的是密文，且永遠看不到你的檔案。

必須讓 MinIO 位於 nginx 後方嗎？

只要 client 不在同一台機器上，就需要 TLS（傳輸層安全性），因為沒有 TLS 時，所有物件都會以明文在網路上傳輸，access key ID 與 request signature 也包括在內。secret key 本身不會離開 client，因為 S3 signing 只會在本機使用它計算該 signature；但網路路徑上的任何人仍可讀取你的資料，並在擷取的 request 時間戳仍有效時重播該 request。使用 certbot 取得憑證，並在 port 443 上配置 proxy，是啟用 TLS 最簡單的方式，也能讓憑證續期作業與 MinIO 分離。如果將 --certs-dir 指向包含 public.crt 與 private.key 的目錄，MinIO 也能自行終止 TLS；但此時服務帳號必須具備讀取續期後 private key 的權限，為了相同結果需額外處理。