أي تخزين S3 مستضاف ذاتياً يناسبك؟ وما الذي تغير في MinIO

إذا قررت أن تستضيف تخزين الكائنات S3 بنفسك، فأول اسم كان يخطر على البال قبل سنتين هو MinIO، ثم تغير وضعه خطوة بعد خطوة حتى أصبح مستودعه مؤرشفاً، فصار السؤال اليوم: هل ما زال MinIO خياراً، وإذا لم يكن فما البديل، Garage الخفيف أم SeaweedFS الأوسع ميزات؟ والإجابة تعتمد على ما تحتاجه من واجهة S3، وعلى عدد السيرفرات والمواقع لديك، وعلى الأداء على جهازك.

شرحنا تثبيت الأدوات الثلاث وبنية كل منها، وكسرناها بإيقاف السيرفرات وإتلاف الأقراص، في الدليل التالي، وهنا نجمع ما تغير في MinIO من مصادره الأولية، ثم نقيس الأدوات الثلاث على الجهاز نفسه، ونضع جدولاً عادلاً ودليلاً للاختيار:

دليلتخزين الكائنات S3 على سيرفرك: التثبيت والبنيةكيف تثبت ثلاث أدوات تخزين S3 مفتوحة المصدر في إعداد صغير يتحمل الأعطال، وماذا يحدث فعلاً عندما يتوقف سيرفر أو يتلف قرص.دليلأنواع التخزين وواجهة S3: أين تضع بيانات تطبيقك؟أين تضع قاعدة البيانات وملفات المستخدمين والنسخ الاحتياطية، ولماذا يناسب كلاً منها نوع مختلف من التخزين.دليلالنسخ الاحتياطي إلى S3 مع Object Lock ضد الفديةكيف تقفل نسخك الاحتياطية في S3 حتى لا يمحوها من يسرق مفاتيحها، وكيف تستعيدها إلى ما قبل الهجوم.

وسوف نناقش في هذا المقال ما يلي:

• ما الذي تغير في MinIO المجتمعي بالتواريخ، كل خطوة من commit أو ملاحظات إصدار في مستودعه.
• النسخ المشتقة Forks التي حاولت أن تكمل الطريق، وما الذي نعرفه عنها.
• قياس واحد مشترك: سرعة الرفع والتنزيل للملفات الصغيرة والكبيرة، والذاكرة في الخمول وبعد الحمل.
• جدول الميزات والرخص، ونقاط القوة ونقاط الضعف لكل أداة، ثم دليل الاختيار.

ما الذي تغير في MinIO؟

الصورة التالية تبين المحطات الست، وبعدها التفصيل مع المصدر الأولي لكل واحدة، وقد اختصرناها أيضاً في مقال أنواع التخزين:

• 18 أبريل 2021، الرخصة: غيرت MinIO رخصة الخادم من Apache-2.0 إلى AGPL-3.0 في commit واحد عدل ملف LICENSE. وتعني AGPL أنك إذا عدلت الكود وقدمته للناس عبر الشبكة فعليك أن تنشر تعديلاتك، وقد شرحنا الرخص في البرمجيات مفتوحة المصدر وتراخيصها، والاستخدام الداخلي دون تعديل لا يطلب منك شيئاً عملياً، ولكن كثيراً من الشركات تمنع AGPL في سياستها.
• 24 مايو 2025، الواجهة: في ملاحظات الإصدار أصبحت واجهة الإدارة المدمجة مهملة Deprecated، ونقلت إلى مشروع منفصل، وأزيل منها الدخول عبر LDAP وOIDC وأصبح جزءاً من المنتج التجاري AIStor. والنتيجة في نسختنا المبنية من الكود واجهة فيها ال Buckets والملفات فقط، كما في الصورة التالية من تجربتنا، أما المستخدمون والسياسات فبأداة mc.

