اللقطة هي تمثيل لحظة زمنية معينة، والحماية بتتحدد حسب تنفيذها. استراتيجية النسخ الاحتياطي بتضيف احتفاظ مقصود وفصل في الوصول واسترجاع متجرب. بعض اللقطات هي نسخ احتياطية؛ وبعضها بيعتمد على التخزين الأصلي. اسأل إيه اللي بينجو من الحذف أو الاختراق أو فقدان البيئة الأساسية.
وصف النسخة قبل ما تسميها
كلمة لقطة بتقولك إن لحظة زمنية معينة اتمثلت، لكن مش بتقولك فين البيانات القابلة للاسترجاع محفوظة أو مين يقدر يحذفها. لقطة نظام الملفات على التخزين الأصلي ولقطة بلوك مُدارة من المزود ممكن يكون ليهم حدود فشل مختلفة. ابدأ بالتنفيذ بدل ما تتعامل مع الاسم كوعد شامل.
AWS بتوثق لقطات EBS كنسخ احتياطية تزايدية لحظية من وحدات التخزين بتاعتها. ده تنفيذ محدد، مش دليل إن كل خيار لقطة بيتصرف بنفس الطريقة. لأي خدمة، اسأل إذا كان الاسترجاع بيعتمد على الوحدة الأصلية، وإذا كانت النسخ بتخرج من نطاق الفشل الأساسي، وإيه اللي بيحصل لما المصدر يتشال.
قارن الأعطال اللي متوقع تنجو منها
الرجوع السريع بعد تحديث والاسترجاع بعد فقدان حساب مشكلتين مختلفتين. اللقطة المحلية ممكن تكون مريحة للأولى بينما بتوفر فصل قليل للتانية. النسخ المستقلة ممكن تضيف حماية، لكن بس لو التخزين والوصول ومسارات الحذف بتاعتها منفصلة بدرجة كافية عن الحادثة اللي بتستعد لها.
اكتب الفشل والنتيجة المطلوبة. المقارنة التوضيحية دي أداة مساعدة للقرار، مش قائمة ميزات لـ SwissOctet. بتشجع على طرح أسئلة عن النسخ والتحكم بدل الادعاء إن تقنية معينة دايمًا أفضل. النتيجة الفعلية بتعتمد على الإعداد وعملية الاسترجاع الموثقة من المشغل.
| السيناريو | سؤال للقطة | سؤال للنسخة الاحتياطية |
|---|---|---|
| تحديث تطبيق سيء | هل أقدر أرجع للنقطة المقصودة؟ | الاسترجاع القابل للاستخدام بياخد قد إيه؟ |
| فقدان القرص الأساسي | هل النسخة بتعتمد على القرص ده؟ | هل أقدر أسترجع على تخزين جديد؟ |
| اختراق حساب إداري | هل الحساب ده يقدر يحذف كل النسخ؟ | هل صلاحيات الحذف منفصلة؟ |
| خطأ اتكتشف بعد أسابيع | هل النقطة دي لسه محتفظ بيها؟ | هل مدة الاحتفاظ بتغطي تأخير الاكتشاف؟ |
اتأكد من اتساق التطبيق
القرص ممكن يلتقط الملفات بينما التطبيق لسه بيغير فيها. حسب البرنامج وعملية اللقطة، النتيجة ممكن تمثل حالة متسقة مع الانهيار بدل حالة تطبيق منسقة. متفترضش إن الملفات القابلة للقراءة معناها إن قاعدة البيانات والملفات المرفوعة المرتبطة بيها متوافقين. استخدم طريقة النسخ الاحتياطي الموثقة من التطبيق أو قاعدة البيانات.
تصميم الأرشفة المستمرة في PostgreSQL بيوضح الفرق: الاسترجاع محتاج نسخة أساسية مناسبة وتسلسل مستمر لملفات write-ahead log المطلوبة. نسخ مجلد بشكل عشوائي بينما قاعدة البيانات شغالة مش إجراء مكافئ. لو التطبيق كمان بيخزن ملفات خارج قاعدة البيانات، خطط إزاي مجموعتي البيانات دول يتم استرجاعهم مع بعض.
تعامل مع مدة الاحتفاظ كفترة استرجاع
مدة الاحتفاظ لازم تحسب قد إيه الخطأ ممكن يفضل من غير ما يلاحظه حد. نافذة عشر أيام مش هتساعد في حذف بالغلط اتكتشف بعد شهر. الاحتفاظ بكل نسخة للأبد بيخلق مشكلة مختلفة: التكلفة، وزيادة تعرض البيانات الحساسة، وسياسة حذف غير واضحة. اختار مدة الاحتفاظ بناءً على متطلبات تشغيلية ومتطلبات التعامل مع البيانات محددة.
سمّي نقاط الاسترجاع بسياق مفيد، زي إصدار التطبيق ووقت المهمة المكتملة، من غير ما تحط أسرار. احتفظ بتاريخ كافي يميز الحالة الجيدة من التالفة. قبل التنظيف، اتأكد إزاي النظام المختار بيتعامل مع البيانات المشتركة أو التزايدية؛ حذف نقطة مسماة ممكن ما يقابلش حذف ملف مستقل بسيط.
افصل المهام الناجحة عن البيانات المتحقق منها
أداة النسخ الاحتياطي لما تبلغ عن نجاح، ده بيثبت إن عمليتها اكتملت وفق قواعدها. مش بيثبت تلقائيًا إن كل بيانات التطبيق المهمة اتحددت، أو إن كل بايت مخزن لسه سليم، أو إن سيرفر جديد يقدر يستخدم النتيجة. دي فحوصات مختلفة. ضمّن صحة المستودع ومراجعة التحديد والاسترجاع التمثيلي في خطة التشغيل.
Restic بتوثق فرق بين فحص المستودع الافتراضي والتحقق اللي بيقرأ بيانات الحزم المخزنة. فحص قراءة البيانات الكامل ممكن يستهلك وقت وعرض نطاق أكتر. المثال ده بيوضح نقطة التخطيط: حدد إيه اللي التحقق بيقرأه فعلاً وخصّص ميزانية للشغل. استخدم توثيق الأداة بدل ما تفترض إن كل أمر اسمه check ليه نفس التغطية.
اختبر استرجاع صغير وكامل
تخيل منشور فيه قاعدة بيانات وصور مرفوعة وإعدادات. استرجع التلاتة في بيئة اختبار خاصة، وبعدين افتح مقال وتحقق من مرفقاته. خلّي تكاملات البريد المجدول والدفع والنشر معطلة أثناء التمرين. اختبار ملف نصي عشوائي بس هيفوّت العلاقات اللي بتخلي التطبيق مفيد.
قِس الوقت المطلوب وسجّل أنهي بيانات اعتماد أو إصدارات حزم أو تبعيات خارجية كانت ناقصة. راجع الصلاحيات على الملفات المسترجعة، مش محتواها بس. تمرين الاسترجاع غالبًا بيكتشف إن البيانات موجودة لكن التعليمات أو الوصول المطلوب لاستخدامها ما اتحفظوش جنب خطة التشغيل.
اقرأ النسخ الاحتياطية الاختيارية كخدمة محددة
لما تعدّ SwissOctet، بص على خيار النسخ الاحتياطي بالظبط ومدة الاحتفاظ للعائلة. اسأل أنهي وحدات تخزين وبيانات تطبيق بيغطيها، وهل الاسترجاع ذاتي الخدمة، وإيه اللي بيحصل لما الإعداد الأساسي يتغير. اسم الخيار لوحده مش بيثبت نسخة مستقلة أو مستودع غير قابل للتغيير أو نقطة استرجاع متسقة مع قاعدة البيانات.
استخدم اللقطات في الأماكن اللي تناسب حمل العمل واحتفظ باستراتيجية نسخ احتياطي أوسع للأعطال اللي مش بتغطيها. سجّل مسار استرجاع مستقل للبيانات المهمة، واحمي بيانات الاعتماد اللي تقدر تمحي النسخ، واختبر الإجراء. أقوى اختيار هو اللي بينجو من السيناريو المحدد بتاعك، مش اللي اسمه مطمئن أكتر.
قائمتك العملية.
- حدد فين البيانات القابلة للاسترجاع موجودة.
- اعمل قائمة بالأعطال اللي النسخة لازم تنجو منها.
- استخدم طريقة اتساق مدعومة من التطبيق.
- اختار مدة الاحتفاظ لنافذة الاكتشاف.
- احمي صلاحيات الحذف بشكل منفصل.
- استرجع تطبيق كامل في بيئة معزولة.
التفاصيل اللي تفرق.
هل اللقطة مش نسخة احتياطية أبدًا؟+
بعض تنفيذات اللقطات هي نسخ احتياطية. الفرق المفيد هو اعتمادها على التخزين ومدة الاحتفاظ ونموذج الوصول والاسترجاع المتجرب، مش الاسم لوحده.
هل فحص سلامة ناجح بيثبت إن التطبيق هيشتغل؟+
بيثبت بس اللي الفحص ده بيغطيه. اختبر استرجاع التطبيق والإعدادات والصلاحيات وعلاقات البيانات بشكل منفصل.
هل أحتفظ بالنسخة الاحتياطية على نفس السيرفر؟+
نسخة على نفس السيرفر ممكن تساعد في أخطاء محدودة لكن بتشارك أعطال مهمة. البيانات المهمة محتاجة مسار استرجاع خارج حدود الفشل اللي ناوي تنجو منها.
اذهب إلى المصدر.
تدعم هذه المراجع المفاهيم التقنية في هذا الدليل. اتبع الوثائق الحالية قبل تغيير نظام إنتاجي.
- Amazon EBS: اللقطات docs.aws.amazon.com
- PostgreSQL: الأرشفة المستمرة والاسترجاع اللحظي www.postgresql.org
- Restic: التعامل مع المستودعات وفحوصات السلامة restic.readthedocs.io
إرشاد تحريري من SwissOctet. الأمثلة توضيحية. يجب التحقق من مواصفات الخدمة والخيارات المتاحة والشروط التعاقدية بشكل منفصل.