התקנת MinIO על Ubuntu 24.04: מדריך אחסון S3 עצמי

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

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

S3 (שירות אחסון פשוט) הוא HTTP API ולא מערכת קבצים. אתם מבצעים PUT לאובייקט בתוך bucket תחת מפתח מסוים ומבצעים GET כדי לקבל אותו בחזרה; אין כתיבה חלקית ואין שינוי שם. כלי גיבוי מעדיפים מודל זה, כיוון שאובייקט או שהגיע בשלמותו או שלא הגיע כלל.

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

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

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

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

עובדה זו מעצבת את המשך המדריך. זו הסיבה ש-MinIO כאן מאזין ב-127.0.0.1 ומגיע לאינטרנט רק דרך proxy שבשליטתכם. אם אתם מעדיפים לעקוב אחר תיקונים, בצעו הידור (build) מקוד המקור. ה-README של הספק מספק פקודה אחת, go install github.com/minio/minio@latest, הדורשת שרשרת כלים של Go וכותבת את הקובץ הבינארי ל-~/go/bin/minio. התקינו את הקובץ הבינארי הזה ל-/usr/local/bin/minio וכל שאר השלבים כאן יישארו ללא שינוי.

התקנת הקובץ הבינארי של MinIO ואימות ההורדה

הורידו את הגרסה המיועדת ואת ה-checksum שפורסם עבורה. הדגל -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

השוו בין שני ה-hashes, והשוו אך ורק את ה-hashes.

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

אל תשתמשו ב-sha256sum -c minio.sha256sum כאן. התווית הכתובה אחרי ה-hash בתוך הקובץ היא minio.RELEASE.2025-09-07T16-13-09Z, ואנחנו שמרנו את ההורדה בשם minio, לכן -c יחפש קובץ שאינו קיים. הוא ידווח על No such file or directory ולאחר מכן על WARNING: 1 listed file could not be read, מה שנראה כמו הורדה פגומה אך אינו כזה. התווית היא רק שם. ה-hash הוא החלק שמספק את הערבות.

היו ברורים לגבי מה בדיקה זו מוכיחה. הקובץ הבינארי וה-hash מגיעים מאותו ספק דרך אותו חיבור, לכן התאמה מוכיחה שההורדה הושלמה ולא ניזוקה או שונתה במעבר. היא אינה מוכיחה שהספק מהימן. זו בעיה אחרת, ושום פקודת 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 ואחריו כמה שורות build. שגיאת Permission denied כאן מציינת שההרשאות (mode) שגויות, ו-command not found מציינת ש-/usr/local/bin אינו נמצא ב-PATH שלכם.

יצירת משתמש מערכת וספריית נתונים

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 בתוך הנפח (volume) כדי לאחסן את התצורה שלו; לכן, ספרייה בבעלות root תגרום ל-MinIO להיסגר בזמן העלייה עם הודעה שמסתיימת ב-permission denied. אותו כלל חל על כל שירות שאתם מריצים בדרך זו, והמאמר משתמשי שירות בעלי הרשאות מינימליות ב-VPS מפרט זאת כראוי.

אחסון פרטי הגישה של root בקובץ סביבה

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

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

כתיבת ה-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. ללא המקף, קובץ חסר יגרום לכשל ביחידה עוד לפני ש-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 מעלה את מגבלת ה-file descriptor, כיוון שכל חיבור פתוח וכל קובץ נתונים פתוח צורכים descriptor אחד, ומגבלת ברירת המחדל של 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 אמורה להשיב 200. הפקודה journalctl -u minio -n 20 --no-pager מציגה את כתובת ה-API שעליה השרת מאזין. אם היחידה ממשיכה לבצע restart, ה-systemd יוותר וירשום בלוג Start request repeated too quickly, מה שאומר ש-MinIO יוצא בכל ניסיון: הסיבה מודפסת בשורות שמעל להודעה זו, לכן יש לקרוא כלפי מעלה.

לצורך בידוד רב יותר, הוסיפו את ProtectSystem=full ו-ProtectHome=true למקטע [Service]. שניהם דורשים mount namespaces מליבת המארח. בווירטואליזציה של מכולות המשתפת את ליבת המארח, כגון OpenVZ או LXC, הם עלולים להיכשל, ואז היחידה תדווח על status=226/NAMESPACE. הסירו את שתי השורות הללו והיא תעלה. היחידה עצמה היא יחידה רגילה, והמאמר שירותים וטיימרים של systemd ב-VPS מכסה את יתר ההנחיות.

התקנת mc וביצוע בדיקת תקינות (round trip)

הלקוח של 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

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

הפצת אובייקט בודד באמצעות presigned URL

כתובת presigned URL היא קישור HTTPS רגיל הכולל חתימה ותוקף. כל מי שמחזיק בקישור יכול למשוך את האובייקט הספציפי ללא צורך בחשבון או בלקוח ייעודי.

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

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

הקצאת מפתח ו-bucket ייעודיים עבור restic

הרשאות ה-root מאפשרות קריאה ומחיקה של כל ה-buckets, לכן משימת גיבוי אינה צריכה להחזיק בהן. צרו bucket, מדיניות (policy) המוגבלת ל-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 שהייתה חוסכת פקודה אחת, אך היא מעניקה גישה מלאה לכל ה-buckets בשרת. המדיניות לעיל מציינת את ה-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. מדיניות שלא נבדקה היא בגדר ניחוש בלבד.

כעת הגדירו את ה-bucket עבור 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 תבקש סיסמה עבור ה-repository. סיסמה זו מצפינה את ה-repository, כך ש-MinIO מאחסנת רק טקסט מוצפן, ואובדן הסיסמה משמעו אובדן הגיבוי. הרצה שמתבצעת על ידי טיימר של systemd אינה כוללת מסוף להקלדת סיסמה, לכן הגדירו את RESTIC_PASSWORD_FILE לקובץ עם הרשאות 600 עבור גיבויים מתוזמנים.

