لم تكن مشكلة المستخدم الأصلي ببساطة هي «أن صندوقي ZimaOS لا يستطيعان نسخ البيانات». فقد كان ينقل نحو 600 غيغابايت بين نظامين يعملان بالإصدار ZimaOS 1.5.x، وكانت عملية النقل في Files تتوقف مرارًا برسالة «المضيف متوقف»، مع بقاء الخادمين نفسيهما متصلين بالإنترنت.
ينبغي فصل هذا السلوك التاريخي عن ZimaOS الحالي. توصي IceWhale الآن صراحةً باستخدام التخزين عبر الشبكة المحلية (LAN Storage) في Files عند نقل البيانات من جهاز NAS آخر، بينما يمكن لتطبيق Backup الحالي استهداف جهاز Zima آخر، كما يوفر مهام قابلة للاستئناف ومقاومة للأعطال. عند إجراء عملية نقل كبيرة جدًا، اختر الطريقة وفقًا لما إذا كنت تريد نسخة مرئية لمرة واحدة، أو مهمة حماية قابلة للاستئناف، أو أسرع وسيلة نقل مادية.
توقفت عملية نقل الملفات من المصدر مرارًا رغم بقاء المضيفين متصلين
جرّب المستخدم الاتجاهين: الدفع من صندوق ZimaOS القديم والسحب من الصندوق الجديد. وفي كلتا الحالتين، توقفت عملية Files المعتمدة على المتصفح في النهاية، رغم أن لوحة تحكم المصدر ظلت قابلة للوصول.
أوصى المجتمع باستخدام rsync باعتباره خيار سطر الأوامر الأكثر قابلية للاستئناف
اقترح أحد أفراد المجتمع استخدام rsync عبر SSH مع دعم النقل الجزئي، بحيث يمكن إعادة تشغيل عملية النسخ المتوقفة دون البدء من جديد. هذه إرشادات متقدمة مفيدة، لكنها لم تصدر عن موظفي IceWhale، كما أن المستخدم الأصلي لم يؤكد أنه استخدمها.
لا تزال إرشادات IceWhale الحالية تستخدم Files للترحيل بين أجهزة NAS
توصي وثائق ZimaOS الحالية بإضافة جهاز NAS القديم كتخزين عبر الشبكة المحلية (LAN Storage) في Files، ثم نسخ المجلدات إلى مساحة تخزين ZimaOS الجديدة. وهذا يعني أنه لا ينبغي تعميم مهلة التوقف في الإصدار 1.5.x إلى قاعدة تقول «لا تستخدم Files أبدًا للترحيل الكبير».
استخدم سير عمل الترحيل الحالي عبر التخزين عبر الشبكة المحلية لإجراء نسخة عادية مرئية.
يمكن لتطبيق Backup الحالي استهداف جهاز Zima آخر
بالنسبة إلى عمليات النقل طويلة المدة، حيث تكون إمكانية الاستئناف أهم من تصفح الوجهة يدويًا، يدعم تطبيق Backup الحالي استخدام جهاز Zima آخر كوجهة. وتوثّق IceWhale الجداول الزمنية، والتقدم الفوري، والاستئناف، ومقاومة الأعطال.
راجع سير عمل النسخ الاحتياطي الحالي القابل للاستئناف بين أجهزة Zima.
يُعد SMB بديلًا مباشرًا لمنطق النسخ عبر المتصفح
أوصى مجتمع المصدر أيضًا بتركيب مشاركة SMB الخاصة بالمصدر على الوجهة، ثم إجراء النسخ من جهة الوجهة. وكان المستخدم قد نقل البيانات بنجاح سابقًا من جهاز NAS أقدم إلى ZimaOS باستخدام مشاركات SMB المركّبة.
قد يكون النقل باستخدام USB أو NVMe الأسرع عندما يكون الصندوقان متجاورين فعليًا
بالنسبة إلى مئات الغيغابايت أو عدة تيرابايتات، يمكن لقرص SSD/NVMe خارجي سريع تجاوز جميع متغيرات الشبكة. والمقابل هو إجراء عمليتي نسخ: من المصدر إلى وسيط النقل، ثم من وسيط النقل إلى الوجهة.
قد تجعل الملفات الصغيرة الكثيرة عملية الترحيل تبدو أبطأ بكثير
يمكن أن تنتقل AppData، والصور المصغرة، والملفات الجانبية للصور، وأشجار الشيفرة، وغيرها من مجموعات البيانات الكثيفة بالبيانات الوصفية، بسرعة أقل بكثير من ملفات الوسائط الكبيرة، لأن كل ملف يحتاج إلى عمليات فتح وإنشاء ومعالجة بيانات وصفية.
تحقق قبل حذف المصدر
بعد أي عملية ترحيل، قارن مجلدات تمثيلية، وعدد الملفات عندما يكون ذلك عمليًا، وافتح الملفات المهمة على الوجهة. أبقِ المصدر سليمًا حتى يُستخدم الصندوق الجديد بنجاح وتتوافر نسخة احتياطية.
يعالج Files وBackup مشكلتين مختلفتين في الترحيل
يُعد Files الخيار الأوضح عندما تريد تصفح المصدر، واختيار مجلدات معينة، ورؤية الملفات المنسوخة فورًا في الوجهة. أما Backup فهو أفضل عندما يُتوقع أن تستغرق عملية النقل ساعات أو أيامًا، وتهمك إمكانية الاستئناف ومقاومة الأعطال والجدولة وسجل المهام القابل للاستعادة.
لا تسمِّ مهمة Backup عملية «نقل» شفافة. فهي تنشئ نسخة محمية لها آليات استعادة خاصة بها؛ لذا تحقّق من تخطيط الوجهة قبل حذف المصدر.
تحقق من مسار الشبكة قبل تحسين أداة النسخ
على اتصال اسمي بسرعة 1 GbE، تحقّق من أن الجهازين تفاوضا فعليًا على اتصال إيثرنت بسرعة غيغابت، ومن عدم وجود جزء يعمل عبر Wi‑Fi أو بسرعة 100 ميغابت/ثانية، ومن سلامة المحول والكابلات. فلا يمكن لأداة النسخ تجاوز سرعة اتصال مادي بطيء.
اختبر بعد ذلك ملفًا كبيرًا واحدًا. فإذا كان الملف الكبير سريعًا بينما كانت شجرة المجلدات بطيئة، فمن المرجح أن يكون عدد الملفات والعبء الناتج عن البيانات الوصفية في مجموعة البيانات أهم من عرض النطاق الترددي الخام للشبكة.
تحتاج ملفات المستخدم وAppData النشط إلى تعامل مختلف
يمكن عادةً نسخ الأفلام والصور والمستندات كملفات عادية. أما قواعد بيانات التطبيقات النشطة وAppData، فقد تتطلب إيقاف التطبيق أو تصدير البيانات أو ترحيلها بإجراءات تراعي التطبيق، لضمان اتساق النسخة داخليًا.
لا تفترض أن نسخ مجلد قاعدة بيانات قيد التشغيل بين صندوقين سينتج عنه ترحيل صالح للتطبيق.
احتفظ بأذونات المشاركة أو أعد إنشاءها عمدًا
حتى عند وصول كل بايت، يمتلك صندوق ZimaOS الوجهة مستخدمين وتعريفات مشاركات وربطًا خاصًا بالحاويات. أعد إنشاء أذونات Samba ومسارات وحدات التخزين الخاصة بالتطبيقات المطلوبة، ثم اختبر الوصول باستخدام المستخدم غير المسؤول المقصود.
استخدم انتقالًا على مرحلتين للبيانات المهمة
بالنسبة إلى ترحيل NAS حي وكبير، انسخ البيانات الأساسية أولًا بينما يظل الصندوق القديم نشطًا. وقبيل الانتقال، أوقف عمليات الكتابة أو أوقفها مؤقتًا، وشغّل تمريرة نهائية تزايدية وقابلة للاستئناف، وتحقق من الوجهة، ثم حوّل العملاء إلى الصندوق الجديد. يقلل ذلك من وقت التوقف ويمنع حذف النسخة الوحيدة السليمة في وقت مبكر جدًا.
الأسئلة الشائعة حول الترحيل بين صندوقي ZimaOS
هل أثبت المصدر أن Files غير موثوق دائمًا في عمليات النسخ الكبيرة؟
لا. فقد وثّق حالة فشل في الإصدار 1.5.x. ولا تزال إرشادات IceWhale الحالية تستخدم Files والتخزين عبر الشبكة المحلية لترحيل أجهزة NAS.
ما الخيار الحالي الذي يدعم عمليات النقل القابلة للاستئناف بين أجهزة Zima؟
يمكن لتطبيق Backup الحالي استهداف جهاز Zima آخر، ويتضمن سلوكًا للاستئناف ومقاومة الأعطال.
هل كان rsync الطريقة النهائية المؤكدة التي استخدمها المستخدم الأصلي؟
لا. كان rsync اقتراحًا من المجتمع؛ وقد ذكر المستخدم لاحقًا أن الترحيل اكتمل دون توثيق طريقة النقل النهائية.