• 15 أكتوبر 2025، الكود فقط: عدلت MinIO ملف README في هذا ال commit ليقول إن النسخة المجتمعية توزع ككود مصدري فقط، ولن تنشر ملفات تنفيذية جاهزة. وفي اليوم نفسه صدر RELEASE.2025-10-15T17-29-55Z لإصلاح ثغرة تصعيد صلاحيات، وطريقة التثبيت فيه go install، ولل Containers «انسخ الكود وابن ال Image بنفسك». وهو آخر إصدار في المستودع، وهو ما بنيناه في التجربة.
• 3 ديسمبر 2025، الصيانة: أضيف إلى README في هذا ال commit أن المشروع في وضع الصيانة Maintenance Mode، فلا ميزات جديدة ولا طلبات دمج، والإصلاحات الأمنية الحرجة «قد تدرس حالة بحالة».
• 12 فبراير 2026، لم يعد يصان: تغير النص في هذا ال commit إلى THIS REPOSITORY IS NO LONGER MAINTAINED، مع بديلين: AIStor Free، ويصفه README بأنه إصدار مستقل Standalone كامل الميزات للاستخدام المجتمعي برخصة مجانية، وAIStor Enterprise الموزع مع دعم تجاري، وكلاهما منتج من MinIO وليس المستودع المفتوح.
• أبريل 2026، الأرشفة: صفحة المستودع تظهره مؤرشفاً للقراءة فقط، وآخر دفع إليه بحسب واجهة GitHub كان في 24 أبريل 2026. وعندما حاولنا في 11 أكتوبر 2026 سحب minio/minio من Docker Hub وquay.io/minio/minio رفض السجلان الطلب، أي أن التثبيت بأمر docker pull المعتاد لم يعد يعمل.

وماذا يعني هذا لمن لديه MinIO يعمل اليوم؟ لن يتوقف الخادم، ولكن الثغرات الجديدة لن تصل إصلاحاتها من المستودع المفتوح، لذلك عامل التركيب الحالي كنظام تخطط لنقله، وبما أن كل الأدوات تتحدث S3 فالنقل ممكن بأداة مثل rclone من Bucket إلى Bucket، مع الانتباه إلى أن النسخ Versions وإعدادات Object Lock لا تنقل تلقائياً بالنسخ العادي.

النسخ المشتقة: هل يكمل أحد الطريق؟

رخصة AGPL تسمح لأي أحد أن يأخذ الكود ويكمله، وقد بحثنا في النسخ المشتقة من المستودع الأصلي على GitHub، وهذا ما وجدناه في 11 أكتوبر 2026 من صفحات المستودعات نفسها:

• pgsty/silo من فريق Pigsty، أنشئ في 25 أكتوبر 2025 باسم pgsty/minio ثم تغير اسمه إلى Silo في 6 أغسطس 2026، وREADME يقول إنه نسخة مستقلة لا علاقة لها بشركة MinIO، تحافظ على خط إصدارات واحد مع ملفات تنفيذية وImages لعدة معماريات وإصلاحات أمنية وواجهة كاملة، وإن Pigsty تستخدمه في الإنتاج لمستودع نسخ PostgreSQL الاحتياطي. وآخر إصدار للخادم عند كتابة المقال RELEASE.2026-09-03T13-18-01Z. وهو الأكثر نشاطاً بين النسخ المشتقة.
• OpenMaxIO وgeorgmangold/console: نسختان من واجهة الإدارة القديمة فقط وليس من الخادم، الأولى أنشئت في مايو 2025 وآخر دفع إليها في يونيو 2025، والثانية في يونيو 2025 وآخر دفع في يوليو 2026.
• libreFS وchainguard-forks/minio: الأولى تعد بالواجهة الكاملة والملفات التنفيذية وآخر دفع إليها في مايو 2026، والثانية من Chainguard لبناء Images الخاصة بها.

هل تعتمد على نسخة مشتقة؟ يمكن ذلك إذا كنت تحتاج توافق MinIO بالذات، لأن الأدوات والسكربتات القديمة تعمل عليها، ولكن قيمها كما تقيم أي مشروع جديد: من يصونه، وكم إصداراً أصدر، ومن يستخدمه في الإنتاج، وماذا يحدث لو توقف بعد سنة. ونحن لم نختبر أياً منها في هذا المقال.

كيف قمنا بالقياس؟

شغلنا كل أداة وحدها على الجهاز نفسه، عقدة واحدة ونسخة واحدة دون تكرار، حتى نقيس الأداة نفسها وليس الشبكة بين العقد:

• Garage v2.4.1 بالخيار --single-node وreplication_factor = 1 وقاعدة بيانات LMDB.
• SeaweedFS 4.48 بالأمر weed server -s3، أي Master وVolume وFiler وبوابة في عملية واحدة، دون تكرار.
• MinIO RELEASE.2025-10-15T17-29-55Z المبني من الكود، على قرص واحد.

