SSD Nodes Learn 8GB RAM — $66/वर्ष
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-08-01

VPS वर MinIO सह स्वतःचे S3 ऑब्जेक्ट स्टोरेज

Ubuntu 24.04 च्या एका VPS वर MinIO उभारा: पडताळलेली binary, systemd unit, mc कमांडची मूलतत्त्वे, presigned URLs आणि restic backup targetची अचूक मांडणी.

Verified Every command ran end-to-end on a fresh Ubuntu 24.04 server, July 30, 2026.

MinIO सह स्वयं-होस्ट केलेले ऑब्जेक्ट स्टोरेज तुम्हाला काय देते

MinIO हे Amazon S3 API शी संवाद साधणारे स्वयं-होस्ट केलेले ऑब्जेक्ट स्टोरेज आहे. restic किंवा कोणत्याही S3 SDK ला तुमच्या स्वतःच्या सर्व्हरकडे निर्देशित करा, फक्त एक endpoint सेटिंग बदला, आणि क्लायंटला कोणताही फरक जाणवणार नाही. या मार्गदर्शकात Ubuntu 24.04 वर एकल नोड तयार केला आहे: पडताळलेली binary, स्वतंत्र system user, root credentials unit file मध्ये ठेवू न देणारे systemd unit, आणि restic ज्यामध्ये backup साठवते असा bucket.

S3 (simple storage service) ही filesystem ऐवजी HTTP API आहे. तुम्ही एखादा object key अंतर्गत bucket मध्ये PUT करता आणि नंतर तो GET करता. यामध्ये partial write किंवा rename नसते. Backup tools ला हे मॉडेल योग्य वाटते, कारण object पूर्णपणे पोहोचतो किंवा पोहोचत नाही.

एका नोडवर तुमच्या डेटाची एकच प्रत असते. तुम्ही हा तडजोडीचा निर्णय घेत आहात. VPS च्या किमतीत तुम्हाला नियंत्रित करता येणारा S3 endpoint मिळतो. त्यासोबत cloud provider करत असलेली प्रत्येक जबाबदारी तुमच्यावर येते. यात निकामी disk बदलणे आणि server software ला patch करणे यांचा समावेश आहे. हा निर्णय कधी योग्य आहे, हे शेवटच्या जवळच्या विभागात स्पष्टपणे सांगितले आहे.

July 2026 मधील MinIO community edition ची स्थिती

यावर आधारित काम सुरू करण्यापूर्वी हा भाग वाचा, कारण यात अलीकडे बदल झाला आहे. May 2025 मध्ये MinIO ने community edition मधील web console मधून प्रशासनाची वैशिष्ट्ये काढून टाकली. आता browser मध्ये फक्त object browser उपलब्ध आहे. त्यामुळे buckets आणि access keys आता mc command line client वापरून व्यवस्थापित कराव्या लागतात.

नंतर 2025 मध्ये MinIO ने pre-compiled community binaries प्रकाशित करणे थांबवले. प्रकल्पाच्या README नुसार community edition आता केवळ source code स्वरूपात वितरित केली जाते. जुन्या download URLs अजूनही कार्यरत आहेत. July 2026 पर्यंत त्यांमधून server build RELEASE.2025-09-07T16-13-09Z आणि client build RELEASE.2025-08-13T08-35-41Z मिळतात. त्यानंतरचे कोणतेही नवीन community build प्रकाशित झालेले नाही. त्यामुळे खालील binary वास्तविक आहे आणि चालते, परंतु ती स्थिर असून त्यात September 2025 नंतर प्रकाशित केलेले security fixes नाहीत.

