نسخة احتياطية مشفّرة لـVPS.
خارج الموقع، مُزالة التكرار، وبعيدة عن المتناول.

يخطئ كل نقاش تقريباً حول النسخ الاحتياطي في الدقيقة الأولى، لأن المتحدثين يتخيلان عطلاً مختلفاً كل منهما. أحدهما يتخيل قرصاً ميتاً. والآخر يتخيل صباح ثلاثاء يختفي فيه الحساب بأكمله. كل منهما يحتاج إجابة مختلفة، وأي إعداد ينجو من الحالة الأولى فقط يبدو آمناً إلى أن يختبره الثاني.

هناك أربعة أنماط فشل تستحق التصميم لمواجهتها، وهي ليست تنويعات على فكرة واحدة — كل نمط منها يُسقط دفاعاً مختلفاً.

العتاد. يتعطل NVMe، أو تموت العقدة المضيفة، أو تفقد المصفوفة عضوين دفعة واحدة. هذا هو العطل الذي يخطط له الجميع، وهو الأندر وقوعاً على البنية التحتية الافتراضية الحديثة. التخزين الزائد يتكفل به. لكن التخزين الزائد لا يتكفل بأي شيء آخر، ولهذا فإن RAID ليس نسخة احتياطية ولم يكن كذلك قط: فهو ينسخ كل عملية كتابة بأمانة، بما في ذلك الكتابة التي تقول «احذف كل شيء».

بشري. سكربت ترحيل شُغِّل على الإنتاج. أمر DROP TABLE في الطرفية الخطأ. أمر rsync بمعطيات معكوسة. هذا هو السبب الأكثر شيوعاً بفارق كبير لضياع البيانات الفعلي، والدفاع الوحيد ضده هو التاريخ — نسخة من قبل الخطأ، محفوظة في مكان لم يصله الخطأ. العنصر الحاسم هو الزمن: إذا كانت النسخة الوحيدة مرآة متأخرة ثلاثين ثانية فقط، فهي تحتوي على الخطأ بالفعل.

خبيث. يحصل أحدهم على صلاحيات root، أو تتسلل برمجية فدية عبر تطبيق لم يُحدَّث. أول ما تفعله برمجيات الفدية الحديثة هو البحث عن إعداد النسخ الاحتياطي — بيانات الاعتماد، المشاركات المُوصَّلة، مفاتيح السحابة — وتدمير ما تجده، تحديداً لأن استعادة ناجحة تحوّل كارثة إلى مجرد بعد ظهر. بيانات اعتماد نسخ احتياطي قادرة على الحذف هي بيانات اعتماد يرثها المهاجم. هذا هو الخلل الذي وُجد فصل append-only في هذا الدليل من أجله.

احتجازي. لم ينكسر شيء ولم يتعرّض شيء لهجوم؛ فقدت الوصول ببساطة. حساب عُلِّق بسبب إشارة احتيال آلية، أو بطاقة فشلت أثناء سفرك، أو نزاع، أو مراجعة امتثال، أو أمر قضائي مُبلَّغ إلى المزوّد. الجهاز سليم وغير قابل للوصول، وكل لقطة داخل ذلك الحساب غير قابلة للوصول معه. هذا هو العطل الذي لا يستطيع أي قدر من التكرار داخل مزوّد واحد الإجابة عنه، وهو السبب في أن نسخة احتياطية جادة تعيش تحت سقف مختلف.

الصف الأخير هو ما يبني عليه بقية هذا الدليل. وهو ليس أغلى من الصف الذي فوقه — فإعداد append-only مجاني، والولاية القضائية الثانية تكلف نفس $3.90 التي تكلفها الأولى.

قاعدة 3-2-1، مُعاد صياغتها لـVPS واحد. ثلاث نسخ من البيانات، على نوعين مختلفين من التخزين، إحداها خارج الموقع. الصياغة الكلاسيكية تعود إلى عصر الأشرطة وخوادم المكاتب، وروحها تصمد في النقل أفضل من حرفيتها. بالنسبة لجهاز واحد مُستضاف ذاتياً، تصبح كالتالي: البيانات الحية على VPS، ومستودع على جهاز ثانٍ في مكان آخر، و — لأي شيء لا يمكن تعويضه فعلاً — نسخة ثالثة يمكنك حملها بيدك، على قرص في المنزل أو في درج. الرقم الذي يهم فعلاً ليس ثلاثة. بل عدد الأشياء المستقلة التي يجب أن تسوء قبل ضياع البيانات. اثنان هو الحد الأدنى الذي يستحق أن تملكه.

