النسخة تحمي ممّا لا تشاركه المصير. فعلى القرص نفسه تنجو من ملفّ محذوف لا من قرصٍ عطب. وعلى الخادم نفسه تنجو من قرصٍ عطب لا من حسابٍ اختُرق. والسؤال دائمًا: ما الذي تشاركه هذه النسخة المصير؟
ثلاثة واثنان وواحد، بعبارة صريحة
- ثلاث نسخ — الحيّة ونسختان احتياطيّتان.
- ونوعان من التخزين — لا مجلّدان على قرص واحد.
- وواحدة في مكان آخر — جهازٌ مختلف، والأفضل مزوّدٌ مختلف.
و«المكان الآخر»، مرتَّبًا بمقدار ما يحمي
- قرصٌ آخر على الخادم نفسه — من قرصٍ عطب، ولا شيء غير ذلك.
- وخادمٌ آخر عند المزوّد نفسه — من خادمٍ عطب. لا من تعليق حساب، ولا من خطأٍ ارتُكب بصلاحيةٍ تشمل المزوّد كلّه.
- ومزوّدٌ آخر بالكامل — كل ما سبق، ويومَ يكون الحساب نفسه هو المشكلة.
وإن كان اختراقُ خادمك يقدر على حذف النسخ أيضًا، فليست دفاعًا عن اختراق. وجهةُ النسخ ينبغي أن تكون للكتابة فقط من الخادم: يضيف ولا يحذف.
الكتابة فقط، عمليًّا
# object storage with an append-only policy, or
# a pull model: the BACKUP server connects to the site and takes a copy,
# so the site never holds credentials that can delete anything
نموذج السحب هو الأقوى والأقلّ استعمالًا: لا شيء على خادم الويب يقدر على بلوغ النسخ إطلاقًا، فلا شيء يحدث هناك يقدر على مسّها.
شفّرها، واحفظ المفتاح في مكان آخر
gpg --symmetric --cipher-algo AES256 backup.tar.gz
مفتاحٌ محفوظ على الخادم الذي مات وحده ليس مفتاحًا. اكتبه واحفظه في مكانٍ لا علاقة له بالخادم.
وجرّب النسخة البعيدة تحديدًا. فالمحليّة تعمل عادةً، والبعيدة هي التي لم يستعد منها أحدٌ قطّ.