والكلاينت واحد للجميع: سكربت boto3 في Container على شبكة Docker نفسها، يرفع 2,000 ملف من 16 KB ب 16 خيطاً Thread ثم ينزلها، ثم يرفع أربعة ملفات من 256 MB على خيطين، كل ملف بأجزاء من 16 MB، ثم ينزلها، ويكرر ذلك ثلاث مرات ويطبع الوسيط Median:

# bench.py: same client, same data, same machine. Prints MB/s and objects/s for PUT and GET.
#   python3.11 bench.py <bucket>
import os, sys, time, statistics, concurrent.futures as cf, boto3
from boto3.s3.transfer import TransferConfig
from botocore.config import Config

B = sys.argv[1]
s3 = boto3.client("s3", endpoint_url=os.environ["AWS_ENDPOINT_URL"],
                  config=Config(signature_version="s3v4", max_pool_connections=32, retries={"max_attempts": 2}))
TC = TransferConfig(multipart_threshold=16 * 2**20, multipart_chunksize=16 * 2**20, max_concurrency=8)
SMALL, N_SMALL = 16 * 1024, 2000          # 2,000 objects of 16 KB
LARGE, N_LARGE = 256 * 2**20, 4           # 4 objects of 256 MB
data_small, data_large = os.urandom(SMALL), os.urandom(LARGE)

class Body:                                # a file-like view of the same random buffer, so the client does not copy it
    def __init__(self, b): self.b, self.p = memoryview(b), 0
    def read(self, n=-1):
        if n < 0: n = len(self.b) - self.p
        c = self.b[self.p:self.p + n]; self.p += len(c); return bytes(c)
    def seek(self, o, w=0): self.p = o if w == 0 else (self.p + o if w == 1 else len(self.b) + o); return self.p
    def tell(self): return self.p

def run(fn, items, workers):
    t = time.perf_counter()
    with cf.ThreadPoolExecutor(workers) as ex: list(ex.map(fn, items))
    return time.perf_counter() - t

def small_put(i): s3.put_object(Bucket=B, Key=f"small/{i:05d}", Body=data_small)
def small_get(i): s3.get_object(Bucket=B, Key=f"small/{i:05d}")["Body"].read()
def large_put(i): s3.upload_fileobj(Body(data_large), B, f"large/{i}", Config=TC)
def large_get(i):
    class Sink:
        def write(self, b): return len(b)
    s3.download_fileobj(B, f"large/{i}", Sink(), Config=TC)

res = {k: [] for k in ("small_put", "small_get", "large_put", "large_get")}
for r in range(3):
    t = run(small_put, range(N_SMALL), 16); res["small_put"].append(N_SMALL / t)
    t = run(small_get, range(N_SMALL), 16); res["small_get"].append(N_SMALL / t)
    t = run(large_put, range(N_LARGE), 2);  res["large_put"].append(N_LARGE * LARGE / 2**20 / t)
    t = run(large_get, range(N_LARGE), 2);  res["large_get"].append(N_LARGE * LARGE / 2**20 / t)
med = {k: statistics.median(v) for k, v in res.items()}
print(f"16 KB PUT  {med['small_put']:8.0f} obj/s  ({med['small_put'] * SMALL / 2**20:6.1f} MB/s)   runs: {[round(x) for x in res['small_put']]}")
print(f"16 KB GET  {med['small_get']:8.0f} obj/s  ({med['small_get'] * SMALL / 2**20:6.1f} MB/s)   runs: {[round(x) for x in res['small_get']]}")
print(f"256 MB PUT {med['large_put']:8.0f} MB/s    runs: {[round(x) for x in res['large_put']]}")
print(f"256 MB GET {med['large_get']:8.0f} MB/s    runs: {[round(x) for x in res['large_get']]}")

وقسنا الذاكرة بالأمر docker stats بعد 60 ثانية من تشغيل الأداة دون أي طلب، ثم مباشرة بعد انتهاء الحمل. وكررنا الجولة كاملة مرتين في وقتين مختلفين. والجهاز Intel Core i7-7700K بثمانية خيوط و32 GB تحت Docker Desktop على WSL2، وكانت تعمل عليه في الوقت نفسه خدمات أخرى، لذلك الأرقام هنا محلية ومتذبذبة، وتصلح لمقارنة الأدوات ببعضها على الجهاز نفسه، ولا تصلح كأرقام أداء متوقعة لسيرفرك، فالسيرفر الحقيقي بأقراص NVMe وشبكة حقيقية ودون Docker Desktop سوف يعطي أرقاماً أعلى بكثير.