نسخ نظام الملفات بأكمله احتياطياً خيار يمكن الدفاع عنه لكنه مُبذِّر. معظم الخادم لا يبعد عن إعادة إنشائه سوى أمر من مدير الحزم، وكل جيجابايت تحمله يجعل المستودع أبطأ في التقليم، وأغلى في الحفظ، وأبطأ في البحث عندما تكون مستعجلاً. التمرين المفيد هو العكس: اسرد ما لن يعيده لك تثبيت جديد.

بالنسبة لخادم VPS نموذجي مُستضاف ذاتياً، هذه القائمة قصيرة، وتحتوي دائماً على هذه الأشياء الخمسة:

• 01محتوى قاعدة البيانات. ليس مجلد البيانات — بل التفريغة. الخطوة 05 تشرح السبب.
• 02الملفات التي رفعها المستخدمون. volumes الخاصة بـ Docker، أو مجلد رفع أو وسائط، أو مخزن بريد. عادةً ما تشكّل معظم البايتات.
• 03الإعداد والأسرار. ملفات Compose، وملفات .env، ومفاتيح التشفير، ورموز API. صغيرة الحجم، لكنها الفارق بين استعادة تستغرق ساعتين وأخرى تستغرق يومين.
• 04حالة النظام التي عدّلتها. /etc بكامله صغير بما يكفي لأخذه دفعة واحدة — إعداد sshd، وقواعد الجدار الناري، ووحدات systemd، وإدخالات cron، وتوجيه البريد الذي أمضيت عليه أمسية.
• 05أي شيء مرتبط بهوية. مفتاح خدمة Tor المخفية، ومفتاح توقيع Matrix، ومفتاح WireGuard الخاص، ومحفظة عقدة. افقد أياً منها ولن تعود الخدمة — بل تعود خدمة مختلفة تحمل الاسم نفسه.

حوّل القائمة إلى ملفين على الخادم المصدر. قائمة include تُبقي القصد واضحاً؛ وقائمة exclude تُبقي الضوضاء خارجاً. كلاهما يُقرأ من قبل أمر النسخ الاحتياطي، وكلاهما ينبغي أن يكون جزءاً من النسخة الاحتياطية نفسها.

/etc/backup/include.txt

/etc
/opt
/root
/var/backups
/var/lib/docker/volumes
/home

/etc/backup/exclude.txt

# Caches and rebuildable artefacts
**/node_modules
**/.cache
**/*.tmp
/var/lib/docker/volumes/*/_data/cache
# Log noise — keep the config, drop the volume
/var/log/journal
# Never back up the mount point you restore into
/mnt/restore

ملاحظتان حول سطر Docker ذاك، لأنه يوقع كثيرين في الخطأ. الأحجام المُسمّاة تعيش تحت /var/lib/docker/volumes وهي ما تريده؛ أما bind mounts فتعيش أينما وضعتها أنت، غالباً بجانب ملف Compose، ويغطيها /opt. صور الحاويات ليست بيانات — فهي تعود بأمر pull، والنسخة الاحتياطية التي تحملها تحمل جيجابايتات لا تحتاج إليها.

أخيراً، قِس النتيجة قبل أن تبني أي شيء حولها. هذا الرقم يخبرك أي فئة مستودع تطلبها وهل سيستغرق التشغيل الأول أربع دقائق أم أربعين:

du -sh --exclude=/var/lib/docker/overlay2 /etc /opt /root /home /var/lib/docker/volumes

مضيف المستودع له مهمة واحدة وشبه لا متطلبات له. لا يحتاج إلى أنوية معالج، لأنه لا يقرأ بياناتك أبداً — إنه يحتفظ بـblobs مشفّرة لا يستطيع فتحها. ولا يحتاج إلى ذاكرة، لأن عمل إزالة التكرار يحدث على المصدر. إنه يحتاج إلى قرص، وعنوان ثابت، وأن يكون في مكان لا تلحقه فيه مشاكل الجهاز المصدر.

في لوحة التحكم: اطلب → VPS → Sentinel، بصورة Debian 12، و — وهذا هو بيت القصيد — معقل مختلف عن المعقل الذي يعمل فيه المصدر. Helsinki للعمل، وReykjavík للحفظ. لا حاجة إلى بريد إلكتروني لفتح الحساب، وتُسدَّد الفاتورة بـMonero أو Bitcoin أو Lightning أو أي من الأصول الأخرى المدعومة، ما يعني أن الجهاز الثاني لا يُعيد إدخال الهوية التي حرص الأول على حمايتها.

