الطريقة الموثوقة لعمل نسخ احتياطي لخادم Linux في 2026 هي قاعدة 3-2-1: احتفظ بثلاث نسخ من بياناتك، على نوعين من التخزين، مع نسخة واحدة خارج الموقع، مشفّرة ومؤتمتة كي لا تضطر أبداً إلى تذكّرها. بالنسبة إلى خادم VPS واحد، فإن أقصر مسار يعمل فعلاً هو restic الذي يرسل لقطات ليلية مشفّرة ومُزالة التكرار إلى تخزين كائنات رخيص مثل Backblaze B2 أو Hetzner Storage Box، مع تفريغ لقاعدة البيانات يجري أولاً. الجزء الذي يتخطاه الجميع تقريباً، والجزء الوحيد الذي يهمّ يوم يتعطّل القرص، هو اختبار الاستعادة. يشرح هذا الدليل الأمر بأكمله من البداية إلى النهاية: اختر أداة، وأرسل اللقطات خارج الموقع، وتعامل مع قواعد البيانات وDocker، وأتمِت العملية، وأثبِت أنها تستعيد.
ما الذي يعنيه فعلاً «عمل نسخ احتياطي لخادم Linux»
النسخة الاحتياطية ليست لقطة (snapshot). لقطة VPS اليومية لدى مزوّدك تعيش عند المزوّد نفسه، وغالباً على الرف نفسه، وتختفي إذا عُلّق حسابك أو مرّت المنطقة بيوم سيّئ. النسخة الاحتياطية الحقيقية هي نسخة منفصلة وخارج الموقع تتحكم أنت بها. هناك طبقتان تستحقان الحماية: بياناتك (قواعد البيانات، و/home، ومجلدات تخزين التطبيقات، وإعدادات /etc) و، اختيارياً، صورة نظام كاملة للاستعادة على المعدن العاري (bare-metal). بالنسبة إلى معظم إعدادات الخادم الواحد لا تحتاج إلى صورة قرص كاملة — فإعادة بناء VPS مع استعادة بياناتك فوقه أسرع وأرخص. ما يجب ألّا تفقده أبداً هو البيانات، وذلك ما يستهدفه الإعداد أدناه. المبدأ الموجِّه عبر كل دليل موثوق لعام 2026 هو نفسه قاعدة 3-2-1: ثلاث نسخ، ونوعان من الوسائط، ونسخة واحدة خارج الموقع. وكل ما عدا ذلك تفصيل تنفيذي.
قاعدة 3-2-1 مطبَّقة على خادم VPS واحد
على جهاز واحد تنطبق القاعدة بوضوح. النسخة 1 هي بياناتك الحيّة على قرص الخادم. النسخة 2 هي لقطة محلية على وحدة تخزين ثانية أو لقطة تخزين الكتل (block-storage) لدى مزوّدك — فورية في الاستعادة، وعديمة الفائدة إذا مات الحساب. النسخة 3 هي نسخة مشفّرة خارج الموقع في تخزين الكائنات أو في صندوق تخزين لدى شركة ودولة مختلفتين. تلك النسخة الثالثة هي التي تنجو من هجوم فدية، أو من rm -rf بيد مرتعشة، أو من مزوّد يغلق حسابك دون إشعار. شفّرها قبل أن تغادر الجهاز كي لا يرى مزوّد التخزين النص الصريح أبداً، وأتمِتها كي تعمل سواء تذكّرت أم لا. إن كنت ستفعل شيئاً واحداً فقط بعد قراءة هذا، فأنشئ النسخة 3. نسختان محليتان دون نسخة خارج الموقع هما الطريقة الأكثر شيوعاً التي يكتشف بها الناس، بعد فوات الأوان، أنه لم يكن لديهم نسخ احتياطي على الإطلاق.
أي أداة نسخ احتياطي لـ Linux ينبغي أن تستخدم؟
يتقلّص المجال إلى حفنة من الأدوات، والاختيار الصحيح يعتمد على ما إذا كنت تريد مزامنة ملفات بسيطة أم لقطات مشفّرة ومُزالة التكرار وأصلية للسحابة. بالنسبة إلى VPS يكون هدفه خارج الموقع تخزين كائنات، فإن restic هو الخيار الافتراضي العملي: فهو يشفّر ويزيل التكرار بحكم التصميم ويتواصل مع S3 وBackblaze B2 وAzure وGoogle Cloud وSFTP دون أدوات إضافية. أما BorgBackup فهو أقرب منافس له، بضغط وإزالة تكرار ممتازين، لكنه يحتاج إلى هدف يفهم Borg (SSH أو صندوق تخزين) بدلاً من S3 الخام.
| الأداة | التشفير | إزالة التكرار | الهدف خارج الموقع | الأفضل لـ |
|---|---|---|---|---|
| restic | مدمج (AES) | نعم | S3, B2, Azure, GCS, SFTP | VPS ← تخزين كائنات |
| BorgBackup | مدمج (AES-256) | نعم | SSH / صندوق تخزين | خوادم بمضيف نسخ احتياطي SSH |
| rsync | لا (استخدم نقل SSH) | لا | أي هدف SSH/NAS | مرايا ملفات بسيطة |
| Timeshift | لا | لقطات | محلي / القرص نفسه | التراجع عن النظام بأسلوب سطح المكتب |
| Veeam / Bacula | نعم | نعم | مستودعات مؤسسية | الأساطيل، والمعدن العاري، والامتثال |
لا يزال rsync مثالياً لعمل مرآة سريعة إلى NAS، لكنه وحده لا يمتلك تشفيراً ولا سجلّاً تاريخياً — فخطأ الأمس يستبدل النسخة الجيدة لليوم. بالنسبة إلى خادم واحد يُنسَخ احتياطياً إلى السحابة، يفوز restic بأقل عدد من الأجزاء المتحركة.
أسرع إعداد موثوق: restic إلى تخزين كائنات خارج الموقع
إليك طبقة «خارج الموقع» بأكملها لخادم VPS يعمل بـ Ubuntu أو Debian. أنشئ مجموعة (bucket) في Backblaze B2 بمفتاح تطبيق، ثم ثبّت وهيّئ مستودع restic مشفّر:
sudo apt install restic # or: dnf install restic
export RESTIC_REPOSITORY="s3:s3.us-west-004.backblazeb2.com/your-bucket"
export AWS_ACCESS_KEY_ID="<b2-keyID>"
export AWS_SECRET_ACCESS_KEY="<b2-applicationKey>"
export RESTIC_PASSWORD="<a-long-random-passphrase>" # store this OFF the server
restic init
ثم أمر واحد ينسخ احتياطياً مساراتك المهمة، مشفّرة ومُزالة التكرار قبل أن يغادر أي شيء الجهاز:
restic backup /etc /home /var/www /srv --exclude /var/www/cache
شغّله مرتين وسينتهي التشغيل الثاني في ثوانٍ — فـ restic لا يرفع سوى القطع المتغيّرة. احفظ RESTIC_PASSWORD في مكان خارج الخادم (مدير كلمات مرور)؛ فبدونه يتعذّر استرجاع المستودع بحكم التصميم، وهي بالضبط الخاصية التي تجعله آمناً في سحابة شخص آخر. هذا هو النمط الذي نلجأ إليه في بنيتنا التحتية: نُشغّل TechRiseUps عبر WaseerHost، ومستودع مشفّر خارج الموقع كهذا هو الحاجز الأخير خلف كل جهاز.
لا تنسَ قواعد البيانات ووحدات تخزين Docker
هنا تفشل معظم النسخ الاحتياطية على مستوى الملفات بصمت. فنسخ دليل بيانات قاعدة بيانات حيّة أثناء الكتابة عليها يُنتج ملفاً تالفاً غير قابل للاستعادة. فرّغ قاعدة البيانات إلى ملف مسطّح أولاً، ثم دع restic يلتقط التفريغ. بالنسبة إلى Postgres، شغّل pg_dump (أو pg_dumpall لكل قاعدة بيانات والأدوار)؛ وبالنسبة إلى MySQL أو MariaDB، شغّل mysqldump --single-transaction. خطوة قبل النسخ الاحتياطي من سطر واحد تتولّى الأمر:
pg_dumpall -U postgres | gzip > /srv/backups/db-$(date +%F).sql.gz
ويضيف Docker الفخّ نفسه: فالحالة المهمة تعيش في وحدات التخزين المُسمّاة، لا في الحاوية. إما أن تفرّغ قاعدة البيانات داخل الحاوية بالطريقة نفسها، أو أوقف الحزمة لفترة وجيزة بـ docker compose down، وانسخ دليل وحدة التخزين احتياطياً، ثم أعده للعمل. إن كنت تستضيف تطبيقاً ذا حالة ذاتياً، فإن دليل استضافة Supabase الذاتية لدينا يشرح أي مسارات Postgres والتخزين تحتاج فعلاً إلى الحماية. القاعدة بسيطة: انسخ احتياطياً نسخة متسقة، لا نسخة حيّة أبداً.
أتمِت الأمر: مؤقّت systemd ليلي
النسخة الاحتياطية التي تشغّلها يدوياً هي نسخة احتياطية ستنساها. لُفّ تسلسل التفريغ-ثم-restic في سكربت صغير، وقُده بمؤقّت systemd (أنظف من cron، مع سجلّات في journalctl). أنشئ /etc/systemd/system/backup.service يشير إلى سكربتك، ثم مؤقّتاً:
# /etc/systemd/system/backup.timer
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
[Install]
WantedBy=timers.target
فعّله بـ systemctl enable --now backup.timer. أضف سياسة استبقاء كي لا ينمو المستودع إلى الأبد — فـ سياسة forget/prune في restic تحتفظ بسلّم منطقي وتحذف الباقي:
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
Persistent=true مهم: إذا كان الخادم مطفأً عند الساعة 03:30، فإن المهمة تعمل عند الإقلاع التالي بدلاً من تخطّيها بصمت. اقرن هذا بخادم محكم الإغلاق — فـ دليل الساعة الأولى الآمنة لـ VPS لدينا يغطّي الجدار الناري وتقوية SSH اللذين يمنعان مضيف النسخ الاحتياطي نفسه من أن يصبح ثغرة الاختراق.
كم تكلّف النسخ الاحتياطية خارج الموقع فعلاً في 2026
النسخ الاحتياطي خارج الموقع هو واحدة من أرخص بوالص التأمين في التقنية. تخزين الكائنات يُحاسَب لكل غيغابايت، وخادم VPS نموذجي لا يحمل سوى عشرات الغيغابايت من البيانات الحقيقية بعد إزالة التكرار والضغط.
| الخيار | السعر (2026) | الخروج (Egress) | ملاحظات |
|---|---|---|---|
| Backblaze B2 | $6.95 / TB / mo | مجاني حتى 3× المخزّن، ثم $0.01/GB | أول 10 GB مجاناً؛ هدف restic أصلي |
| Hetzner Storage Box | بضعة يوروهات شهرياً لـ 1 TB | مشمول | BorgBackup + rsync عبر SSH |
| AWS S3 | ~$23 / TB / mo | $0.09/GB | يتراكم الخروج بسرعة عند الاستعادة |
بالنسبة إلى خادم يحمل 30 GB من اللقطات مُزالة التكرار، يكلّف Backblaze B2 أقل من دولار بكثير شهرياً، ولأن B2 يمنح خروجاً مجانياً حتى ثلاثة أضعاف حجمك المخزّن، فإن الاستعادة الكاملة عادة لا تكلّف شيئاً. هذا هو الرقم الذي يجب موازنته بالبديل: إعادة بناء قاعدة بيانات مفقودة من الذاكرة. إن كنت تضبط تكلفة حزمتك بأكملها، فإن منطق «راقب الخروج» نفسه هو ما يقود تحليلنا لرسوم الخروج السحابية.
اختبر الاستعادة — الخطوة التي يتخطاها الجميع
النسخة الاحتياطية غير المُختبَرة أمل، وليست نسخة احتياطية. الطريقة الوحيدة لمعرفة أن إعدادك يعمل هي أن تستعيد منه قبل أن تحتاج إليه. مع restic، تحقّق من سلامة المستودع ثم استعد لقطة إلى دليل مؤقت:
restic check # verify repository integrity
restic snapshots # list what you have
restic restore latest --target /tmp/restore-test
قارن الملفات المستعادة بالأصول، وتأكّد أن تفريغ قاعدة البيانات يُستورَد فعلاً إلى قاعدة بيانات قابلة للرمي، ثم احذف النسخة المؤقتة. افعل هذا يوم إعدادك للأمر، ومرة أخرى كلما غيّرت ما تنسخه احتياطياً. يمكنك أيضاً تنفيذ restic mount /mnt/restic لتصفّح اللقطات كنظام ملفات عادي وسحب ملف واحد. ضع تمرين استعادة على التقويم كل ربع سنة. نمط الفشل الذي ينهي الشركات ليس «لم يكن لدينا نسخ احتياطي»؛ بل هو «كان لدينا نسخ احتياطي، ولم يستعد أيٌّ منها».
الأسئلة الشائعة
ما أفضل أداة نسخ احتياطي لـ Linux؟
بالنسبة إلى خادم واحد يُنسَخ احتياطياً إلى السحابة، فإن restic هو الخيار الافتراضي الأفضل في 2026: فهو يشفّر ويزيل التكرار تلقائياً ويكتب مباشرةً إلى S3 أو Backblaze B2 أو SFTP. وBorgBackup خيار قوي بالقدر نفسه حين يكون هدفك مضيف SSH أو Hetzner Storage Box. استخدم rsync فقط للمرايا البسيطة حيث لا تحتاج إلى تشفير أو سجلّ تاريخي.
كيف أنسخ احتياطياً خادم Ubuntu كاملاً؟
انسخ احتياطياً بياناتك (قواعد البيانات المُفرَّغة إلى ملفات، إضافة إلى /etc و/home وأدلة التطبيقات) بـ restic أو Borg إلى مستودع خارج الموقع، وأتمِت الأمر بمؤقّت systemd. نادراً ما تستحق صورة المعدن العاري الكاملة العناء لخادم VPS — فإعادة بناء نظام التشغيل واستعادة البيانات فوقه أسرع. إن أردت صورة كاملة فعلاً، فإن أدوات مثل Timeshift أو لقطة المزوّد تغطّي طبقة النظام.
كيف أنسخ احتياطياً خادم Linux إلى NAS؟
وجّه الأدوات نفسها إلى NAS بدلاً من السحابة. يعمل rsync عبر SSH على عكس الملفات إلى مشاركة مُصدَّرة؛ ويستطيع restic وBorg الكتابة إلى NAS عبر SFTP لنسخ احتياطية مشفّرة ومُصدَّرة. تعامل مع NAS كالنسخة 2 (المحلية) ومع ذلك احتفظ بنسخة 3 مشفّرة خارج الموقع، لأن حريقاً أو سرقة أو هجوم فدية يأخذ NAS والخادم معاً.
كيف أنسخ احتياطياً خادماً كاملاً للاستعادة على المعدن العاري؟
للاستعادة الكاملة للنظام تحتاج إلى صورة نظام، لا مجرد ملفات. يُنشئ Clonezilla صورة قرص قابلة للإقلاع، ويتولّى Veeam Agent for Linux أو Bacula النسخ الاحتياطي المتّسق مع التطبيقات على المعدن العاري للأساطيل. بالنسبة إلى VPS واحد، المسار العملي هو أن تكتب سكربت بناء خادمك (أو تستخدم Coolify أو Ansible) كي تصبح إعادة البناء مهمة من خمس دقائق، ثم استعد نسختك الاحتياطية من البيانات فوقها.
Sources
- Backblaze — B2 Cloud Storage pricing: $6.95/TB/month, free egress up to 3× stored, then $0.01/GB.
- Hetzner — Storage Box: 1 TB+ boxes supporting BorgBackup and rsync over SSH.
- restic documentation: encryption, deduplication, supported backends, and snapshot handling.
- restic — Removing snapshots (forget/prune): retention policy flags.
- LinuxTeck — Best Linux Server Backup Solutions 2026: the 3-2-1 rule and tool comparison.
وقاص احمد وسیر
وقاص احمد وسیر مطوّر ومهندس أتمتة بخبرة تزيد على 8 سنوات في بناء أنظمة إنتاجية يستخدمها أكثر من 100 ألف شخص. يبني تطبيقات SaaS متعددة المستأجرين، وأتمتة بالذكاء الاصطناعي (n8n، تدفقات LLM، بوتات واتساب)، وبنية استضافة (WHM/cPanel، CloudLinux) — وهو صانع WaSphere وFlowMaticX وعلامة الاستضافة WaseerHost. أنجز أكثر من 100 مشروع لشركات صغيرة ومتوسطة ووكالات وشركات ناشئة ممولة.



