MinIO על VPS: אחסון אובייקטים עצמאי עם S3

מה נותן לכם אחסון אובייקטים עצמאי עם MinIO

MinIO הוא אחסון אובייקטים עצמאי שתומך ב-API של Amazon S3. הגדירו את restic או כל SDK של S3 כך שיפנה לשרת שלכם, שנו הגדרת endpoint אחת, והלקוח לא יוכל להבחין בהבדל. במדריך זה נבנה צומת יחיד ב-Ubuntu 24.04: בינארי שאומת, משתמש מערכת ייעודי, יחידת systemd ששומרת את פרטי הכניסה של root מחוץ לקובץ היחידה, ו-bucket שאליו restic מגבה.

‏S3 ‏(simple storage service) הוא API מבוסס HTTP ולא מערכת קבצים. מציבים אובייקט ב-bucket תחת מפתח, ומקבלים אותו בחזרה. אין כתיבה חלקית ואין שינוי שם. כלי גיבוי מעדיפים את המודל הזה, משום שאובייקט הגיע בשלמותו או שלא הגיע כלל.

צומת יחיד מחזיק עותק יחיד של הנתונים שלכם. זו הפשרה שאתם בוחרים בה. אתם מקבלים endpoint של S3 בשליטתכם תמורת עלות של VPS, ובמקביל מקבלים על עצמכם את כל המשימות שספק הענן ביצע עבורכם, מהחלפת דיסק שנכשל ועד עדכון תוכנת השרת. הסעיף לקראת סוף המדריך מציין במפורש מתי הפשרה הזו מתאימה.

מצבה של מהדורת הקהילה של MinIO ביולי 2026

קראו את החלק הזה לפני שאתם מתבססים עליו, משום שהוא השתנה לאחרונה. במאי 2025 הסירה MinIO את תכונות הניהול ממסוף האינטרנט במהדורת הקהילה. בדפדפן נותר דפדפן אובייקטים, ולכן מנהלים את ה-buckets ואת מפתחות הגישה באמצעות לקוח שורת הפקודה mc במקום זאת.

בהמשך 2025 הפסיקה MinIO לפרסם קובצי בינארי מקומפלים מראש של מהדורת הקהילה. קובץ ה-README של הפרויקט מציין כעת שמהדורת הקהילה מופצת כקוד מקור בלבד. כתובות ההורדה הישנות עדיין פועלות: נכון ליולי 2026 הן מספקות את בניית השרת RELEASE.2025-09-07T16-13-09Z ואת בניית הלקוח RELEASE.2025-08-13T08-35-41Z, ולא הופיעה בניית קהילה חדשה יותר. לכן קובץ הבינארי שלהלן אמיתי ופועל, אך הוא קפוא. תיקוני אבטחה שפורסמו לאחר ספטמבר 2025 אינם כלולים בו.

עובדה זו מעצבת את המשך המדריך. זו הסיבה ש-MinIO מאזין כאן ב-127.0.0.1 וניגש לאינטרנט רק דרך proxy שבשליטתכם. אם אתם מעדיפים לעקוב אחר תיקונים, בצעו בנייה מקוד המקור. קובץ ה-README של היצרן מספק פקודה יחידה, go install github.com/minio/minio@latest, הדורשת toolchain של 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 מעניקים גישה לכל ה-buckets, ולכן אין להציב אותם בקובץ היחידה, הניתן לקריאה לכל המשתמשים. תחילה יוצרים את הקובץ עם ההרשאות המתאימות, ורק לאחר מכן כותבים אליו, כדי שהסיסמה לא תימצא אפילו לרגע בקובץ הניתן לקריאה.

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, שהם הצמד הראשון שכל סורק מנסה, ונראה תקין לחלוטין בזמן שהוא עושה זאת. סיסמה שאורכה פחות מ-8 תווים נדחית במקום זאת: MinIO יוצא במהלך האתחול ומציג שגיאה שלפיה פרטי האימות אינם חוקיים, משום שמפתח הגישה חייב להכיל לפחות 3 תווים, ומפתח הסוד לפחות 8 תווים.