عمود مجموعة العمل يفترض لقطات يومية محفوظة لمدة سنة مع معدل تغيّر طبيعي؛ فالمستودع الذي يحتفظ في معظمه بملفات بطيئة التغيّر يذهب أبعد من ذلك بكثير، والمستودع المليء بملفات ثنائية كبيرة يُعاد كتابتها باستمرار يذهب أقل. الصف الأخير موجود لأجل الحجم الكبير، ولأجل التفصيل الذي ينساه الناس حتى اليوم السيئ: التخزين السحابي من نوع الكائنات يفرض رسوماً على التنزيل أيضاً، والتنزيل هو ما تفعله في حالة الطوارئ.

على الوجهة — مستخدم بلا صلاحيات ومجلد.

adduser --disabled-password --gecos "" backup
install -d -m 0700 -o backup -g backup /srv/restic/web01

مستخدم النسخ الاحتياطي لا كلمة مرور له، ولا صلاحية sudo، ولا شيء يمكنه تسجيل الدخول إليه. وجوده فقط لامتلاك مجلد. امنحه مجلداً خاصاً به لكل جهاز مصدر إذا كنت تنسخ عدة أجهزة احتياطياً — فمستودع واحد لكل مصدر يمنع اختراق جهاز واحد من المساس بتاريخ جهاز آخر.

على المصدر — مفتاح لا يُستخدم لأي شيء آخر.

ssh-keygen -t ed25519 -f /root/.ssh/id_backup -N "" -C "backup:web01"
cat /root/.ssh/id_backup.pub

لا تُعِد استخدام مفتاح تسجيل الدخول الخاص بك. هذا المفتاح يعيش بلا تشفير على القرص لأن مؤقتاً بلا مراقبة يجب أن يستخدمه في الثالثة فجراً، وهذا بالضبط نوع المفتاح الذي تريده مقصوراً على وجهة واحدة وغرض واحد.

عودة إلى الوجهة — قيّد ما يمكن لذلك المفتاح فعله. الصق المفتاح العام في /home/backup/.ssh/authorized_keys مع إضافة بادئة أمامه. لـrestic عبر SFTP:

restrict,from="198.51.100.7" ssh-ed25519 AAAAC3NzaC1lZDI1... backup:web01

خيار restrict يوقف بكلمة واحدة إعادة توجيه المنافذ، وإعادة توجيه الوكيل، وX11، وتخصيص PTY، تاركاً نقل الملفات فقط ولا شيء غيره. عبارة from= تُقيّد المفتاح بعنوان المصدر، لذا فإن نسخة منه مسروقة من الخادم تصبح عديمة الفائدة في أي مكان آخر. بالنسبة لـBorg، اذهب خطوة أبعد وافرض الأمر، حيث يعيش نمط append-only الخاص به:

command="borg serve --append-only --restrict-to-path /srv/borg/web01",restrict ssh-ed25519 AAAAC3NzaC1lZDI1... borg:web01

هذا السطر هو دفاع كامل ضد برمجيات الفدية في مكان واحد: مهما أرسل المصدر، فإن الوجهة لن تُشغّل سوى borg serve، وداخل ذلك المسار فقط، وفي نمط لا يفعل سوى الإلحاق. صدفة root على المصدر لا تستطيع استخدام هذا المفتاح لمحو الشهر الماضي.

سمِّ الوجهة مرة واحدة، على المصدر. ضعه في /root/.ssh/config حتى يكون كل أمر لاحق قصيراً ويبقى العنوان في ملف واحد بعينه:

Host rkv-repo
    HostName 198.51.100.42
    User backup
    IdentityFile /root/.ssh/id_backup
    IdentitiesOnly yes

ثم اتصل مرة واحدة يدوياً — ssh rkv-repo — لقبول مفتاح المضيف. المؤقت غير المُراقَب لن يجيب على مطالبة بصمة الاتصال، وأول نسخة احتياطية تتجمد بصمت لأسبوع كامل هي حالة كلاسيكية. وبينما أنت على الوجهة، عاملها كما تعامل أي جهاز آخر تملكه: شغّل التصليب في الساعة الأولى عليها أيضاً. فهي تحتفظ بنسخة من كل شيء، وتستحق الساعة كاملة.

