لا وجود لتواترٍ صحيح، بل لنتيجة. فالمدّة بين نسختين هي بالضبط مقدار ما ستفقده من عمل في أسوأ الأحوال. قرّر كم يُسمح لذلك الرقم أن يكون، ويتبع الجدولُ منه.

اسأله بصوت مسموع

لو اختفى كل شيء الآن وكانت أحدث نسخة من الليلة الماضية، فماذا ضاع؟ لموقعٍ تعريفيّ: لا شيء. ولمتجر: طلبات اليوم، أي زبائن دفعوا ولا سجلّ لدفعهم.

نقاط انطلاق معقولة

  • موقع تعريفيّ يتغيّر شهريًّا — نسخةٌ كاملة أسبوعيًّا كرمٌ.
  • مدوّنة أو موقع أخبار — كل ليلة.
  • متجر أو نظام حجز — الملفّات كل ليلة، وقاعدة البيانات كل ساعة.
  • وكل ما يتلقّى مدفوعات باستمرار — الملفّات كل ليلة، وقاعدة البيانات كل ١٥ دقيقة أو شحنُ سجلّات متّصل.

والملفّات وقاعدة البيانات لا تحتاجان الجدول نفسه

الملفّات تتغيّر حين تنشر. والصفوف تتغيّر كل دقيقة. ونسخُهما منفصلَين يعني أن المهمّة المتكرّرة المكلفة هي الصغيرة.

# hourly, database only
15 * * * * /usr/bin/mysqldump --single-transaction --quick shop \
  | gzip > /srv/backup/db-$(date +\%H).sql.gz

# nightly, everything
30 2 * * * /usr/local/bin/restic backup /var/www /srv/backup
الراية ‎--single-transaction‎ تأخذ لقطةً متّسقة من InnoDB بلا إقفال للموقع. وبدونها يُقفَل متجرٌ مزدحم طوال مدّة النسخ — انظر التصدير بلا إقفال الموقع.

وقبل كل تغيير أيضًا

الجدول لا يغطّي التحديث الذي أنت على وشك تطبيقه. خذ نسخةً أوّلًا — انظر انسخ احتياطيًّا قبل كل تحديث.

والتواتر الأكثر أفضل فقط حتى النقطة التي لا يفحص عندها أحدٌ أنه نجح. فنسخةٌ ليلية مُتحقَّق منها خيرٌ من نسخةٍ كل ساعة تفشل بصمت منذ مارس — انظر قراءة سجلّ نسخة فاشلة.