King_Arda وZimaBlade: بناء جهاز NAS منزلي يضع الخصوصية أولًا

تعرّف إلى King_Arda

King_Arda هو منشئ مختبر منزلي على Reddit، وقد وصف نفسه في المنشور الأصلي بأنه يدرس الأمن السيبراني ويمتلك معرفة بالشبكات من خلال Cisco CCNA. لم يكن يبحث فقط عن جهاز قادر على تخزين الملفات، بل أراد خادم NAS يمكن أن يصبح أيضًا مساحة عملية لتجربة الخدمات المستضافة ذاتيًا والشبكات والنسخ الاحتياطية والتخزين.

قبل شراء ZimaBlade، قارن بين خيارات NAS التقليدية وإعادة استخدام حاسوب قديم. وفي النهاية اختار النظام الأصغر المعتمد على x86 لأن مزيج السعر والمرونة والمظهر والمساحة المتاحة للتجربة كان يتوافق مع ما يريده من أول خادم NAS لمختبره المنزلي.

يمكنك متابعة King_Arda على Reddit للاطلاع على الملف الشخصي للمنشئ وراء قصة المستخدم هذه.

إفصاح: في منشور Reddit الأصلي، ذكر King_Arda أنه تواصل مع دعم Zima بعدما اكتشف أن مزوّد الطاقة الموجود لديه لم يكن قويًا بما يكفي لإعداد التخزين الذي يريده. وأوضح أن الدعم وفّر شحنًا مجانيًا مقابل نشر منشور Reddit، مع تأكيده أيضًا أنه كان حرًا في مشاركة رأيه الخاص. وتحافظ قصة المستخدم هذه على هذا الإفصاح وعلى انتقاداته لتجربة الإعداد.

من البحث عن NAS إلى ZimaBlade

فكّر King_Arda في خيارين مألوفين للبدء قبل اختيار ZimaBlade: شراء جهاز NAS من Synology أو إعادة استخدام حاسوب قديم. ودفعه بحثه في النهاية نحو منصة DIY أصغر يمكنها العمل كتخزين وخادم منزلي متعدد الاستخدامات في الوقت نفسه.

وصف اختياره إلى حد كبير من ناحية القيمة والمرونة. كما أعجبته الفكرة الأوسع للبرمجيات مفتوحة المصدر وامتلاك تحكم أكبر في الخدمات التي تعمل على الجهاز. وكان ذلك مهمًا لأن NAS لم يكن مصممًا ليبقى جهازًا مخصصًا لغرض واحد.

تصف وثائق ZimaBlade الحالية المنصة بأنها خادم أحادي اللوحة بمعمارية x86، مع منفذي SATA 3.0 وإيثرنت بسرعة Gigabit وإمكانية توسعة عبر PCIe. ولا يحدد منشور King_Arda ما إذا كانت لوحته طراز 3760 أم 7700، لذلك لا تنسب هذه القصة أيًا منهما إليه.

لماذا ظل ZimaOS في مركز الإعداد

أبقى King_Arda على ZimaOS في النظام بدلًا من استبداله فورًا بـ Windows أو Proxmox أو نظام تشغيل خوادم آخر. وقد أعجبته تجربة الملفات المعتمدة على المتصفح ومتجر التطبيقات، لأنهما سهّلا اكتشاف تطبيقات Docker ونشرها دون تحويل كل تجربة إلى مشروع يعتمد على سطر الأوامر.

أصبحت ثلاثة تطبيقات محورية في الإعداد: Immich للصور، وJellyfin للوسائط، وDuplicati لسير عمل النسخ الاحتياطي. كما جرّب تطبيقات أخرى على طول الطريق، وهنا بدأ الجهاز يتصرف بدرجة أقل كخادم NAS بسيط وبدرجة أكبر كعقدة حقيقية في مختبر منزلي.

الخصوصية دون التخلي عن النسخ الاحتياطي خارج الموقع

كانت الصور أحد أوضح أسباب King_Arda للاستضافة الذاتية. فقد قال إنه لم يكن مرتاحًا لترك مكتبة صوره بالكامل لدى Google، لا سيما بسبب مخاوفه بشأن كيفية استخدام الصور المستضافة سحابيًا فيما يتصل بالذكاء الاصطناعي.

