استراتيجية عملية للنسخ الاحتياطي لـ VPS (قاعدة 3-2-1)
بقلم فريق ApexVPS • آخر تحديث: يوليو 2026 • 7 دقائق قراءة
إن استراتيجية النسخ الاحتياطي الموثوقة لـ VPS هي الفرق بين استرداد خلال خمس دقائق وأسبوع سيء للغاية. تفشل الخوادم، وتتلف الأقراص، وتسوء عمليات النشر، ويمكن لأمر واحد مكتوب بشكل خاطئ أن يمسح مجلدًا. يشير مركز تعلم Cloudflare ومعظم فرق البنية التحتية إلى نفس الانضباط البسيط: قاعدة 3-2-1. يوضح هذا الدليل كيفية تطبيقه على خادم افتراضي حقيقي، والأدوات التي يجب استخدامها، وكيفية الجدولة والاختبار لكل شيء بحيث يعمل الاسترداد فعليًا عندما تحتاجه.
ما معنى قاعدة 3-2-1
قاعدة 3-2-1 هي مبدأ نسخ احتياطي قديم يظل صحيحًا أينما كان خادمك:
- 3 نسخ من بياناتك — النسخة الحية بالإضافة إلى نسختين احتياطيتين على الأقل.
- وسائط أو أنظمة تخزين مختلفة — بحيث لا يمكن لفشل واحد أن يدمر النسختين معًا.
- نسخة واحدة خارج الموقع — منفصلة ماديًا أو منطقيًا عن الجهاز الذي تحميه.
على VPS، عادةً ما يعني هذا الخادم قيد التشغيل، ومستودع النسخ الاحتياطي المحلي، ونسخة مشفرة تُدفع إلى تخزين بعيد في موقع مختلف. الهدف هو التكرار دون نقطة فشل مشتركة واحدة.
ماذا تنسخ احتياطيًا على VPS
نسخ القرص كاملاً قطعة بقطعة مضيعة للوقت وغير فعال. خطة النسخ الاحتياطي الجيدة تستهدف الأشياء الثلاثة التي يصعب حقًا إعادة إنشائها.
بيانات التطبيق والملفات
الملفات المرفوعة، جذور المواقع، وحدات التخزين للحاويات، وأي شيء يولده المستخدمون. المسارات النموذجية تشمل /var/www و/srv و/home ودليل Docker volume. إذا كنت تستضيف تطبيقات بنفسك مثل خادم ملفات أو wiki، فهنا توجد محتواك الذي لا يمكن استبداله — راجع دليلنا حول تشغيل VPS للاستضافة الذاتية لمعرفة كيفية ترتيب تلك الأدلة عادةً.
قواعد البيانات
لا تنسخ أبدًا ملفات قاعدة البيانات الحية أثناء تشغيل الخدمة — قد تحصل على حالة تالفة أو غير مكتملة. بدلاً من ذلك، صدّر تفريغًا متسقًا. بالنسبة لـ MySQL أو MariaDB:
mysqldump --single-transaction --routines --triggers \
-u backup -p mydatabase > /srv/backups/mydatabase.sql
الخيار --single-transaction يعطي لقطة متسقة لجداول InnoDB دون قفلها. بالنسبة لـ PostgreSQL، استخدم pg_dump بدلاً من ذلك:
pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump
تكوين النظام والخدمات
الملفات التي تجعل خادمك خاصًا بك: /etc (nginx، وحدات systemd، cron، إعدادات SSH)، قوائم الحزم، شهادات TLS، وقواعد جدار الحماية. إعادة بناء هذه من الذاكرة بعد الفشل هي بالضبط العمل المضني الذي تهدف النسخ الاحتياطية إلى تجنبه.
اختيار أدوات النسخ الاحتياطي
ثلاث أدوات تغطي معظم حالات VPS. اختر بناءً على مدى تقديرك لإزالة التكرار والتشفير.
restic — لقطات مشفرة ومزيلة للتكرار
restic أداة نسخ احتياطي حديثة ذات ملف ثنائي واحد تشفر وتزيل التكرار افتراضيًا. قم بتهيئة مستودع مرة واحدة، ثم قم بتشغيل النسخ الاحتياطية عليه:
# One-time: create an encrypted repository
restic init --repo /srv/backups/restic
# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql
# List what you have
restic -r /srv/backups/restic snapshots
BorgBackup — أرشيفات مزيلة للتكرار
يقدم BorgBackup إزالة تكرار وضغطًا مماثلين مع سير عمل مختلف قليلاً:
borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www
rsync — مزامنة ملفات بسيطة
عندما تحتاج فقط إلى مرآة سريعة للملفات إلى مضيف آخر، فإن rsync عبر SSH لا يُضاهى:
rsync -aAX --delete /var/www/ [email protected]:/backups/www/
خيارات -aAX تحافظ على الأذونات وACLs والسمات الموسعة؛ --delete يحافظ على المرآة متزامنة مع المصدر. rsync وحده لا يحتفظ بسجل الإصدارات، ولهذا يدمجه العديد من الفرق مع restic أو borg.
أتمتة الجدول باستخدام cron
النسخة الاحتياطية التي عليك تذكر تشغيلها هي نسخة لن تحدث. ضع الخطوات في نص برمجي، اجعله قابلًا للتنفيذ، وجدوله مع cron. حرر crontab الخاص بك باستخدام:
crontab -e
ثم أضف سطورًا مثل هذه:
# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh
# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh
سجل المخرجات، واجعل البرنامج النصي يخرج برمز غير صفري عند الفشل حتى تتمكن من ربطه بـ ميزات المراقبة والتنبيه المضمونة في خطتك. الفشل الصامت في النسخ الاحتياطي أسوأ من عدم وجود نسخة احتياطية، لأنه يعطي إحساسًا زائفًا بالأمان.
احتفظ بنسخة خارج الموقع حقيقية
الرقم "1" في 3-2-1 هو الجزء الذي يتجاهله معظم الناس. النسخة الاحتياطية الموجودة على نفس الخادم الذي تحميه تختفي مع هذا الخادم. ادفع نسخة مشفرة إلى مكان مستقل — تخزين كائنات، أو صندوق SFTP بعيد، أو مزود آخر. يكتب restic وborg مباشرة إلى مستودعات بعيدة، على سبيل المثال عبر SFTP:
restic -r sftp:[email protected]:/backups/restic backup /var/www
نظرًا لأن restic وborg يشفران قبل مغادرة البيانات لـ VPS الخاص بك، فإن المضيف البعيد لا يرى نصك الصريح أبدًا. قم بتقليم اللقطات القديمة وفقًا لسياسة حتى لا ينمو التخزين إلى الأبد:
restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
اختبر استعادتك — في كل مرة
النسخة الاحتياطية غير المختبرة مجرد إشاعة. جدول استعادة دوريًا في مكان مؤقت وتأكد من عودة الملفات وقواعد البيانات كما هي:
# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test
# Verify repository integrity
restic -r /srv/backups/restic check
# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql
إذا نجح الاستعادة وتطابقت البيانات، فلديك استراتيجية. وإذا لم تنجح، فقد تعلمت ذلك بعد ظهر يوم الثلاثاء بدلاً من أثناء انقطاع حقيقي.
اللقطات طبقة واحدة، وليست الاستراتيجية كاملة
تشمل كل خطة من خطط ApexVPS نسخًا احتياطية تلقائية — لقطات يومية على Starter Pro ولقطات كل ساعة على Business — وهي مفيدة حقًا للتراجع السريع بعد نشر سيئ أو حذف عرضي. لكن كن صريحًا مع نفسك بشأن ما هي عليه: طبقة أولى مريحة تعيش على منصتنا. فهي ليست بديلاً عن النسخة الخارجية المستقلة التي تم التحقق منها والتي تتطلبها قاعدة 3-2-1. تعامل مع لقطات المنصة كنقطة استعادة محلية سريعة، وقم بتشغيل مهمة restic أو borg الخاصة بك لتلبية جزأي النسخ الخارجي والاستعادة المختبرة من القاعدة. هذا النهج متعدد الطبقات هو ما يفصل الإعداد المتفائل عن الإعداد المرن، سواء كنت تستضيف تطبيقات مثل Nextcloud أو تدير قاعدة بيانات إنتاجية.
قائمة التحقق لاستراتيجية النسخ الاحتياطي لخادم VPS
بتجميع العناصر معًا، تبدو استراتيجية النسخ الاحتياطي الكاملة لخادم افتراضي كما يلي. اعمل عليها مرة واحدة، وقم ببرمجتها، واترك cron يتابعها:
- حدد ما هو مهم — ملفات التطبيق، وقواعد البيانات المصدّرة، والإعدادات تحت
/etc. - اختر أداة — restic أو BorgBackup لنسخ احتياطية مشفرة ومزالة التكرار ومصحوبة بإصدارات؛ وrsync للمرايا البسيطة.
- قم بتصدير قواعد البيانات بشكل متسق —
mysqldump --single-transactionأوpg_dump، ولا تنسخ أبدًا الملفات الحية مباشرة. - قم بأتمتة ذلك — جدولة البرنامج النصي مع cron وتنبيه عند أي خروج غير صفري.
- ادفع نسخة واحدة خارج الموقع — مشفرة، على تخزين مستقل، مع سياسة استبقاء معقولة.
- اختبر الاستعادة بانتظام — استعد إلى موقع مؤقت وتأكد من سلامة البيانات.
افعل هذه الأمور الستة وتتوقف قاعدة 3-2-1 عن كونها نظرية وتصبح عادة يمكن للبنية التحتية الاعتماد عليها. ساعة الإعداد الأولية ضئيلة بالمقارنة مع تكلفة اكتشاف، أثناء الحادث، أن نسختك الوحيدة كانت على القرص الذي مات للتو.
الأسئلة الشائعة
هل تعتبر لقطات المزود استراتيجية نسخ احتياطي؟
اللقطات طبقة مفيدة واحدة، ولكنها ليست استراتيجية كاملة. لقطاتنا اليومية والساعية تحمي من معظم الأخطاء قصيرة المدى، لكنها تعيش على نفس منصة خادمك. لا تزال استراتيجية النسخ الاحتياطي الكاملة 3-2-1 تحتاج إلى نسخة خارجية مستقلة تتحكم فيها واستعادات اختبرتها فعليًا.
كم مرة يجب أن أقوم بنسخ احتياطي لخادم VPS؟
طابق التكرار مع مقدار البيانات الذي يمكنك تحمل فقدانه. يمكن نسخ الملفات الثابتة والإعدادات احتياطيًا يوميًا، بينما غالبًا ما تستحق قواعد البيانات النشطة نسخًا كل ساعة. استخدم cron لأتمتة الجدول الزمني حتى لا يعتمد النسخ الاحتياطي على تذكرك.
ما هي أفضل أداة للنسخ الاحتياطي لخادم VPS؟
كل من restic و BorgBackup ممتازان: يقومان بإزالة التكرار وضغط وتشفير النسخ الاحتياطية، ويدعمان مستودعات خارج الموقع. rsync جيد لمرايا الملفات البسيطة، وmysqldump أو pg_dump يتعاملان مع تصدير قواعد البيانات. تجمع العديد من الإعدادات بين تصدير قاعدة البيانات وتشغيل restic أو borg.
كيف أعرف أن النسخ الاحتياطية تعمل بالفعل؟
اختبر الاستعادة وفقًا لجدول زمني. استعد إلى دليل مؤقت، وتحقق من محتويات الملفات والمجاميع الاختبارية، واستورد تصدير قاعدة البيانات إلى قاعدة بيانات مؤقتة. النسخة الاحتياطية التي لم تستعدها أبدًا هي مجرد تخمين متفائل، وليست خطة استرداد.