النتائج

المخرج من الجولة الثانية كما يلي، والجولة الأولى في الجدول بعده:

===== Garage v2.4.1 (single node, replication_factor 1, LMDB)
idle after 60s: 5.457MiB / 31.29GiB
16 KB PUT        67 obj/s  (   1.0 MB/s)   runs: [67, 71, 56]
16 KB GET        91 obj/s  (   1.4 MB/s)   runs: [82, 92, 91]
256 MB PUT       26 MB/s    runs: [27, 26, 26]
256 MB GET       40 MB/s    runs: [37, 47, 40]
after load: 252.4MiB / 31.29GiB
===== SeaweedFS 4.48 (weed server -s3, one volume server, replication 000)
idle after 60s: 86.69MiB / 31.29GiB
16 KB PUT        86 obj/s  (   1.3 MB/s)   runs: [86, 88, 84]
16 KB GET       114 obj/s  (   1.8 MB/s)   runs: [118, 114, 104]
256 MB PUT       52 MB/s    runs: [44, 53, 52]
256 MB GET      206 MB/s    runs: [165, 206, 221]
after load: 2.477GiB / 31.29GiB
===== MinIO RELEASE.2025-10-15T17-29-55Z (built from source, one drive)
idle after 60s: 82.93MiB / 31.29GiB
16 KB PUT        71 obj/s  (   1.1 MB/s)   runs: [119, 71, 60]
16 KB GET       171 obj/s  (   2.7 MB/s)   runs: [205, 171, 96]
256 MB PUT       95 MB/s    runs: [121, 95, 19]
256 MB GET      298 MB/s    runs: [302, 298, 138]
after load: 577.2MiB / 31.29GiB

والصورة التالية تبين وسيط الجولات الست لكل أداة، والخط أقل وأعلى جولة:

في النتائج أعلاه لاحظ التالي:

• MinIO كان الأسرع في أغلب القياسات، وخاصة الملفات الكبيرة، ولكنه الأكثر تذبذباً، فرفع الملفات الكبيرة تراوح بين 19 و206 MB/s، وهذا يشير إلى أن الجهاز المشترك أثر عليه أكثر من غيره.
• Garage كان الأبطأ في كل القياسات وبفارق كبير في الملفات الكبيرة، وكان ثابتاً بين الجولتين، وهذا يتفق مع صفحة أهدافه التي تقول إن الأداء الأقصى ليس هدفاً، وإنما البساطة والعمل بين المواقع.
• في الخمول استخدم Garage أقل من 7 MiB، أي عشر ما استخدمه الآخران، وهذا هو الفرق المهم إذا كنت تضع عقدة على جهاز صغير.
• بعد الحمل ارتفعت ذاكرة SeaweedFS إلى 1.56 و2.48 GiB، وهي الأعلى، فإذا كان السيرفر صغيراً فراقبها في الأيام الأولى قبل أن تضع عليه خدمات أخرى.
• الأرقام المطلقة منخفضة لكل الأدوات، 1 إلى 3 MB/s للملفات الصغيرة، والسبب الجهاز المشترك والكلاينت المكتوب بلغة Python، فلا تقارنها بأرقام المطورين المنشورة.

الميزات والرخص في جدول واحد

الميزات من سكربت التوافق الذي شغلناه على الثلاثة في دليل التثبيت، والرخص من مستودعاتها:

Garage

نقاط القوة: الأخف على الإطلاق في تجربتنا، أقل من 7 MiB في الخمول، ومصمم لعقد في مواقع مختلفة عبر الإنترنت العادي، فثلاثة أجهزة صغيرة في ثلاثة مكاتب تكفيه، وتشغيله وفهمه بسيط، والنصاب يمنع الكتابة التي لا يضمن قراءتها.

نقاط الضعف: لا يدعم Versioning ولا Object Lock ولا سياسات ال Bucket، فلا يصلح وحده للنسخ الاحتياطي المحمي من الفدية، وكان الأبطأ في قياسنا، ولا توجد له واجهة رسمية، والتخطيط Layout يحتاج خطوات يدوية عند كل تغيير.

SeaweedFS