या एका वस्तुस्थितीमुळे या मार्गदर्शकातील पुढील सर्व बाबी ठरतात. त्यामुळे येथे MinIO 127.0.0.1 वर listening करते आणि तुमच्या नियंत्रणातील proxy मार्फतच internet पर्यंत पोहोचते. तुम्हाला security fixes चा मागोवा घ्यायचा असल्यास source code मधून build करा. Vendor README मध्ये go install github.com/minio/minio@latest ही एकच command दिली आहे. तिला Go toolchain आवश्यक आहे आणि ती binary ~/go/bin/minio येथे लिहिते. ती binary /usr/local/bin/minio येथे install करा. त्यानंतर या मार्गदर्शकातील इतर प्रत्येक पायरी तशीच राहते.

MinIO binary स्थापित करा आणि डाउनलोडची पडताळणी करा

निश्चित केलेले release आणि त्याचा प्रकाशित checksum डाउनलोड करा. -f flag मुळे HTTP error आल्यास curl अपयशी ठरते. त्यामुळे error page तुम्ही दिलेल्या नावाखाली जतन होत नाही. अन्यथा 404 page install होऊ शकते आणि ते execute का होत नाही, असा प्रश्न पडू शकतो.

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

दोन्ही hash ची तुलना करा. फक्त hash चीच तुलना करा.

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

येथे sha256sum -c minio.sha256sum वापरू नका. त्या file मधील hash नंतर लिहिलेले label minio.RELEASE.2025-09-07T16-13-09Z आहे. आपण download minio या नावाने जतन केले आहे. त्यामुळे -c अस्तित्वात नसलेली file शोधते. ते No such file or directory दाखवते आणि त्यानंतर WARNING: 1 listed file could not be read दाखवते. त्यामुळे download खराब झाल्यासारखे दिसते, परंतु तसे नसते. Label हे केवळ नाव असते. हमी देणारा भाग म्हणजे hash.

ही तपासणी नेमके काय सिद्ध करते, हे स्पष्टपणे समजा. Binary आणि hash एकाच vendor कडून, एकाच connection द्वारे आले आहेत. त्यामुळे जुळणारे hash download पूर्ण आहे आणि transfer दरम्यान त्याचे नुकसान किंवा बदल झालेला नाही, हे सिद्ध करते. मात्र vendor विश्वसनीय आहे, हे सिद्ध होत नाही. ती वेगळी समस्या आहे आणि कोणतीही sha256sum command ती सोडवू शकत नाही.

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 वर नाही.

system user आणि data directory तयार करा

MinIO नेटवर्कवरून upload स्वीकारते, त्यामुळे ते root म्हणून चालवू नका. त्याला home directory आणि login shell नसलेले account द्या.

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 पेक्षा कमी असलेले system account तयार करते. त्यामुळे ते वापरकर्त्यांसाठी राखीव श्रेणीबाहेर राहते. -M home directory तयार करणे वगळते, कारण login न करणाऱ्या account ला home directory ठेवण्याची गरज नसते. id minio-user वापरून निकाल तपासा. stat -c '%U %a' /var/lib/minio देखील वापरा. त्यातून minio-user 750 दिसले पाहिजे.

data directory त्या user साठी writable असली पाहिजे; केवळ readable असणे पुरेसे नाही. पहिल्यांदा सुरू झाल्यावर MinIO volume मध्ये स्वतःची configuration ठेवण्यासाठी .minio.sys directory तयार करते. त्यामुळे root-owned directory असल्यास MinIO startup दरम्यान permission denied ने समाप्त होणारा संदेश दाखवून बंद होते. अशा प्रकारे चालवलेल्या प्रत्येक service साठी हाच नियम लागू होतो. VPS वरील least-privilege service users मध्ये याचे योग्य स्पष्टीकरण दिले आहे.

root क्रेडेन्शियल्स environment फाइलमध्ये ठेवा

