تخطيط النسخ الاحتياطي والاسترداد: احمِ ملفاتك
أنشئ خطة شاملة للنسخ الاحتياطي والاسترداد. أهداف RTO و RPO وإجراءات الاختبار واستراتيجيات التعافي من الكوارث.
خطة النسخ الاحتياطي والاسترداد تجيب عن سؤالين رقميين: RPO (كمية البيانات التي يمكنك تحمّل خسارتها، مُقاسةً بالوقت) وRTO (المدة التي يمكنك تحمّل التوقف عنها). حدِّد هذين الرقمين لكل حمل عمل، ثم صمِّم الحل بالعكس. قاعدة بيانات بـ RPO خمس دقائق تحتاج شحن WAL مستمراً؛ تقرير تسويقي أسبوعي بـ RPO 24 ساعة يحتاج مهمة ليلية واحدة. أضِف قاعدة 3-2-1 — ثلاث نسخ على نوعين من الوسائط، مع نسخة واحدة خارج الموقع — واختبر عمليات الاسترداد ربع سنوياً. معظم قصص "لدينا نسخ احتياطية" تنتهي بكارثة لأن أحداً لم يتدرب على الاسترداد قط.
RPO وRTO: الأرقام الأساسية
RPO (هدف نقطة الاسترداد) = الحد الأقصى المقبول لفقدان البيانات بالوقت. RTO (هدف وقت الاسترداد) = الحد الأقصى المقبول للتوقف.
أمثلة حسب حمل العمل:
- قاعدة بيانات إنتاجية لموقع تجارة إلكترونية: RPO 5 دقائق، RTO ساعة واحدة
- رفع ملفات للعملاء: RPO 15 دقيقة، RTO ساعتان
- خادم ملفات داخلي: RPO 24 ساعة، RTO 8 ساعات
- أرشيف البريد الإلكتروني: RPO 24 ساعة، RTO 48 ساعة
- تحليلات التسويق: RPO 24 ساعة، RTO 72 ساعة
RPO/RTO أضيق يكلف أكثر. خمس دقائق RPO تعني نسخاً متماثلاً مستمراً (بنية تحتية مكلفة)؛ 24 ساعة RPO تعني مهمة ليلية واحدة (رخيصة). لا تُعقِّد الحل — ليس كل حمل عمل يحتاج نظام استعداد فوري.
قاعدة 3-2-1 لا تزال صالحة
ثلاث نسخ من البيانات، على نوعين مختلفين من التخزين، مع نسخة واحدة خارج الموقع. قاعدة 3-2-1 سابقة للسحابة وما زالت سارية:
- الأساسية: تخزين الإنتاج (S3، EBS، قرص PostgreSQL)
- الثانوية: نسخة احتياطية على وسيط مختلف أو منطقة مختلفة (دلو S3 آخر مع النسخ المتماثل، Glacier)
- الثالثية: خارج الموقع، ومن المفضل أن تكون مزوداً مختلفاً أو معزولاً (Backblaze B2، شريط على الموقع، أقراص فيزيائية في خزنة)
نقطة تنويع المزود مهمة. حساب AWS جذر مخترق يمكنه حذف جميع نسخك الاحتياطية على AWS. نسخة ثانوية في Backblaze أو Wasabi أو على الموقع تنجو من هذا السيناريو. للشركات بإيرادات دون 50 مليون دولار، نسخة عند مزود ثانٍ تضيف نحو 50-200 دولار شهرياً وتؤمّن ضد المشكلات الكارثية على مستوى المستأجر.
كامل وتدريجي وكامل اصطناعي
ثلاث استراتيجيات للنسخ الاحتياطي:
- كامل: نسخ كل شيء في كل مرة. بسيط، الاسترداد سريع (ملف واحد)، التخزين ثقيل.
- تدريجي: نسخ ما تغيّر منذ آخر نسخة احتياطية فقط. فعّال في التخزين، الاسترداد يتطلب النسخة الكاملة + كل النسخ التدريجية.
- كامل اصطناعي: دمج على الخادم للنسخة الكاملة والتدريجية في نسخة كاملة افتراضية جديدة. استرداد سريع من أي نقطة.
أدوات النسخ الاحتياطي الحديثة (Veeam وRubrik وrestic مع الحذف التلقائي وBorgBackup) تستخدم التدريجي الدائم مع النسخ الكاملة الاصطناعية تحت الغطاء. النمط: تدريجي ليلي، كامل اصطناعي أسبوعي، احتفظ بـ 30 نسخة يومية + 12 شهرية + 7 سنوية (دوران الجد-الأب-الابن).
لخادم ملفات بـ 2 تيرابايت ومعدل تغيير يومي 5%، التدريجي الدائم يخزن نحو 3-5 تيرابايت لمدة احتفاظ سنة — مقابل أكثر من 700 تيرابايت لو اخترت نسخة كاملة كل ليلة.
التشفير قبل المغادرة
لا ينبغي للنسخ الاحتياطية أن تنتقل أو تُخزَّن دون تشفير. التشفير من جانب العميل باستخدام AES-256-GCM (الافتراضي في restic وBorg وDuplicacy وVeeam وغيرها) يضمن أن مضيف النسخ الاحتياطية لا يرى النص الصريح قط.
إدارة المفاتيح أهم من اختيار الخوارزمية. نسخة احتياطية مشفرة بمفتاح مخزَّن في نفس حساب AWS الذي يحتوي النسخة الاحتياطية مجرد مسرحية أمنية — مهاجم لديه وصول IAM يحصل على الاثنين. خزِّن المفاتيح في:
- AWS KMS بمفتاح حساب منفصل (فك تشفير عبر الحسابات)
- HashiCorp Vault في بيئة خارج النطاق
- وحدة أمان الأجهزة (YubiKey أو HSM) للمفتاح الجذر
- نسخة ورقية مطبوعة ومختومة للمفاتيح الحرجة فعلاً
دوِّر بانتظام (سنوياً)، سجِّل كل استخدام، واختبر الاسترداد بمفتاح مُدار قبل أن يصبح التدوير سارياً في الإنتاج.
الثبات: الجواب على برامج الفدية
هجمات برامج الفدية في 2025 تستهدف النسخ الاحتياطية أولاً في الغالب — تُشفِّر بيانات الإنتاج، ثم تحذف أو تُشفِّر النسخ الاحتياطية لمنع الاسترداد. النسخ الاحتياطية الثابتة (غير القابلة للتعديل) تُحبط هذا.
التطبيقات:
- S3 Object Lock (وضع الامتثال): حتى الجذر لا يستطيع الحذف خلال فترة الاحتفاظ
- تخزين Azure Blob الثابت: مماثل، مُطبَّق على مستوى الحاوية
- مستودع Veeam Hardened Linux: للإلحاق فقط، SSH فقط، بدون API حذف
- شريط فيزيائي في خزنة: العزل المطلق
للبيانات الحرجة للأعمال، نسخة احتياطية واحدة على الأقل يجب أن تكون ثابتة لفترة الاحتفاظ. التكلفة التدريجية صفر في الغالب — كنت ستحتفظ بها على أي حال. القيمة عند وقوع هجوم برامج فدية لا تُقدَّر.
الاختبار: الجزء غير الاختياري
نسخة احتياطية لم تسترد منها قط ليست نسخة احتياطية؛ إنها أمل. جدول الاختبار حسب الأولوية:
- الطبقة الأولى (حرجة للمهمة): تدريب استرداد كامل ربع سنوياً، استرداد ملف عشوائي شهرياً
- الطبقة الثانية (مهمة للأعمال): تدريب استرداد كامل نصف سنوي، استرداد ملف عشوائي ربع سنوياً
- الطبقة الثالثة (عادية): تدريب استرداد كامل سنوياً، استرداد ملف عشوائي ربع سنوياً
سجِّل في الاختبار:
- كم استغرق الاسترداد (قارن بـ RTO)
- هل تطابقت البيانات مع حالة الإنتاج (بصمات تحقق مقابل نقطة معروفة)
- هل فشل استرداد أي أذونات أو تكوينات
- ماذا انكسر وكيف جرى إصلاحه
الشركات التي تتجاوز الاختبار تكتشف النسخ الاحتياطية التالفة أثناء الحوادث الفعلية، وهو أغلى وقت تتعلم فيه أي شيء.
قواعد البيانات تحتاج خطة خاصة بها
الملفات وقواعد البيانات تُنسخ احتياطياً بطريقة مختلفة. دليل .pgdata منسوخ في منتصف عملية تعديل يكون تالفاً. استخدم الأدوات الأصلية:
- PostgreSQL:
pg_basebackup+ أرشفة WAL لـ PITR، وpg_dumpللمنطقي - MySQL: Percona XtraBackup للفيزيائي الساخن، و
mysqldumpللمنطقي - MongoDB:
mongodump، مجموعات النسخ المتماثل مع ثانويات متأخرة - Microsoft SQL Server: نسخ احتياطي أصلي بـ
BACKUP DATABASE، وشحن السجل لـ PITR
لقاعدة بيانات PostgreSQL بـ 500 جيجابايت وRPO خمس دقائق، نسخ احتياطي أساسي ليلي + أرشفة WAL مستمرة إلى S3 يمنحك استرداداً للوقت الفعلي لأي ثانية خلال آخر 30 يوماً. وقت الاسترداد: سحب النسخة الأساسية (30 دقيقة)، إعادة تشغيل WAL حتى الوقت المستهدف (5-30 دقيقة). RTO ضيق يعني نسخة نشطة دافئة جاهزة للترقية.
لقطات متسقة مع التطبيق
لقطات نظام الملفات (ZFS وBtrfs وAWS EBS وأقراص Azure المُدارة وقرص GCP الثابت) تجمِّد نقطة زمنية على مستوى الكتلة. لقواعد البيانات، ادمج مع إيقاف التطبيق مؤقتاً:
pg_start_backup('label')(PostgreSQL) أوFLUSH TABLES WITH READ LOCK(MySQL)- التقط اللقطة
pg_stop_backup()أو أطلق القفل
اللقطة متسقة مع التطبيق — قابلة للاستخدام في الاسترداد بدون استرداد من الأعطال. AWS Backup وAzure Backup وGoogle Cloud Backup تُؤتمت هذا النمط لقواعد البيانات الشائعة.
توزيع أرشيفات النسخ الاحتياطية على أطراف ثالثة
عندما تحتاج النسخ الاحتياطية إلى الوصول لأطراف خارجية — مدققين أو جهات تنظيمية أو أوصياء خلفاء — فإن عملية النقل نفسها تحتاج عناية. FTP قديم؛ مرفقات البريد الإلكتروني تصطدم بحدود الحجم؛ تسليم محركات USB بطيء.
نقل الملفات المشفَّر من طرف إلى طرف يتعامل مع توزيع النسخ الاحتياطية العرضي بكفاءة. HexaTransfer ينقل ملفات حتى 10 جيجابايت مع تشفير AES-256-GCM من جانب العميل ورابط لمرة واحدة. مناسب لإرسال لقطة قاعدة بيانات إلى مدقق دون منحه وصولاً إلى دلاء S3 الخاصة بك.
التوثيق جزء من النسخة الاحتياطية
أفضل نسخة احتياطية في العالم عديمة الفائدة إذا كان الشخص القادر على استردادها في إجازة ولا أحد غيره يعرف الطريقة. وثِّق:
- ما يُنسخ احتياطياً وما لا يُنسخ (استثناءات صريحة)
- الجدول والاحتفاظ لكل حمل عمل
- إدارة المفاتيح والوصول
- كتيبات تشغيل الاسترداد بأوامر خطوة خطوة
- قائمة جهات الاتصال (دعم المورد، المناوب)
- نتائج الاختبار وتواريخه
اطبع نسخة. خزِّن نسخة في الخزنة الفيزيائية مع مفاتيح الطوارئ. إذا كان دليل تشغيل نسخك الاحتياطية يعيش فقط في صفحة Confluence تُخدَّم من نفس البنية التحتية التي انهارت للتو، فلديك مشكلة. الورق لا يزال يعمل حين لا يعمل شيء آخر.
حدِّد RPO/RTO، طبِّق 3-2-1 مع الثبات، شفِّر من جانب العميل، اختبر ربع سنوياً، وثِّق بدقة متواصلة. نجاح النسخ الاحتياطي 10% تقنية و90% انضباط.
جرّبها على hexatransfer.com — مجاناً، بدون حساب، حتى 10 جيجابايت.
أرسل ملفات كبيرة بأمان مع تشفير من طرف إلى طرف
انقل ملفات حتى 10 جيجابايت مجاناً مع تشفير من طرف إلى طرف. لا حاجة لحساب. يتم تشفير ملفاتك في متصفحك قبل الرفع — لا أحد آخر يستطيع قراءتها.
إرسال ملف