نقاط القوة: أوسع دعم لواجهة S3 بين الثلاثة في تجربتنا، فقد قبل الميزات الثماني كلها ورفض حذف النسخة المقفلة، ورخصته Apache-2.0 هي الأكثر مرونة، ويتوسع بإضافة خوادم Volumes وبوابات دون إعادة توزيع، ويقدم نظام ملفات وWebDAV مع S3، وله واجهة إدارة فيها المستخدمون والمجموعات والسياسات، كما في الصورة التالية من تشغيل weed mini في تجربتنا.

نقاط الضعف: مكونات أكثر تحتاج فهماً، Master وVolume وFiler وبوابة، والبوابة دون ملف هويات تقبل أي مفتاح، والكتابة توقفت عندما تعطل خادم من اثنين مع قاعدة 001، وكانت ذاكرته الأعلى بعد الحمل، ووجدنا أنه يغير تاريخ آخر تعديل عند تمديد قفل الكائن، وهذا كسر الاستعادة الزمنية في Kopia كما في تجربة Object Lock.

MinIO

نقاط القوة: الأسرع في قياسنا، وترميز المحو فيه ناضج، فقد قرأ الملف بعد إتلاف قرصين وأصلحهما في ثانية، ودعمه لواجهة S3 واسع، وأغلب الأدوات والأدلة على الإنترنت كتبت له، والنسخة المشتقة Silo تقدم إصدارات مبنية لمن يحتاج التوافق معه.

نقاط الضعف: المستودع مؤرشف ولم يعد يصان، والتثبيت بالبناء من الكود، والواجهة المجتمعية متصفح ملفات فقط، ولا يدعم إعداد CORS على ال Bucket، ورخصته AGPL-3.0، وتوسيعه يكون بمجموعات أقراص كاملة وليس بقرص واحد.

أي أداة تختار؟

• تخزين ملفات تطبيق صغير أو متوسط على سيرفر أو ثلاثة، أو عدة مواقع متفرقة: Garage، والسبب الخفة والبساطة والعمل بين المواقع، بشرط ألا تحتاج Versioning أو Object Lock أو سياسات.
• نسخ احتياطي محمي بقفل الكائنات، أو تطبيق يحتاج ميزات S3 الأوسع، أو ملايين الملفات: SeaweedFS، مع ملف هويات من أول يوم، وخوادم أكثر من عدد النسخ، واختبار الاستعادة على إصدارك.
• لديك MinIO يعمل اليوم: لا تبدأ مشروعاً جديداً عليه، وخطط للانتقال إلى SeaweedFS أو Garage بأداة rclone، وإذا كنت مضطراً للبقاء فتابع الثغرات، أو قيم Silo كنسخة مشتقة تحصل على إصلاحات.
• مؤسسة تحتاج Block وFile وObject معاً على عدة سيرفرات: لا شيء من الثلاثة، وإنما Ceph مع RGW، وقد لخصناه في قسم Ceph.
• لا تريد إدارة تخزين أصلاً: خدمة سحابية متوافقة مع S3، بعد أن تحسب ال Egress كما في فاتورة S3.

الخلاصة

• MinIO المجتمعي انتقل من Apache-2.0 إلى AGPL-3.0 في 2021، ثم فقد واجهة الإدارة في مايو 2025، ثم أصبح كوداً فقط في أكتوبر 2025، ثم دخل وضع الصيانة، ثم لم يعد يصان في فبراير 2026، ثم أرشف في أبريل 2026.
• أنشط نسخة مشتقة هي Silo من Pigsty، ولم نختبرها.
• في قياسنا المحلي كان MinIO الأسرع والأكثر تذبذباً، وSeaweedFS في الوسط وبأعلى ذاكرة بعد الحمل، وGarage الأبطأ والأخف بأقل من 7 MiB في الخمول.
• Garage لا يدعم Versioning ولا Object Lock ولا السياسات، وSeaweedFS دعم الميزات الثماني، وMinIO كلها ما عدا CORS على ال Bucket.
• Garage للمواقع المتفرقة والبساطة، وSeaweedFS للميزات والنسخ المقفلة، وMinIO لفترة انتقالية فقط.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، والقياس على Garage v2.4.1 وSeaweedFS 4.48 وMinIO RELEASE.2025-10-15T17-29-55Z مبني من الكود، بكلاينت boto3 1.43.111 في Docker Engine 29.8.0 على Docker Desktop، وحالة مستودع MinIO والنسخ المشتقة والسجلات كما رأيناها في 11 أكتوبر 2026.