root क्रेडेन्शियल्समुळे प्रत्येक bucket उघडता येतो. त्यामुळे ती unit file मध्ये ठेवू नका, कारण ती सर्व वापरकर्त्यांना वाचता येते. प्रथम योग्य mode सह फाइल तयार करा आणि त्यानंतरच त्यात लिहा. त्यामुळे password अगदी क्षणभरासाठीसुद्धा वाचता येणाऱ्या फाइलमध्ये राहणार नाही.

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 विद्यमान फाइल नव्याने तयार करण्याऐवजी ती truncate करते. त्यामुळे mode 600 आणि मालक root कायम राहतो. हे जाणीवपूर्वक केले आहे. systemd विशेषाधिकार User= कडे कमी करण्यापूर्वी root म्हणून EnvironmentFile वाचते. त्यामुळे service account ला स्वतःचे क्रेडेन्शियल्स वाचण्याची गरज पडत नाही. सेवा सुरू झाल्यानंतर sudo -u minio-user cat /etc/default/minio वापरून याची पडताळणी करा. त्या command ने Permission denied मुद्रित केले पाहिजे.

सेवा सुरू करण्यापूर्वी MinIO च्या दोन वर्तनांची माहिती असणे उपयुक्त आहे. त्याच्या environment मध्ये MINIO_ROOT_USER आणि MINIO_ROOT_PASSWORD नसल्यास MinIO सुरू होण्यास नकार देत नाही. ते दस्तऐवजीकृत default credentials minioadmin:minioadmin सह सुरू होते. कोणताही scanner प्रथम हीच जोडी वापरून पाहतो. असे असतानाही MinIO पूर्णपणे निरोगी असल्यासारखे दिसते. त्याऐवजी 8 characters पेक्षा लहान password नाकारला जातो. MinIO startup वेळी credentials अवैध असल्याचे error देऊन बंद होते, कारण access key मध्ये किमान 3 characters आणि secret key मध्ये किमान 8 characters आवश्यक असतात.

MINIO_VOLUMES हा data path आहे आणि MINIO_OPTS मध्ये flags असतात. 127.0.0.1 शी bind केल्यामुळे या VPS च्या बाहेरून कोणीही अद्याप S3 API पर्यंत पोहोचू शकत नाही. हा योग्य default आहे. नंतर certificate धारण करणाऱ्या 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 वर चालणारा server तुम्हाला न कळवता सुरू होतो. डॅश नसल्यास, MinIO सुरू होण्यापूर्वीच गहाळ फाइलमुळे युनिट अयशस्वी होते आणि journalctl -u minio मध्ये Failed to load environment files: No such file or directory दिसते. सुरू होण्यास नकार देणारे युनिट, डीफॉल्ट password शांतपणे स्वीकारणाऱ्या server पेक्षा, लक्षात येणे अधिक सोपे असते.

$MINIO_VOLUMES आणि $MINIO_OPTS मुद्दाम अवतरणचिन्हांशिवाय ठेवले आहेत, कारण systemd whitespace वर unquoted variables वेगवेगळ्या arguments मध्ये विभाजित करते. त्यामुळे MINIO_OPTS मधील चार शब्द minio server साठी चार arguments बनतात. LimitNOFILE=65536 file descriptor ची मर्यादा वाढवते. प्रत्येक open connection आणि प्रत्येक open data file साठी एक descriptor लागतो. Load वाढल्यावर 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 मध्ये server ज्या API address वर listening आहे तो दाखवला जातो. युनिट वारंवार restart होत राहिल्यास systemd प्रयत्न थांबवते आणि Start request repeated too quickly log करते. याचा अर्थ प्रत्येक प्रयत्नात MinIO बाहेर पडते. कारण त्या संदेशाच्या वरील ओळींमध्ये दिलेले असते, त्यामुळे log मध्ये वरच्या दिशेने वाचा.

अधिक isolation साठी [Service] विभागात ProtectSystem=full आणि ProtectHome=true जोडा. दोन्हींसाठी host kernel कडून mount namespaces आवश्यक आहेत. OpenVZ किंवा LXC सारख्या host kernel शेअर करणाऱ्या container virtualisation मध्ये ते अयशस्वी होऊ शकतात. अशा वेळी युनिट status=226/NAMESPACE दाखवते. त्या दोन ओळी काढा आणि युनिट सुरू होते. हे युनिट स्वतः एक सामान्य युनिट आहे. उर्वरित directives साठी VPS वरील systemd services आणि timers पहा.