MINIO_VOLUMES הוא נתיב הנתונים, ו-MINIO_OPTS מכיל את הדגלים. קישור ל-127.0.0.1 משמעותו ששום גורם מחוץ ל-VPS הזה אינו יכול עדיין לגשת ל-S3 API, וזו ברירת המחדל המתאימה. בהמשך פותחים את הגישה אליו במכוון, דרך proxy שמחזיק certificate.

כתיבת יחידת 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, ונקודת הקצה של תקינות השירות אמורה להשיב את 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 בחשבון מנהל מערכת אחד, והקצו לכל יישום מפתח משלו.

מסירת אובייקט אחד באמצעות כתובת URL חתומה מראש

כתובת URL חתומה מראש היא קישור HTTPS רגיל שמצורפים אליו חתימה ותאריך תפוגה. כל מי שמחזיק בקישור יכול לקבל את אותו אובייקט בלי חשבון ובלי לקוח.

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

הפלט כולל את X-Amz-Signature ואת X-Amz-Expires במחרוזת השאילתה. יש בו שני היבטים שמפתיעים משתמשים. הקישור נבנה מנקודת הקצה שבכינוי שבו השתמשתם, לכן כינוי ב-127.0.0.1 יוצר קישור שרק מכונה זו יכולה לפתוח. צרו כינוי נוסף בשם המארח הציבורי שלכם עבור קישורים שאתם מתכוונים לשלוח. בנוסף, אין לחצן לביטול. החתימה נשארת בתוקף עד לתפוגתה, לכן זמן תפוגה קצר הוא אמצעי הבקרה היחיד שברשותכם. שבעה ימים הם פרק הזמן המרבי שמאפשר פורמט החתימה של S3.

תנו ל-restic מפתח ודלי משלו