כלל מיקום אחד חשוב יותר מכל פקודה לעיל. repository של restic שנמצא על אותו VPS שבו נמצא המידע המגובה מגן עליכם רק מפני rm שגוי, ולא משום דבר אחר. צומת ה-MinIO צריך להיות מכונה נפרדת, רצוי באזור גיאוגרפי אחר. גיבויי restic על גבי VPS מכסה תזמון ושמירת גרסאות מעבר לכך.

סיום TLS עם nginx

MinIO מאזין ב-localhost, לכן nginx מהווה את הממשק הציבורי. הנפיקו תחילה את התעודה, כמתואר ב-הנפקת תעודות Let's Encrypt עם certbot ו-nginx, ולאחר מכן השתמשו בבלוק ה-server הבא.

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 על גודל ה-body, שאלמלא כן תגרום לדחיית כל העלאה גדולה יותר עם 413 Request Entity Too Large עוד לפני שהבקשה מגיעה ל-MinIO. proxy_request_buffering off מעביר את ההעלאה בזרם ישיר (stream), שכן ברירת המחדל שומרת את כל הבקשה לקובץ זמני תחילה, מה שדורש שטח דיסק כפול עבור אובייקטים גדולים. proxy_set_header Host $http_host היא ההגדרה העדינה: חתימת S3 מכסה את ה-header מסוג Host, לכן proxy שמשכתב אותו יגרום לכל בקשה להיכשל עם SignatureDoesNotMatch, בעוד לוג הגישה יציג בקשה תקינה שהתקבלה.

הגדירו ל-MinIO את השם הציבורי שלו, כדי שהקישורים שהוא מייצר יצביעו על ה-proxy ולא על 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. ב-יסודות ה-firewall מסוג ufw ב-VPS תמצאו את הפקודות הרלוונטיות.

מתי MinIO בצומת יחיד מספיק, ומתי דרוש S3 אמיתי

צומת יחיד (single-node) במקרה זה משמעו כונן אחד ללא יתירות (parity). התיעוד של MinIO מגדיר תצורה זו כמתאימה לבדיקות ולעומסי עבודה קטנים שאינם דורשים זמינות גבוהה. אין עותק נוסף בתוך הפריסה, לכן השרידות של כל אובייקט תלויה בשרידות של דיסק VPS בודד. תכונות המניחות קיום של backend מבוזר עם erasure coding, כגון שכפול דליים (bucket replication) ונעילת אובייקטים (object locking), שייכות לפריסות מרובות כוננים; לכן, אל תבטיחו לאף אחד מדיניות שמירה בלתי-ניתנת לשינוי (immutable retention) בתצורה זו.

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

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

ראוי לציין גבול אחד כיוון שהוא עולה לעיתים קרובות. אחסון אובייקטים אינו מסד נתונים. כל כתיבה מחליפה אובייקט שלם, ולכן קובץ SQL פעיל על דלי S3 הוא איטי ולא בטוח. שמרו את מסד הנתונים על דיסק מקומי ובצעו גיבוי שלו לתוך הדלי במקום זאת: הרצת 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 חסר או שהנתיב אליו שגוי בקובץ ה-unit. הודעה שמסתיימת ב-permission denied מעידה על כך שחשבון השירות אינו בעל הרשאות כתיבה לספריית הנתונים; ודאו ש-stat -c '%U' /var/lib/minio/data מציג minio-user.

minioadmin:minioadmin עדיין מצליח להתחבר. קובץ משתני הסביבה לא הגיע לתהליך. ודאו שה-unit מכיל את EnvironmentFile=/etc/default/minio, הריצו את sudo systemctl daemon-reload, ולאחר מכן בצעו restart לשירות. MinIO קורא את פרטי הגישה (root credentials) פעם אחת בלבד בעת העלייה, לכן עריכת הקובץ ללא restart לא תשפיע.

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 בתוך ה-server block.

SignatureDoesNotMatch. או שפרטי הגישה (secret key) שגויים, או שרכיב כלשהו בין הלקוח לבין MinIO שינה את ה-header מסוג Host, אשר נכלל בחתימת הבקשה.

RequestTimeTooSkewed. השעון בשרת או בלקוח אינו מכוון. כל בקשת S3 נושאת חותמת זמן ונדחית אם היא חורגת מחלון של 15 דקות. בדקו את timedatectl וודאו שסנכרון הזמן פעיל.

Access Denied על bucket שקיים בוודאות. ה-key מוגבל ל-bucket אחר. הציגו את ההרשאות שהמדיניות מאפשרת בפועל באמצעות mc admin policy info local restic-rw והשוו את שם ה-bucket בשורות ה-resource.

FAQ

האם MinIO בצומת בודד מספיק טוב לגיבויים אמיתיים?

הוא מספיק טוב כיעד עבור restic כאשר הוא רץ על מכונה נפרדת מהנתונים אותם הוא מגבה. הוא אינו מספיק טוב כעותק יחיד. פריסה על כונן בודד אינה כוללת parity, לכן אין עותק שני בתוך MinIO, ואם הדיסק של ה-VPS יאבד נתונים, האובייקטים יאבדו. שמרו יעד שני במקום אחר, ובצעו שחזור משניהם לפחות פעם אחת כדי לוודא שהתהליך עובד.

מדוע sha256sum -c נכשל בקובץ ה-checksum של MinIO?

מכיוון שהתווית המופיעה אחרי ה-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?

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

כיצד מגדירים את restic לעבוד מול MinIO כ-S3 backend?

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

האם אני חייב להריץ את MinIO מאחורי nginx?

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