قاعدة قواعد البيانات، مذكورة مرة واحدة. محرك قاعدة بيانات يعمل يحتفظ بحالته في الذاكرة ويكتبها إلى القرص في وقته الخاص. اقرأ ملفاته أثناء ذلك وستحصل على مجموعة صفحات من لحظات مختلفة عدة — ملف قد يُستعاد، وقد يُستعاد تالفاً، أو قد يُستعاد كشيء يُفتح بسلاسة لكنه يفتقد الساعة الأخيرة بصمت. لا سبيل لمعرفة أي احتمال تحقق من الخارج. لذلك لا تلمس النسخة الاحتياطية الملفات الحيّة أبداً: تُكتب تفريغة إلى القرص أولاً، وتأخذ النسخة الاحتياطية تلك التفريغة.

كل شيء يذهب إلى سكربت واحد. ضعه في /usr/local/sbin/nb-backup.sh، واجعله قابلاً للتنفيذ، واحتفظ به داخل النسخة الاحتياطية نفسها:

#!/bin/sh
set -eu

# ---- 1. Consistent dumps, written where the include list will find them.
install -d -m 0700 /var/backups/db

# PostgreSQL in a container:
docker exec -t app-db pg_dumpall -U postgres | gzip -9 > /var/backups/db/postgres.sql.gz

# MariaDB / MySQL, InnoDB tables:
# docker exec -t mail-db mariadb-dump --single-transaction --all-databases \
#   | gzip -9 > /var/backups/db/mariadb.sql.gz

# SQLite — never a plain file copy:
# sqlite3 /opt/app/data/app.db ".backup '/var/backups/db/app.db'"

# ---- 2. The snapshot.
restic backup \
  --files-from /etc/backup/include.txt \
  --exclude-file /etc/backup/exclude.txt \
  --tag nightly --one-file-system

# ---- 3. Retention, then reclaim the space it freed.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# ---- 4. Structural check every night; read 5% of the data on Sundays.
restic check
[ "$(date +%u)" = "7" ] && restic check --read-data-subset=5%

echo "backup ok: $(date -u +%FT%TZ)"

ثلاثة تفاصيل في ذلك السكربت تؤدي عملاً أكبر مما تبدو عليه. set -eu في الأعلى تعني أن فشل التفريغة يُوقف التشغيل بدلاً من أخذ لقطة بصمت لتفريغة الأمس لستة أشهر قادمة. forget وprune هما أمر واحد، لأن سياسة احتفاظ لا تستعيد مساحة أبداً هي قرص سيمتلئ عاجلاً. وفحص يوم الأحد يقرأ شريحة من البيانات الفعلية وليس الفهرس فقط — فتلف المستودع نادر، وصامت، والشيء الوحيد الذي يكشفه هو القراءة.

المؤقت. ملفا وحدة صغيران. systemd هو المُجدوِل الصحيح هنا وليس cron، لأن المؤقت يمنحك Persistent — فالتشغيل الذي يفوت أثناء إطفاء الجهاز يحدث عند الإقلاع التالي بدلاً من تخطّيه بصمت — ولأن journalctl عندها يحتفظ بتاريخ كل تشغيل.

/etc/systemd/system/nb-backup.service

[Unit]
Description=Nightly encrypted offsite backup
Wants=network-online.target
After=network-online.target docker.service

[Service]
Type=oneshot
EnvironmentFile=/etc/backup/restic.env
ExecStart=/usr/local/sbin/nb-backup.sh
Nice=10
IOSchedulingClass=idle

/etc/systemd/system/nb-backup.timer

[Unit]
Description=Nightly encrypted offsite backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=45m
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now nb-backup.timer
systemctl list-timers nb-backup.timer
systemctl start nb-backup.service && journalctl -u nb-backup.service -n 40 --no-pager

التأخير العشوائي ليس زخرفة. كل خادم مُستضاف ذاتياً على الإنترنت يشغّل صيانته عند الساعة 03:00 بالضبط، والنسخة الاحتياطية التي تبدأ في نفس الثانية التي يبدأ فيها تدوير السجلات وتجديد الشهادة وتحديث الحاوية تقضي ليلتها في التنافس معها على عمليات الإدخال والإخراج. توزيع لحظة البدء عبر خمس وأربعين دقيقة لا يكلف شيئاً ويُزيل فئة كاملة من الليالي البطيئة الغامضة.