לפרטי ההתחברות של root יש הרשאות לקרוא ולמחוק כל דלי, ולכן משימת גיבוי אינה צריכה להחזיק בהם. צרו דלי, מדיניות המוגבלת לדלי הזה, ומשתמש שאין לו הרשאות נוספות.

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 מובנית, שהייתה חוסכת פקודה אחת, אך היא מעניקה גישה מלאה לכל הדליים בשרת. המדיניות שלמעלה מציינת את הדלי פעמיים בכוונה: פעם אחת כ-arn:aws:s3:::restic, כדי שאפשר יהיה להציג את הדלי, ופעם נוספת כ-arn:aws:s3:::restic/*, עבור האובייקטים שבתוכו. ב-S3 דלי והאובייקטים שבו הם משאבים נפרדים, ולכן מדיניות המציינת רק אחד מהם נכשלת באופן שנראה כמו תקלה בלקוח.

בדקו את ההגבלה לפני שאתם מסתמכים עליה.

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 כך שיפנה אל הדלי. 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, ולכן 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 אינה נגישה ממחשב אחר, ללא קשר להגדרות חומת האש. ב־יסודות ufw בחשבון VPS מופיעות הפקודות.

מתי MinIO בצומת יחיד מספיק, ומתי כדאי לבחור ב-S3 מנוהל

צומת יחיד כאן פירושו כונן אחד ללא parity. התיעוד של MinIO עצמו מתאר תצורה זו כמתאימה לבדיקה ולעומסי עבודה קטנים ללא דרישת זמינות. אין עותק נוסף בתוך הפריסה, ולכן העמידות של כל אובייקט זהה לעמידות של דיסק VPS יחיד. תכונות שמניחות backend מבוזר ומקודד בשיטת erasure coding, ובהן שכפול buckets ונעילת אובייקטים, שייכות לפריסות עם כמה כוננים. לכן אין להבטיח בתצורה זו מדיניות שמירת נתונים בלתי ניתנת לשינוי.

זו בחירה מתאימה כיעד restic ב-VPS שני באזור אחר, וכנקודת קצה של S3 לעבודות פיתוח ולארטיפקטים של CI, כאשר אובדן bucket מחייב בנייה מחדש ותו לא. היא מתאימה גם להעלאות משתמשים באפליקציה קטנה, כל עוד יש בבעלותכם תוכנית שחזור ובדקתם בפועל שחזור.

בחרו ב-S3 מנוהל כאשר חוזה או רגולטור דורשים נעילת אובייקטים או עמידות במספר אזורים, או כאשר אינכם רוצים להיות האדם שמקבל התראה בשעה 03:00 משום שדיסק התמלא. גם build קפוא הוא סיבה עניינית. נכון ל-July 2026, הקובץ הבינארי הקהילתי שהוכן מראש מתוארך ל-September 2025 ואינו מקבל תיקונים, ולכן הפעלתו פירושה הסכמה למצב זה, או בנייה מקוד המקור ומעקב עצמאי אחר הפרויקט.

חשוב לציין גבול אחד, משום שהוא עולה לעיתים קרובות. אחסון אובייקטים אינו מסד נתונים. כל כתיבה מחליפה אובייקט שלם, ולכן קובץ SQL פעיל ב-bucket של S3 איטי ואינו בטוח. השאירו את מסד הנתונים בדיסק המקומי וגבו אותו אל ה-bucket במקום זאת: הפעלת SQLite בסביבת ייצור ב-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 קורא את פרטי הכניסה של root פעם אחת בעת האתחול. לכן עריכת הקובץ ללא הפעלה מחדש אינה משנה דבר.

Address already in use בעת האתחול. תהליך אחר מחזיק ביציאה 9000. מצאו אותו באמצעות sudo ss -ltnp | grep :9000 לפני שתשנו את היציאה של MinIO.

העלאות בגודל של יותר מ-1 MB נכשלות דרך ה-proxy. 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, כאשר הוא פועל במחשב נפרד מהמחשב שהנתונים עליו מוגנים. הוא אינו מספיק כעותק היחיד. בפריסה עם כונן יחיד אין כלל parity, ולכן אין עותק נוסף בתוך 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 באינטרנט?

MinIO הסירה את תכונות הניהול ממסוף המהדורה הקהילתית במאי 2025, והשאירו בממשק האינטרנט דפדפן אובייקטים. כעת מנהלים buckets ומשתמשים באמצעות הלקוח mc, בעזרת פקודות כגון mc admin user add ו-mc admin policy attach. זו הדרך הנתמכת במהדורה הקהילתית ולא פתרון עוקף. לכן מדריך זה מבצע הכול משורת הפקודה.

כיצד מפנים את restic אל MinIO כקצה עורפי של S3?

הגדירו את AWS_ACCESS_KEY_ID ואת AWS_SECRET_ACCESS_KEY למפתח גישה של MinIO ולסוד המתאים לו. לאחר מכן השתמשו במחרוזת מאגר בתבנית s3:https://s3.example.com/restic, כאשר רכיב הנתיב האחרון הוא שם ה-bucket. צרו תחילה את ה-bucket באמצעות mc mb, מכיוון שלמפתח המוגבל ל-bucket יחיד אין הרשאה ליצור buckets. restic מצפינה הכול באמצעות סיסמת המאגר שלה לפני ההעלאה. לכן MinIO מאחסנת טקסט מוצפן ואינה נחשפת לקבצים שלכם.

האם חובה להפעיל את MinIO מאחורי nginx?

נדרש TLS (אבטחת שכבת התעבורה) בכל פעם שהלקוח אינו נמצא באותו מחשב, מכיוון שאישורי S3 ונתוני האובייקטים עוברים בתוך הבקשה. Proxy בפורט 443 עם אישור מ- certbot הוא הדרך הפשוטה ביותר להשיג זאת, והוא משאיר את חידוש האישור מחוץ ל-MinIO. MinIO יכולה גם לסיים את TLS בעצמה אם תפנו את --certs-dir אל תיקייה המכילה את public.crt ואת private.key. במקרה כזה, לחשבון השירות נדרשת הרשאת קריאה למפתח הפרטי שחודש. זו עבודה נוספת עבור אותה תוצאה.