mc स्थापित करा आणि राउंड ट्रिपची खात्री करा

MinIO client म्हणजे mc. तो apt install mc वापरून स्थापित करू नका. ते पॅकेज Midnight Commander नावाचा file manager आहे आणि त्याचा 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

Server ची 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 मुद्रित केले पाहिजे. या राउंड ट्रिपमुळे server कार्यरत असल्याची निश्चित खात्री होते, कारण यामध्ये इतर प्रत्येक client करेल त्याच signed S3 requests केल्या जातात. दुसरे मत हवे असल्यास mc admin info local server status दाखवते.

आता आणखी एक तपासणी करा, कारण box अजून रिकामा आहे.

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

ही command अयशस्वी झाली पाहिजे. ती यशस्वी झाल्यास environment file process पर्यंत पोहोचलेली नाही आणि तुमचा server default credentials वर चालू आहे. मशीनवर इतर कोणत्याही गोष्टीने प्रवेश करण्यापूर्वी ही समस्या दुरुस्त करा.

mc aliases ~/.mc/config.json मध्ये plain text स्वरूपात साठवते. त्यामुळे ही credentials command चालवणाऱ्या व्यक्तीच्या home directory मध्ये राहतात. mc ला sudo अंतर्गत चालवल्यास root credentials /root/.mc/config.json मध्ये ठेवली जातात. root alias एका administrator account कडेच ठेवा आणि प्रत्येक application साठी स्वतंत्र key द्या.

Presigned URL वापरून एक ऑब्जेक्ट उपलब्ध करून देणे

Presigned URL म्हणजे signature आणि expiry जोडलेली साधी HTTPS link असते. ही link असलेली कोणतीही व्यक्ती account किंवा client शिवाय तो एकच object fetch करू शकते.

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

Output मध्ये query string मध्ये X-Amz-Signature आणि X-Amz-Expires असतात. याबाबत दोन गोष्टी अनेकांना अनपेक्षित वाटतात. ही link तुम्ही वापरलेल्या alias मधील endpoint वरून तयार होते. त्यामुळे 127.0.0.1 वरील alias वापरल्यास अशी link तयार होते जी केवळ हेच machine open करू शकते. पाठवायच्या links साठी तुमच्या public hostname वर दुसरा alias तयार करा. तसेच revoke करण्यासाठी कोणतेही button नसते. Signature expiry होईपर्यंत valid राहते. त्यामुळे तुमच्याकडे असलेले एकमेव नियंत्रण म्हणजे short expiry ठेवणे. S3 signature format मध्ये कमाल expiry 7 days आहे.

restic साठी स्वतंत्र key आणि bucket द्या