ثم اجعل الفشل صاخباً. هذه هي الخطوة التي يتخطاها الجميع، وهي التي تحدد ما إذا كان كل ما سبق يستحق العناء. النسخة الاحتياطية التي تتوقف عن العمل لا تُعلن ذلك: المؤقت يستمر في الإطلاق، والخدمة تستمر في الفشل، وآخر لقطة سليمة تتراجع إلى الماضي بينما تبقى لوحة التحكم خضراء. أضف وحدة OnFailure= إلى الخدمة تُرسل لك شيئاً سترى فعلاً، وألقِ نظرة مرة في الشهر على أعلى قائمة اللقطات. سطر واحد، وعادة واحدة.

restic snapshots --latest 3        # is the newest one from last night?
systemctl list-timers nb-backup.timer   # is the timer still armed?

كل ما سبق هنا يحمي من الحوادث. هذا الفصل يحمي من خصم، ومشكلة التصميم غير مريحة بمجرد أن تراها: يجب على الجهاز المصدر أن يصل إلى المستودع كل ليلة، ما يعني أن الجهاز المصدر يحمل بيانات اعتماد فعّالة للمستودع. من يملك المصدر يملك تلك البيانات. إذا كانت بيانات الاعتماد قادرة على الحذف، فالمهاجم يحذف — وبرمجيات الفدية الحديثة تفعل ذلك بالضبط، وعن قصد، قبل أن تُشفّر أي شيء، لأن الضحية القادرة على الاستعادة لا تدفع.

الحل ليس كلمة مرور أقوى. إنه صلاحية غير متماثلة: يمكن للمصدر إضافة بيانات ولا يمكنه إزالة أي منها. ثلاث طرق لبنائها، مرتبة تنازلياً بحسب سهولة تنفيذها بشكل صحيح.

الأولى — وضع append-only المفروض عبر SSH. هذا هو الميدان الأصلي لـBorg وهو الحل الأنظف المتاح على جهاز تملكه. مُدخل authorized_keys من الخطوة 03 يفرض borg serve --append-only، لذا يرفض الطرف البعيد أي حذف مهما طلب الطرف القريب. لا يزال التقليم يجب أن يحدث، لكنه يحدث من جهة الوجهة، وفق جدول لا يستطيع المصدر التأثير فيه، ويُشغّله حساب لا يستطيع المصدر الوصول إليه. مهاجم يملك صلاحيات root على المصدر يستطيع ملء المستودع بالقمامة؛ لكنه لا يستطيع إزالة الأرشيف الخاص بالليلة السابقة لوصوله.

الثانية — نقطة نهاية REST من نوع append-only. rest-server المرافق لـrestic يملك نمط --append-only بنفس الخاصية: الكائنات الجديدة تُقبل، والموجودة لا يمكن حذفها. شغّله على الوجهة خلف TLS، ووجّه RESTIC_REPOSITORY إلى رابط https:// بدلاً من sftp:، ويصبح شكل الدفاع مطابقاً. هذا يكلف خدمة إضافية واحدة على الوجهة ويمنح نفس الضمان.

الثالثة — قفل الكائن. على تخزين متوافق مع S3، يجعل تفعيل الإصدارات إلى جانب فترة احتفاظ بقفل الكائن الحذفَ مستحيلاً حتى تنتهي الفترة، وهو أمر تفرضه طبقة التخزين لا برنامج. إنه الأقوى بين الثلاثة والأكثر كلفة، ويُدخِل حساب مزوّد — ما يُعيد المخاطرة الاحتجازية التي يحاول هذا الدليل بأكمله توزيعها. معقول كنسخة ثالثة، ومحرج كنسخة وحيدة.

إذا لم يناسبك أي من هذه — SFTP عادي، مفتاح قادر على الكتابة وبالتالي على الحذف — فلا تتظاهر بغير ذلك؛ أضِف نسخة ثانية مستقلة لا يستطيع المصدر لمسها إطلاقاً. اسحب بدلاً من أن تدفع: دع الوجهة تسجّل الدخول إلى المصدر، وتقرأ ما تحتاجه، وتخزّنه. عندها تعيش بيانات الاعتماد على الجهاز غير المكشوف، ولا يجد مهاجم على المصدر شيئاً يشير إلى النسخة الاحتياطية. الأمر يتطلب عملاً إضافياً بسيطاً لإعداده، لكنه يقلب المخاطرة في الاتجاه الصحيح تماماً.