لم يكن الحل الذي اختاره هو التخلي عن التخزين السحابي تمامًا. فقد منحه Immich خدمة للصور على أجهزة يتحكم بها، بينما أرسل Duplicati نسخة احتياطية مشفّرة من صوره إلى Google Drive. كما وصف إعادة الملفات من Drive إلى ZimaBlade، بحيث لا يمثل أي طرف النسخة الوحيدة.

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

استخدام WireGuard بدلًا من إضافة طبقة أخرى للوصول عن بُعد

بالنسبة إلى الوصول عن بُعد، فكّر King_Arda في Tailscale، لكنه اختار WireGuard لأن جهاز التوجيه لديه كان يدعمه بالفعل. وأتاح له ذلك استخدام مسار شبكي يفهمه بدلًا من إضافة خدمة وصول عن بُعد أخرى مخصصة لخادم NAS فقط.

توثّق الإصدارات الحالية من ZimaOS أيضًا الوصول عن بُعد عبر ZimaClient، لكن إعداد King_Arda يوضح نمطًا مختلفًا للاستضافة الذاتية: يمكن للمستخدمين الذين يديرون شبكتهم الخاصة بالفعل اختيار طبقة الوصول التي تتوافق مع بقية بنيتهم التحتية.

يغطي دليل الوصول عن بُعد الحالي في ZimaOS مسار ZimaClient؛ بينما يوثّق منشور Reddit الأصلي اختيار King_Arda المنفصل لـ WireGuard.

أين توقف المسار السهل عن كونه سهلًا

كان متجر التطبيقات مريحًا، لكن King_Arda لم يصف كل عملية تثبيت بأنها تتم دون تدخل منه تمامًا. فقد قال إنه اضطر أحيانًا إلى تغيير أجزاء من ملف Docker قبل أن يعمل التطبيق بالطريقة التي يريدها.

كما أبلغ عن مشكلة أكثر إثارة للقلق في مسار التخزين: إذ بدا أن بعض البيانات تُكتب على وحدة التخزين الداخلية في ZimaBlade رغم اعتقاده أنه اختار محرك الأقراص الصلب. كذلك لم تعمل مهام النسخ الاحتياطي التي توقع أن تبدأ تلقائيًا دائمًا كما كان متوقعًا.

لم تدفعه هذه المشكلات إلى التخلي عن النظام، لكنها غيّرت نوع المستخدم الذي سيوصي به. فقد كانت تجربته أكثر إيجابية بكثير لمن يرغب في فحص الإعدادات واستكشاف الأخطاء وإصلاحها، مقارنةً بمن يتوقع جهازًا لا يكشف أبدًا عن نموذج الحاويات أو التخزين الأساسي لديه.

إرشادات ZimaOS الحالية توضّح مسارات بيانات التطبيقات بدرجة أكبر

تقدّم وثائق ZimaOS الحالية إرشادات مخصصة لتخزين التطبيقات. ويوصي دليل مسارات تخزين التطبيقات بوضع بيانات التطبيقات على مساحة تخزين رئيسية بدلًا من ترك مجموعات البيانات الدائمة الكبيرة على محرك النظام. ويشير تحديدًا إلى مكتبات الصور مثل Immich بوصفها أعباء عمل يمكن أن تملأ قرص نظام صغيرًا بسرعة.

لا يثبت ذلك حل المشكلة المحددة التي واجهها King_Arda على جهازه. لكنه يوفّر إرشادات حالية أوضح للفئة نفسها من المشكلات التي واجهها أثناء تعلّم كيفية تفاعل استمرارية ZimaOS وDocker معًا.

خادم NAS يوصي به لمن يحبون التجربة، لا للجميع

كان تقييم King_Arda العام مشروطًا عن قصد. فقد أعجبه الجهاز وشعر بأنه أدى ما يريده، لكنه لم يكن ليسلّم التجربة نفسها إلى مبتدئ تمامًا يتوقع أن تعمل كل خدمة دون إعداد أو بحث.

