الخلاصة

  • تتيح Fly.io استرجاع معرّف وحدة التخزين المحذوفة لمدة 24 ساعة. ويمكن استخدام المعرّف المحفوظ للوصول إلى لقطاتها ما دامت باقية ضمن مدة الاحتفاظ.
  • تُفعّل اللقطات اليومية التلقائية افتراضيًا، بمدة احتفاظ افتراضية خمسة أيام قابلة للضبط من يوم إلى 60 يومًا. تعديل الإعداد يخص اللقطات الجديدة.
  • تتوقف رسوم وحدة التخزين في حالة pending_destroy، بينما يخضع تخزين اللقطات لحساب منفصل. الاستعادة تنشئ وحدة جديدة وتتطلب عملًا إضافيًا لإرجاع الخدمة.

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

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

إيصال الحذف لا يساوي تسليم المسؤولية

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

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

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

خمسة أيام ليست هدية بعد الحذف

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

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

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

حتى طلب لقطة عند الحاجة يمر بمراحل. تعرض الوثائق حالات waiting ثم running ثم created. إرسال الطلب يثبت وجود طلب؛ الحالة الأخيرة تثبت اكتمال الإنشاء. من يمحو الأصل بينما الدليل الوحيد هو بدء الطلب يجعل جدوله الزمني أسرع من وسيلة إنقاذه.

أسبوع كامل، لكن في سياق آخر

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

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

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

الدفتر المالي لا يملك عدّادًا واحدًا

تُحسب رسوم وحدات التخزين بالتناسب مع الساعات، حتى إن لم تكن الوحدة موصولة أو كانت الآلة متوقفة. وفي حالة pending_destroy تتوقف رسوم الوحدة. لذلك يمكن للحذف أن ينهي تكلفة لا يكفي إيقاف الآلة لإنهائها.

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

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

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

يعرّف سجل العضوية الأولي لدى RIPE NCC المؤسسة باسم Fly.io, Inc. هذا مرجع لهوية الجهة، بينما مصدر آليات الحذف والاستعادة والفوترة هو وثائق Fly.io التشغيلية. عنوان العضوية لا يحدد مكان بيانات العميل. أما عنوان اللقطة داخل سجل الاسترداد فيحدد عملًا يجب إنجازه قبل أن ينتهي وقت البحث عنه.

المصادر الأصلية