أياً كان ما تختاره، تحقق منه بالطريقة نفسها التي تتحقق بها من أي ضابط أمني آخر — بمحاولة كسره. من المصدر، وباستخدام مفتاح النسخ الاحتياطي، حاول تنفيذ حذف. النتيجة الصحيحة هي الرفض.

borg delete ::name-of-an-old-archive
# → Remote: Repository is in append-only mode. Refusing to delete.

اسأل معظم الناس لماذا يجب أن تكون النسخة الاحتياطية في مكان آخر، وستكون الإجابة حريقاً، أو فيضاناً، أو انقطاع كهرباء في مركز بيانات. كلها حقيقية، وكلها نادرة أكثر فأكثر، وكلها تجيب عنها مئة كيلومتر من المسافة. الأعطال التي تُسقط الشركات فعلاً في 2026 إدارية، والمسافة وحدها لا تفعل شيئاً حيالها.

حساب واحد هو نقطة فشل واحدة. تعليق بسبب إشارة احتيال آلية، أو استرداد مبلغ بينما كنت على متن طائرة، أو مراجعة امتثال، أو إخطار إزالة موجَّه إلى الشركة لا إلى جهاز بعينه — كل واحد من هذه يصل إلى كل خادم تحت ذلك الحساب في اللحظة نفسها، بما في ذلك الخادم الذي يحمل اللقطات. كان التكرار التقني مثالياً وغير ذي صلة. مزوّدان، أو على الأقل حسابان تحت سقفين قانونيين مختلفين، هما البنية الوحيدة التي تجيب عن هذا.

ولاية قضائية واحدة هي إطار قانوني واحد. المعاقل النوردية الأربعة ليست قابلة للتبادل — فالسويد وفنلندا والنرويج وآيسلندا تحمي كل منها شيئاً مختلفاً قليلاً، والنرويج وآيسلندا تقعان بالكامل خارج الاتحاد الأوروبي. تقسيم جهاز عامل ومستودعه بين اثنتين منهما يعني أن النسخة ليست فقط في مكان آخر؛ بل هي تحت مجموعة ثانية ومستقلة من القواعد. مرجع الولايات القضائية النوردية يستعرض القوانين واحداً تلو الآخر.

والوجهة لا تعرف شيئاً. هذا ما يجعل الفصل رخيصاً بدلاً من أن يكون مقايضة. كل من restic وBorg يُشفّر قبل أن يغادر أي شيء المصدر، لذا يخزّن مضيف المستودع blobs لا يملك مفتاحاً لها. إنه لا يعرف أي الملفات يحتفظ بها، ولا كم عددها، ولا ما هي أسماؤها. أنت لا تمنح ثقة لطرف ثانٍ؛ بل تستأجر قرصاً لا يستطيع قراءة نفسه. وهذه أيضاً الإجابة الصادقة عن سؤال «هل يجب أن أستخدم مزوداً لا أثق به تماماً كوجهة للنسخ الاحتياطي؟» — بالنسبة لمستودع مشفّر، فإن الثقة بالكاد تدخل في المعادلة.

زمن الاستجابة ليس عاملاً مؤثراً. المسافة من Helsinki إلى Reykjavík هي 30 ms على العمود الفقري، ومن Helsinki إلى Stockholm 8 ms، ومن Stockholm إلى Oslo 11 ms. النسخ الاحتياطي الليلي لا يهتم بأي من هذه الأرقام، ولا تهتم بها استعادة محكومة بسرعة القرص. اختر الزوج من أجل المسافة القانونية، لا مسافة الشبكة — فمسافة الشبكة عبر الدول النوردية خطأ تقريب لا أكثر.

شيء أخير يستحق أن يُقال بوضوح، لأنه سبب وجود هذا الدليل على هذا الموقع بدلاً من مدونة سيسادمن عامة: الجهاز الثاني يعيد فتح كل سؤال أجاب عنه الأول. إذا طُلب VPS العامل بلا وثيقة هوية ودُفع بـMonero، ثم طُلب جهاز النسخ الاحتياطي الخاص به ببطاقة شركة ومسح جواز سفر، يصبح الزوج قابلاً للتعرّف بقدر النصف الأضعف بالضبط. الدليل الرئيسي حول استضافة VPS مجهولة الهوية يستعرض الطبقات الثلاث — التسجيل، والدفع، والشبكة — وتنطبق على هدف نسخ احتياطي بقدر انطباقها تماماً على خادم ويب.