أما لمن يرغب في تعديل الإعدادات وفهم مكان وجود البيانات واستكشاف أخطاء الحاوية وإصلاحها عند الضرورة، فكان استنتاجه أكثر إيجابية بكثير. وبهذا المعنى، لم يعمل ZimaBlade كتخزين فحسب، بل أيضًا كمنصة للتعلّم.

محرك واحد أولًا، ومحرك ثانٍ لاحقًا

في وقت المنشور الأصلي، كان خادم NAS يعمل بمحرك أقراص صلب واحد. وكان King_Arda يخطط لإضافة محرك ثانٍ واستخدام RAID، لكنه لم ينشر مستوى RAID المقصود.

مع وجود قرصين، تتضمن وثائق ZimaOS الحالية RAID 1 بوصفه الخيار المتطابق، بينما يتطلب RAID 5 ثلاثة محركات أقراص على الأقل. وهذه خلفية مفيدة للقراء، لكن لا ينبغي تحويلها إلى ادعاء بأن King_Arda اختار RAID 1 شخصيًا. فالتحديث العلني الذي نشره يقتصر على خطة إضافة قرص آخر.

ترد الخيارات الأوسع في مرجع RAID الحالي من ZimaOS.

أصبح تخطيط الطاقة جزءًا من خطة التخزين

كشف التوجه نحو إضافة قرص ثانٍ عن قيد عملي آخر: إذ لم يكن مزوّد الطاقة في إعداد King_Arda قويًا بما يكفي لتشغيل ما يريده. وكانت تلك المشكلة هي التي دفعته إلى التواصل مع الدعم، وأدت إلى ترتيب الشحن المجاني الذي أفصح عنه في منشور Reddit.

كما توصي إرشادات إعداد ZimaBlade NAS الحالية بالنظر في استخدام طاقة خارجية عند تشغيل محركات الأقراص الصلبة لفترات طويلة. ولا يقدّم المنشور الأصلي طراز محرك الأقراص أو تيار بدء الدوران أو مواصفات المحول أو طراز ZimaBlade، لذلك لا تحاول هذه القصة تشخيص الحد الكهربائي الدقيق لإعداده.

خادم NAS صغير أصبح مختبرًا منزليًا عمليًا

بحلول الوقت الذي كتب فيه King_Arda عن المشروع، كان ZimaBlade يفعل أكثر بكثير من مجرد تخزين الملفات. فقد أصبح خادمًا خاصًا للصور، وجهازًا لتشغيل Jellyfin، وعقدة للنسخ الاحتياطي، ومساحة لتطبيق معرفته بالشبكات والأمن السيبراني التي كان يدرسها بالفعل.

تكمن فائدة القصة في أن التعلّم جاء من النجاحات ومن الاحتكاكات على حد سواء. فقد اضطر إلى تحديد المكان الذي ينبغي أن توجد فيه بيانات الحاويات، وطبقة الوصول عن بُعد المناسبة، وكيفية الاحتفاظ بنسخة مشفّرة خارج الموقع، وما الذي تغيّر عندما أدى توسيع التخزين إلى زيادة متطلبات الطاقة.

لا تزال القصة تُكتب

لا تزال قصة King_Arda وZima تُكتب. يلتقط منشور Reddit المؤرخ 31 يناير 2026 نظامًا كان مفيدًا بالفعل لكنه لا يزال يتوسع: كان محرك أقراص صلب واحد يشغّل أعباء عمل فعلية، وكان التخطيط قائمًا لإضافة قرص ثانٍ وRAID، وأصبح Immich وJellyfin خدمتين يوميتين، بينما تولّى Duplicati مهام النسخ الاحتياطي ووفر WireGuard الوصول عن بُعد.

لا توجد متابعة علنية في المواد التي تم التحقق منها لهذه الصفحة تؤكد ترقية القرص الثاني أو إعداد RAID النهائي أو ما إذا كانت مشكلات بيانات التطبيقات والنسخ الاحتياطي قد حُلّت لاحقًا. وينبغي أن تظل هذه النقاط مفتوحة إلى أن يوثّق King_Arda المرحلة التالية بنفسه.

لمتابعة المصدر وراء هذه القصة، اقرأ منشور ZimaBlade NAS الأصلي على Reddit أو زُر الملف الشخصي لـ King_Arda على Reddit.