root credentials प्रत्येक bucket वाचू आणि हटवू शकतात. त्यामुळे backup job मध्ये त्यांचा वापर करू नका. एक bucket, त्या bucketपुरती मर्यादित policy आणि इतर कोणतेही अधिकार नसलेला user तयार करा.

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 उपलब्ध आहे. तिच्यामुळे एक command कमी लागली असती, पण ती server वरील प्रत्येक bucket ला पूर्ण प्रवेश देते. वरील policy मध्ये bucket चे नाव जाणीवपूर्वक दोनदा दिले आहे: bucket ची listing कार्यरत राहण्यासाठी एकदा arn:aws:s3:::restic म्हणून आणि त्यातील objects साठी एकदा arn:aws:s3:::restic/* म्हणून. S3 मध्ये bucket आणि त्यातील objects ही स्वतंत्र resources आहेत. त्यामुळे त्यांपैकी केवळ एकाचे नाव असलेली policy client मध्ये बिघाड असल्यासारखी दिसणारी त्रुटी निर्माण करते.

या मर्यादेवर विश्वास ठेवण्यापूर्वी तिची चाचणी घ्या.

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 S3 credentials प्रमाणित AWS environment variables मधून वाचतो. त्यामुळे restic-specific credential file आवश्यक नाही.

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 password विचारतो. हा password repository encrypt करतो. त्यामुळे MinIO कडे केवळ ciphertext साठवला जातो आणि password हरवल्यास backup गमावला जातो. systemd timer ने सुरू केलेल्या run कडे input देण्यासाठी terminal नसतो. त्यामुळे scheduled backups साठी RESTIC_PASSWORD_FILE ला mode 600 असलेल्या file कडे सेट करा.

वरील कोणत्याही command पेक्षा placement चा एक नियम अधिक महत्त्वाचा आहे. संरक्षित करत असलेल्या data प्रमाणेच त्याच VPS वर restic repository ठेवल्यास खराब rm पासूनच संरक्षण मिळते; इतर कोणत्याही समस्येपासून नाही. MinIO node वेगळ्या machine वर असावा आणि शक्य असल्यास वेगळ्या region मध्ये असावा. VPS वरील restic backups यावर आधारित scheduling आणि retention समाविष्ट करते.

nginx सह TLS समाप्त करा

MinIO localhost वर चालत असल्यामुळे nginx हा सार्वजनिक प्रवेशबिंदू आहे. certbot आणि nginx सह Let's Encrypt प्रमाणपत्रे मध्ये सांगितल्याप्रमाणे प्रथम प्रमाणपत्र जारी करा. त्यानंतर हा 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 हे default 1 MB body limit काढून टाकते. अन्यथा MinIO ला विनंती मिळण्यापूर्वीच 413 Request Entity Too Large मुळे त्यापेक्षा मोठे upload नाकारले जातात. proxy_request_buffering off upload थेट पुढे पाठवते. कारण default पद्धत संपूर्ण request आधी temporary file मध्ये साठवते. त्यामुळे मोठ्या object साठी disk space दुप्पट लागते. proxy_set_header Host $http_host ही सूक्ष्म बाब आहे. S3 signature मध्ये Host header समाविष्ट असतो. त्यामुळे proxy ने तो पुन्हा लिहिल्यास प्रत्येक request SignatureDoesNotMatch सह अयशस्वी होते, जरी access log मध्ये सामान्य request आल्याचे दिसत असले तरी.

MinIO ला त्याचे public name देखील सांगा. त्यामुळे त्याने तयार केलेल्या links localhost ऐवजी proxy कडे निर्देश करतील.

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

Firewall configuration लहान ठेवा. SSH आणि HTTPS ला परवानगी द्या. ports 9000 आणि 9001 साठी कोणताही rule ठेवू नका. कारण 127.0.0.1 शी bind केलेला address firewall काहीही सांगत असला तरी दुसऱ्या machine वरून पोहोचण्यायोग्य नसतो. VPS वरील ufw firewall ची मूलतत्त्वे येथे commands दिले आहेत.

एकल-node MinIO कधी पुरेसे आहे आणि वास्तविक S3 कधी आवश्यक आहे

येथे एकल node म्हणजे parity नसलेली एक drive. MinIO च्या अधिकृत दस्तऐवजीकरणानुसार ही रचना testing आणि availability ची आवश्यकता नसलेल्या लहान workloads साठी योग्य आहे. Deployment मध्ये दुसरी प्रत नसते. त्यामुळे प्रत्येक object ची durability ही एका VPS disk च्या durability इतकीच असते. Distributed erasure-coded backend गृहीत धरणारी features, ज्यामध्ये bucket replication आणि object locking यांचा समावेश आहे, multi-drive deployments साठी असतात. त्यामुळे या setup वर कोणालाही immutable retention policy देण्याचे आश्वासन देऊ नका.

दुसऱ्या region मधील दुसऱ्या VPS वरील restic target म्हणून हे योग्य आहे. Development work आणि CI artifacts साठी S3 endpoint म्हणूनही हे योग्य आहे. अशा वेळी bucket गमावल्यास rebuild करावा लागतो, त्यापेक्षा अधिक नुकसान होत नाही. लहान application मधील user uploads साठीही हे योग्य ठरू शकते. मात्र recovery plan तुमच्याकडे असावा आणि restore ची प्रत्यक्ष चाचणी घेतलेली असावी.

Contract किंवा regulator object lock किंवा multi-region durability मागत असल्यास managed S3 निवडा. Disk भरल्यामुळे 03:00 वाजता तुम्हालाच page होऊ नये असे वाटत असल्यासही managed S3 निवडा. Frozen build हे दुसरे स्पष्ट कारण आहे. July 2026 पर्यंत pre-compiled community binary September 2025 मधील आहे आणि त्याला कोणतेही fixes मिळत नाहीत. त्यामुळे ते चालवणे म्हणजे ही मर्यादा स्वीकारणे. दुसरा पर्याय म्हणजे source मधून build करणे आणि project मधील बदल स्वतः नियमितपणे लागू ठेवणे.

एक महत्त्वाची मर्यादा स्पष्ट करणे आवश्यक आहे, कारण हा प्रश्न वारंवार उपस्थित होतो. Object storage हा database नाही. प्रत्येक write संपूर्ण object बदलतो. त्यामुळे S3 bucket वरील live SQL file धीमी आणि असुरक्षित असते. Database local disk वर ठेवा आणि त्याचा backup bucket मध्ये घ्या: VPS वर production मध्ये SQLite चालवणे या विभागात ही विभागणी स्पष्ट केली आहे.

अपयशाच्या स्थिती आणि दिसणारे संदेश

systemctl enable --now नंतर युनिट लगेच अपयशी ठरते. journalctl -u minio -n 30 --no-pager वाचा. Failed to load environment files: No such file or directory म्हणजे युनिटमध्ये /etc/default/minio गहाळ आहे किंवा त्याचा path चुकीचा लिहिला आहे. permission denied ने समाप्त होणाऱ्या संदेशाचा अर्थ data directory service account कडून लिहिण्यायोग्य नाही. त्यामुळे stat -c '%U' /var/lib/minio/data चालवून minio-user प्रदर्शित होते का ते तपासा.

minioadmin:minioadmin अद्याप login करते. environment file प्रक्रियेपर्यंत पोहोचलेली नाही. युनिटमध्ये EnvironmentFile=/etc/default/minio आहे याची खात्री करा, sudo systemctl daemon-reload चालवा आणि service पुन्हा सुरू करा. MinIO सुरुवातीला root credentials एकदाच वाचते. त्यामुळे restart न करता ती file संपादित केल्यास कोणताही बदल होत नाही.

सुरुवातीला Address already in use. दुसरी process port 9000 वापरत आहे. MinIO ची port बदलण्यापूर्वी sudo ss -ltnp | grep :9000 वापरून ती process शोधा.

proxy मार्फत 1 MB पेक्षा मोठे uploads अपयशी ठरतात. nginx ने 413 Request Entity Too Large ला उत्तर दिले आणि MinIO पर्यंत request पोहोचलीच नाही. server block मध्ये client_max_body_size 0 सेट करा.

SignatureDoesNotMatch. secret key चुकीची आहे किंवा client आणि MinIO यांच्यामधील एखाद्या घटकाने Host header बदलला आहे. Signature मध्ये या headerचा समावेश असतो.

RequestTimeTooSkewed. client किंवा server वरील clock चुकीचे आहे. प्रत्येक S3 request मध्ये timestamp असतो आणि 15 minute window च्या बाहेरची request नाकारली जाते. timedatectl तपासा आणि time synchronisation सक्रिय असल्याची खात्री करा.

अस्तित्वात असल्याची खात्री असलेल्या bucket वर Access Denied. key वेगळ्या bucket साठी मर्यादित आहे. Policy प्रत्यक्षात कोणत्या परवानग्या देते ते mc admin policy info local restic-rw वापरून प्रदर्शित करा आणि resource lines मधील bucket name शी तुलना करा.

FAQ

वास्तविक बॅकअपसाठी single-node MinIO पुरेसे आहे का?

संरक्षित करत असलेल्या डेटापेक्षा वेगळ्या मशीनवर चालणारे restic target म्हणून ते पुरेसे आहे. मात्र, तुमची एकमेव प्रत म्हणून ते पुरेसे नाही. single-drive deployment मध्ये parity शून्य असते. त्यामुळे MinIO मध्ये दुसरी अंतर्गत प्रत नसते. त्या VPS disk मधील डेटा गमावल्यास objects नष्ट होतात. दुसरे target दुसऱ्या ठिकाणी ठेवा. प्रक्रिया कार्यरत असल्याची खात्री करण्यासाठी किमान एकदा दोन्ही ठिकाणांहून restore करा.

MinIO च्या checksum file वर sha256sum -c का अयशस्वी होते?

कारण त्या file मधील hash नंतरचे label release चे नाव, minio.RELEASE.2025-09-07T16-13-09Z, दर्शवते. मात्र, डाउनलोड केलेल्या file चे सामान्य नाव minio असते. sha256sum -c checksum file मध्ये लिहिलेले नाव असलेली file शोधते. ती सापडत नाही. त्यामुळे No such file or directory आणि WARNING: 1 listed file could not be read असा संदेश दिसतो. Download योग्य आहे. Hash strings थेट तपासा आणि label कडे दुर्लक्ष करा. त्याला कोणताही security अर्थ नसतो.

MinIO चे admin web console कुठे गेले?

May 2025 मध्ये MinIO ने community edition console मधून administration features काढून टाकली. Web interface मध्ये आता object browser उपलब्ध आहे. Buckets आणि users आता mc client वापरून व्यवस्थापित केले जातात. यासाठी mc admin user add आणि mc admin policy attach सारख्या commands वापरल्या जातात. Workaround ऐवजी community edition मध्ये हीच समर्थित पद्धत आहे. म्हणून या मार्गदर्शकात सर्व काम command line वरून केले आहे.

MinIO ला S3 backend म्हणून restic शी कसे जोडायचे?

AWS_ACCESS_KEY_ID आणि AWS_SECRET_ACCESS_KEY मध्ये MinIO access key आणि त्याचा secret सेट करा. त्यानंतर s3:https://s3.example.com/restic या स्वरूपातील repository string वापरा. यातील शेवटचा path element bucket चे नाव असते. प्रथम mc mb वापरून bucket तयार करा. कारण एका bucket पुरती मर्यादित केलेल्या key ला buckets तयार करण्याची permission नसते. Upload करण्यापूर्वी restic स्वतःच्या repository password ने सर्व डेटा encrypt करते. त्यामुळे MinIO मध्ये ciphertext साठवला जातो आणि तुमच्या files त्याला कधीही दिसत नाहीत.

MinIO nginx च्या मागे चालवणे आवश्यक आहे का?

Client त्याच machine वर नसल्यास TLS (transport layer security) आवश्यक आहे. कारण S3 credentials आणि object data दोन्ही request मधून प्रवास करतात. port 443 वर certbot कडून मिळालेल्या certificate सह proxy वापरणे हा यासाठी सर्वात सोपा मार्ग आहे. त्यामुळे certificate renewal ची जबाबदारी MinIO पासून वेगळी राहते. --certs-dir ला public.crt आणि private.key असलेली directory दाखवल्यास MinIO स्वतःही TLS terminate करू शकते. मात्र, त्यानंतर service account ला renewed private key वाचण्याची access द्यावी लागते. त्याच परिणामासाठी हे अतिरिक्त काम आहे.

#minio#s3#object-storage#self-hosted#vps