mahan
ساخت S3 Object Storage شخصی با MinIO در ۲۰۲۶؛ نصب AIStor Free، Bucket و Access Key روی VPS
Object Storage فقط مخصوص AWS نیست. می‌توانید روی سرور خودتان یک Endpoint سازگار با S3 داشته باشید و اپلیکیشن، Backup Server، CDN، سیستم آرشیو یا نرم‌افزارهای مختلف را به آن متصل کنید.
اما MinIO در سال ۲۰۲۶ تغییر مهمی کرده است. بسیاری از آموزش‌های قدیمی هنوز دستور دانلود Community Binary یا اجرای تصویر قدیمی minio/minio را پیشنهاد میکنند؛ در حالی که مخزن Community قدیمی دیگر Maintained نیست. در این آموزش مسیر فعلی را دنبال می‌کنیم و MinIO AIStor Free را به‌عنوان S3 Object Storage تکسروری راه‌اندازی می‌کنیم.
⚠️ قبل از نصب: AIStor Free رایگان است، اما همان MinIO Community قدیمی با AGPL نیست. Free License محدودیت‌هایی دارد؛ از جمله عدم پشتیبانی از Distributed Multi-node، Site/Bucket Replication و Encryption at Rest. برای Lab، Backup سبک و Object Storage تکسروری مناسب است؛ برای معماری HA باید محدودیت License را بررسی کنید.
S3 Object Storage چیست؟
در Object Storage فایل با Path فایل‌سیستم سنتی مدیریت نمی‌شود؛ هر داده یک Object داخل Bucket است و از طریق API فراخوانی میشود.
S3 Endpoint
|
+--- bucket: backups
| +--- db.sql.zst
| +--- server.tar.zst
|
+--- bucket: media
+--- image.webp
+--- video.mp4
S3 چه کاربردهایی دارد؟
🔹 Backup Repository
🔹 ذخیره تصاویر و ویدئو
🔹 Backend فایل برای اپلیکیشن
🔹 Storage برای Podcast و Media
🔹 Origin برای CDN
🔹 Data Lake کوچک
مطلب مرتبط: S3 را پشت CDN قرار دهید
اگر Object Storage را برای تصاویر یا فایلهای استاتیک می‌سازید، مقاله ساخت CDN شخصی و Image CDN با Nginx مسیر بعدی مناسبی است؛ S3 میتواند Origin فایل باشد و Edgeها محتوای پرتکرار را Cache کنند.
پیش‌نیازها
🔹 Ubuntu 24.04 LTS
🔹 Kernel 6.8 یا جدیدتر
🔹 یک Disk یا Volume مستقل برای Objectها
🔹 دامنه مانند s3.example.com
🔹 AIStor Free License
Object Storage برای فایل حجیم، Backup و Media
اگر حجم داده بالا است، علاوه بر CPU و RAM به ظرفیت Disk، IOPS و Traffic توجه کنید. برای Storage سنگین یا چند ترابایت داده، سرور اختصاصی میتواند نسبت به VPS کوچک منطقی‌تر باشد.
📌 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
مرحله اول: نصب AIStor Server
برای سرور AMD64:
curl --progress-bar -L \ https://dl.min.io/aistor/minio/release/linux-amd64/minio.deb \ -o minio.deb sudo dpkg -i minio.deb minio --version
Package یک User و Service مربوط به MinIO ایجاد میکند.
مرحله دوم: دریافت Free License
برای AIStor Free باید Free License را از MinIO/SUBNET دریافت کنید. فایل License را روی Server قرار دهید:
sudo mkdir -p /opt/minio sudo touch /opt/minio/minio.license sudo chown -R minio-user:minio-user /opt/minio
محتوای License دریافتی را در فایل minio.license قرار دهید.
مرحله سوم: آماده‌سازی Storage
sudo mkdir -p \ /mnt/drive-1/minio sudo chown -R minio-user:minio-user /mnt/drive-1
برای Production واقعی بهتر است این مسیر روی Volume یا Disk مخصوص داده قرار داشته باشد، نه صرفاً Root Partition کوچک VPS.
مرحله چهارم: تنظیم /etc/default/minio
sudo nano /etc/default/minio
مقادیر اصلی:
MINIO_LICENSE="/opt/minio/minio.license" MINIO_VOLUMES="/mnt/drive-1/minio" MINIO_ROOT_USER="CHANGE_TO_RANDOM_ACCESS_KEY" MINIO_ROOT_PASSWORD="CHANGE_TO_LONG_RANDOM_SECRET"
مقادیر تصادفی بسازید:
openssl rand -hex 16 openssl rand -hex 32
⚠️ هرگز minioadmin:minioadmin را روی Server واقعی نگه ندارید.
مرحله پنجم: راه‌اندازی Service
sudo systemctl enable minio.service sudo systemctl start minio sudo systemctl status minio sudo journalctl -u minio -f
مرحله ششم: نصب MinIO Client یا mc
wget \ https://dl.min.io/aistor/mc/release/linux-amd64/mc \ -O mc chmod +x ./mc sudo mv ./mc /usr/local/bin/ mc --version
مرحله هفتم: اتصال CLI
mc alias set storage \ http://127.0.0.1:9000 \ YOUR_ROOT_USER \ YOUR_ROOT_PASSWORD mc admin info storage
مرحله هشتم: ساخت اولین Bucket
mc mb storage/media
آپلود فایل:
mc cp photo.webp storage/media/
فهرست Objectها:
mc ls storage/media
Root Credential را به Application ندهید
Application نباید با Root User به S3 وصل شود. برای هر سرویس یک User یا Access Key محدود بسازید و فقط Permission همان Bucket را بدهید.
این کار Blast Radius نشت Credential را کاهش می‌دهد.
اتصال نرم‌افزارهای S3-Compatible
بیشتر SDKها به چهار مقدار نیاز دارند:
Endpoint: https://s3.example.com Access Key: APP_ACCESS_KEY Secret Key: APP_SECRET_KEY Bucket: media
S3 Object Storage جای File System نیست
Object Storage برای Objectهای بزرگ و APIمحور عالی است، اما نباید آن را دقیقاً مثل ext4 یا یک Network Share معمولی فرض کنید. Rename، Directory و Metadata رفتار S3 مخصوص خود را دارند.
محدودیت مهم AIStor Free
| قابلیت | AIStor Free |
|---|---|
| Single-node | بله |
| Multi-drive روی یک Node | بله |
| Distributed Multi-node | خیر |
| Replication | محدود به Tier پولی |
| Encryption at Rest | در Free در دسترس نیست |
آیا Community Edition قدیمی MinIO را نصب کنیم؟
برای Lab و بررسی Code می‌توانید نسخه Source قدیمی را مطالعه یا Build کنید، اما مخزن رسمی Community اکنون Archived و Read-only است. برای Server جدید Production، استفاده از Binaryهای Legacy که دیگر Update امنیتی دریافت نمی‌کنند توصیه نمی‌شود.
سؤالات متداول
S3 Object Storage چیست؟
مدلی برای نگهداری Objectها داخل Bucket و دسترسی به آن‌ها از طریق API سازگار با S3 است.
آیا MinIO Community هنوز Maintained است؟
مخزن قدیمی Community در آوریل ۲۰۲۶ Archived شده و برای نصب تازه مسیر رسمی به AIStor تغییر کرده است.
آیا AIStor Free رایگان است؟
بله، Free License برای کاربردهای تکسروری ارائه میشود، اما محدودیت Feature دارد.
آیا میتوان Backup روی S3 ذخیره کرد؟
بله، تعداد زیادی Backup Tool از S3 یا S3-Compatible Endpoint پشتیبانی میکنند.
آیا S3 برای CDN مناسب است؟
بله، Object Storage میتواند Origin فایلهای استاتیک باشد و CDN جلوی آن قرار بگیرد.
در راه‌اندازی S3، Disk یا Access Key مشکل دارید؟
Storage Permission، TLS، Firewall، Bucket Policy و Access Key از نقاط رایج خطا هستند.
📌 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
جمع‌بندی
در ۲۰۲۶ ساخت S3 شخصی با MinIO دیگر دقیقاً شبیه آموزش‌های چند سال قبل نیست. Community Repository قدیمی Archived شده و برای Deployment تازه، AIStor Free گزینه فعلی MinIO برای Single-node است.
بعد از نصب، Endpoint استاندارد S3، Bucket و Access Key دارید و می‌توانید Backup Tool، Application یا CDN را به Storage شخصی خودتان متصل کنید.
ساخت Immutable Backup Storage ضدباج‌افزار با MinIO Object Lock؛ بکاپ WORM روی VPS
اگر Ransomware یا مهاجم به Backup Server دسترسی پیدا کند، داشتن نسخه پشتیبان به‌تنهایی کافی نیست؛ چون ممکن است همان Backupها نیز حذف یا رمزگذاری شوند. یکی از راه‌های مقاوم‌تر کردن لایه Backup، استفاده از Immutable Storage است.
در این آموزش یک Bucket سازگار با S3 می‌سازیم که Objectهای Backup برای مدت مشخصی در حالت WORM یا Write Once Read Many باقی بمانند. از MinIO AIStor Object Lock استفاده می‌کنیم و تفاوت Governance، Compliance و Legal Hold را هم عملی بررسی می‌کنیم.
⚠️ مهم: Immutable Backup معادل «غیرقابل‌حذف برای همیشه» نیست. Retention Policy باید با ظرفیت Storage، سیاست نگهداری و نرم‌افزار Backup شما هماهنگ باشد. انتخاب اشتباه Compliance Mode میتواند باعث شود حتی Administrator نیز تا پایان Retention نتواند داده را پاک کند.
Immutable Backup چیست؟
Immutable Backup نسخه‌ای است که در دوره Retention مشخص، Object Version آن قابل تغییر یا حذف نیست.
هدف این است که حتی اگر Credential نرم‌افزار Backup لو رفت، مهاجم نتواند Recovery Pointهای محافظت‌شده را بلافاصله پاک کند.
Production Server
|
v
Backup Software
|
v
S3 Bucket
Versioning + Object Lock
|
v
Immutable Recovery Points
پیش‌نیاز این مقاله
فرض می‌کنیم S3 Storage مقاله قبل را ساخته‌اید و mc به آن متصل است:
mc admin info storage
مطلب مرتبط: Backup واقعی با Restic و Backrest
Immutable Storage فقط مقصد مقاوم Backup است؛ هنوز به Software نیاز دارید که Backup Job و Restore را مدیریت کند. برای لایه Backup می‌توانید آموزش Backrest و Restic برای Backup و Restore سرور را مطالعه کنید. فقط توجه داشته باشید Retention Object Lock ممکن است عملیات Prune/Delete برخی ابزارها را تا پایان دوره Lock محدود کند.
Versioning، Governance و Compliance چه فرقی دارند؟
| حالت | رفتار | مناسب برای |
|---|---|---|
| Versioning | نسخههای قبلی Object را نگه می‌دارد | Undo و History |
| Governance | کاربر عادی نمی‌تواند Lock را دور بزند؛ User دارای Permission خاص میتواند | محیط‌های مدیریتی منعطف‌تر |
| Compliance | حتی Root نمی‌تواند Object Version را قبل از پایان Retention حذف کند | WORM سخت‌گیرانه |
| Legal Hold | تا زمان برداشتن Hold، Object قفل می‌ماند | پرونده، Audit و نگهداری نامحدود |
Backup Storage بهتر است Failure Domain جدا داشته باشد
اگر Production و Immutable Backup روی همان VPS، همان Disk و همان Credential باشند، Protection واقعی محدود میشود. برای Backup مهم بهتر است مقصد روی سرور یا Storage جدا قرار داشته باشد.
📌 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
مرحله اول: ساخت Bucket با Object Lock
برای ساده‌ترین و واضح‌ترین طراحی، Bucket را از ابتدا با Lock بسازید:
mc mb --with-lock \ storage/immutable-backups
فعال شدن Object Lock، Versioning را نیز فعال میکند.
مرحله دوم: بررسی Versioning
mc version info \ storage/immutable-backups
مرحله سوم: Retention آزمایشی Governance
قبل از رفتن سراغ Compliance طولانی، ابتدا Governance کوتاه را آزمایش کنید:
mc retention set \ --default \ GOVERNANCE \ "7d" \ storage/immutable-backups
بررسی تنظیم:
mc retention info \ storage/immutable-backups
مرحله چهارم: Upload یک Backup آزمایشی
tar -czf \ server-backup.tar.gz \ /etc/nginx mc cp server-backup.tar.gz storage/immutable-backups/
این Object باید Retention پیش‌فرض Bucket را به ارث ببرد.
مرحله پنجم: دیدن Versionهای Object
mc ls --versions \ storage/immutable-backups/
چرا mc rm ساده تست کافی نیست؟
در Bucket Versioned، حذف عادی ممکن است فقط یک Delete Marker ایجاد کند و نسخه اصلی را پنهان کند. این به معنی حذف شدن نسخه Immutable نیست.
برای بررسی واقعی باید Version ID را ببینید و تلاش کنید همان Version محافظت‌شده را حذف کنید. Retention باید این عملیات را مسدود کند.
مرحله ششم: Compliance Mode برای Backup واقعی
⚠️ قبل از اجرای این دستور روی داده واقعی مطمئن شوید Retention درست است. در Compliance Mode حتی Root User نیز نمی‌تواند Object Version را قبل از پایان زمان Lock حذف کند.
نمونه Retention سی‌روزه:
mc retention set \ --default \ COMPLIANCE \ "30d" \ storage/immutable-backups
اعمال Retention هنگام Upload
برای Object مشخص نیز میتوان Retention تعیین کرد:
mc cp \ --retention-mode COMPLIANCE \ --retention-duration 30d \ database.sql.zst \ storage/immutable-backups/
Legal Hold چه زمانی به درد می‌خورد؟
Retention مدت مشخص دارد؛ Legal Hold تاریخ پایان خودکار ندارد و تا زمانی که User دارای Permission آن را بردارد باقی می‌ماند.
mc legalhold set \ storage/immutable-backups/important.tar.zst
ساعت سرور اهمیت امنیتی دارد
Retention به زمان وابسته است. اگر ساعت Server اشتباه باشد، محاسبه Retain Until میتواند مشکل پیدا کند. NTP و Time Synchronization را جدی بگیرید.
timedatectl status sudo timedatectl set-ntp true
Retention چند روز باشد؟
یک عدد ثابت برای همه وجود ندارد. Retention باید با RPO، حجم Backup، نرخ تغییر داده، ظرفیت Storage و سیاست حذف هماهنگ باشد.
| سناریو نمونه | Retention آزمایشی |
|---|---|
| Backup روزانه شخصی | ۷ تا ۳۰ روز |
| Server کاری مهم | ۳۰ تا ۹۰ روز براساس ظرفیت |
| آرشیو قانونی | براساس Policy و الزامات قانونی |
این اعداد فقط مثال طراحی هستند؛ قبل از Compliance واقعی ظرفیت را محاسبه کنید.
Immutable Storage و قانون 3-2-1-1-0
معماری مقاوم‌تر Backup معمولاً فقط یک Repository ندارد. یک نمونه:
🔹 ۳ نسخه از داده
🔹 ۲ نوع Storage یا Failure Domain
🔹 ۱ نسخه Off-site
🔹 ۱ نسخه Offline یا Immutable
🔹 ۰ خطا در Restore Test
Backup Tool باید با Object Lock سازگار باشد
بعضی Backup Toolها هنگام Prune یا Retention داخلی خودشان تلاش میکنند Objectهای قدیمی را حذف کنند. اگر آن Object هنوز WORM Locked باشد، عملیات Delete شکست می‌خورد.
بنابراین Retention نرم‌افزار Backup و Retention Storage را جداگانه و هماهنگ طراحی کنید.
Immutable به معنی ضدخرابی سخت‌افزار نیست
Object Lock جلوی Delete و Overwrite منطقی را می‌گیرد، اما اگر تنها Disk خراب شود، Data Center از دسترس خارج شود یا کل VPS حذف شود، Immutability به‌تنهایی Recovery ایجاد نمی‌کند.
برای داده مهم، نسخه دوم در Failure Domain جدا همچنان لازم است.
مشکلات رایج
Object پاک نمی‌شود
اگر Compliance یا Governance فعال است، Retention Info و Version ID را بررسی کنید. این رفتار ممکن است دقیقاً همان Protection مورد انتظار باشد.
Backup Software در Prune خطا می‌دهد
احتمالاً Tool می‌خواهد Objectی را حذف کند که هنوز Lock است. Policy نرم‌افزار و Storage را هماهنگ کنید.
Storage پر شده ولی فایل‌ها حذف نمی‌شوند
Compliance Retention را نمی‌توان صرفاً برای آزاد کردن Disk دور زد. به همین دلیل Capacity Planning قبل از Lock بسیار مهم است.
برای طراحی Retention یا Backup Repository مطمئن نیستید؟
اگر Governance، Compliance، ظرفیت Storage یا سازگاری نرم‌افزار Backup برایتان مبهم است، قبل از Lock طولانی بهتر است معماری بررسی شود؛ چون بعضی تصمیم‌ها تا پایان Retention قابل بازگشت نیستند.
📌 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
سؤالات متداول
Immutable Backup چیست؟
Backupی است که نسخه محافظت‌شده آن در مدت Retention قابل تغییر یا حذف نیست.
WORM یعنی چه؟
Write Once Read Many؛ داده نوشته میشود و در دوره Lock میتوان آن را خواند اما نسخه محافظت‌شده قابل تغییر نیست.
Governance با Compliance چه تفاوتی دارد؟
Governance برای User دارای Permission خاص قابل Bypass است؛ Compliance حتی برای Root نیز تا پایان Retention قابل حذف نیست.
آیا Object Lock جلوی Ransomware را می‌گیرد؟
میتواند حذف یا Overwrite نسخههای Lockشده را محدود کند و لایه مهمی در مقاومت در برابر Ransomware باشد، اما جای معماری Backup کامل را نمی‌گیرد.
آیا حذف عادی Object در Bucket Versioned یعنی Backup پاک شده است؟
لزوماً نه؛ حذف بدون Version ID ممکن است Delete Marker بسازد و نسخه اصلی همچنان تحت Retention باقی بماند.
آیا Immutable Storage باید روی سرور جدا باشد؟
برای داده مهم، جدا کردن Failure Domain و Credentialها Protection واقعی‌تری ایجاد میکند.
جمع‌بندی
Versioning به‌تنهایی Backup را Immutable نمی‌کند. برای ساخت Repository مقاوم‌تر باید Object Lock و Retention را روی Versionهای Backup اعمال کنید.
Governance برای شروع و تست انعطاف بیشتری دارد؛ Compliance سخت‌گیرانه‌تر است و قبل از استفاده باید Capacity و Policy دقیق مشخص شوند.
در نهایت Immutable Storage فقط یک لایه از Data Protection است. نسخه Off-site، Credential جدا و Restore Test همچنان بخش‌های ضروری معماری Backup هستند.
دیدگاه‌ها (۰)