لماذا تؤتمت نسخك الاحتياطية باستخدام Restic
غالبًا ما يستضيف خادم VPS بيانات لا يمكن تعويضها: قواعد بيانات، وأقراص تخزين Docker (volumes)، وملفات تهيئة. يلبّي Restic ثلاثة متطلبات أساسية لاستراتيجية جيدة: التشفير (AES-256، فالمستودع غير قابل للاستخدام دون كلمة المرور)، وإزالة التكرار (لا تُخزَّن الكتل المتطابقة إلا مرة واحدة، ما يقلّص الحجم والتكلفة تقليصًا كبيرًا)، ودعم واجهات تخزين متنوّعة (S3 وBackblaze B2 وSFTP والتخزين المحلي). واستضافة Restic ذاتيًا على الخادم بدلًا من الاعتماد على خدمة نسخ احتياطي مُدارة تمنحك تحكّمًا كاملًا في التشفير: يبقى المفتاح لديك، ولا يرى مزوّد التخزين سوى كتل بيانات مبهمة. وهذا هو أساس استراتيجية 3-2-1 جادّة.
ما الذي يقدّمه لك Restic
- تشفير AES-256 من جهة العميل: لا ترى واجهة التخزين سوى بيانات غير قابلة للقراءة.
- إزالة التكرار على مستوى الكتل تقلّص كثيرًا حجم النسخ الاحتياطية المتتالية وتكلفتها.
- لقطات تزايدية سريعة: لا تُنقَل سوى الكتل الجديدة في كل تشغيلة.
- واجهات تخزين متعددة (S3 وBackblaze B2 وSFTP وrest-server والتخزين المحلي) دون تغيير سير العمل.
- استعادة دقيقة: ملف واحد أو مجلد أو لقطة كاملة عبر
restic restore. - سياسة احتفاظ مؤتمتة عبر
forget --prune(الاحتفاظ بـ N نسخة يومية، وM نسخة أسبوعية...).
المتطلبات المسبقة لهذا النشر
يتّسم Restic بقلّة استهلاك الموارد: فهو يعمل على أي خادم VPS، بما في ذلك 1 vCPU و1 غيغابايت من RAM، مع استهلاك إزالة التكرار قدرًا يسيرًا من الذاكرة يتناسب مع حجم المستودع. تحتاج إلى الملف التنفيذي restic (حزمة التوزيعة أو تنزيل مباشر)، وواجهة تخزين وِجهة بعيدة (سلّة (bucket) متوافقة مع S3 لدى مزوّد، أو خادم آخر عبر SFTP) وبيانات اعتماده. ولا يلزم Docker هنا: فـ Restic أداة تعمل من سطر الأوامر. جهّز cron أو مؤقّت systemd للأتمتة، وموضعًا آمنًا خارج الخادم لحفظ كلمة مرور المستودع.
إعداد نسخ Restic الاحتياطية المؤتمتة
تثبيت Restic وتجهيز متغيّرات البيئة
ثبّت الملف التنفيذي (apt install restic ثم restic self-update). أنشئ ملف /root/.restic-env يحتوي على RESTIC_REPOSITORY وRESTIC_PASSWORD ومفاتيح الوصول إلى واجهة التخزين (AWS_ACCESS_KEY_ID وAWS_SECRET_ACCESS_KEY لسلّة متوافقة مع S3). وقيّد صلاحياته بـ chmod 600.
تهيئة المستودع المشفّر
حمّل البيئة ثم نفّذ restic init. يُنشئ هذا الأمر بنية المستودع ويُحكِم التشفير بكلمة مرورك. احفظ هذه الكلمة في مكان آخر غير الخادم: فبدونها لا يمكن إجراء أي استعادة.
تشغيل أول نسخة احتياطية
انسخ أدلّتك الحسّاسة احتياطيًا، على سبيل المثال restic backup /etc /var/www /opt/docker-data. أما لقاعدة بيانات، فأنشئ نسخة تفريغ (dump) في ملف ثم ضمّنه، أو مرّر التفريغ عبر الأنبوب إلى restic backup --stdin.
تحديد سياسة احتفاظ
تجنّب التراكم اللامتناهي عبر restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune. تحذف مرحلة --prune فعليًا الكتل التي أصبحت يتيمة وتحرّر المساحة في واجهة التخزين.
الأتمتة عبر cron أو مؤقّت systemd
أنشئ سكربت backup.sh يستورد .restic-env، ويشغّل restic backup ثم restic forget --prune، ويسجّل النتيجة. جدوِله يوميًا، على سبيل المثال 0 3 * * * /root/backup.sh في crontab.
اختبار عملية استعادة والتحقّق من السلامة
النسخة الاحتياطية غير المُختبَرة وهمٌ. اعرض اللقطات عبر restic snapshots، واستعِد إلى مجلد مؤقّت (restic restore latest --target /tmp/test-restore)، وشغّل restic check دوريًا للتحقّق من سلامة المستودع.
احمِ نسخك الاحتياطية من برامج الفدية (ransomware) بتفعيل وضع "append-only" في واجهة التخزين: انشر rest-server بعيدًا مع الخيار --append-only، أو استخدم سلّة S3 مع سياسة IAM تمنع عمليات الحذف. وبذلك، حتى لو اخترق مهاجمٌ خادمك وحصل على بيانات الاعتماد، فلن يتمكّن من محو لقطاتك الحالية ولا تشفيرها. وامزج ذلك بتشغيل restic forget --prune من جهاز منفصل يملك وحده صلاحيات الحذف.
