Tidak ada frekuensi yang benar, yang ada hanyalah akibat. Jarak antara dua cadangan persis sama dengan banyaknya pekerjaan yang akan hilang dalam keadaan terburuk. Tentukan berapa besar angka itu boleh menjadi, dan jadwalnya mengikuti dengan sendirinya.

Tanyakan dengan suara keras

Kalau semuanya lenyap sekarang juga dan salinan terbarunya berasal dari tadi malam, apa yang hilang? Untuk situs profil perusahaan: tidak ada. Untuk toko: pesanan hari ini, artinya pelanggan yang sudah membayar dan tak punya catatan apa pun tentangnya.

Titik awal yang masuk akal

  • Situs profil, berubah sebulan sekali — cadangan penuh mingguan sudah murah hati.
  • Blog atau situs berita — tiap malam.
  • Toko atau sistem pemesanan — berkas tiap malam, basis data tiap jam.
  • Apa pun yang menerima pembayaran terus-menerus — berkas tiap malam, basis data tiap 15 menit atau pengiriman log tanpa henti.

Berkas dan basis data tidak butuh jadwal yang sama

Berkas berubah saat Anda menerapkan pembaruan. Baris berubah setiap menit. Mencadangkan keduanya secara terpisah berarti pekerjaan yang sering dan mahal itu justru yang berukuran kecil.

# 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 mengambil citra InnoDB yang runut tanpa mengunci situsnya. Tanpa itu, toko yang ramai terkunci sepanjang dump berlangsung — lihat Mengekspor tanpa mengunci situs.

Dan juga sebelum tiap perubahan

Sebuah jadwal tidak mencakup pembaruan yang sebentar lagi Anda terapkan. Ambil satu cadangan dulu — lihat Cadangkan sebelum tiap pembaruan.

Lebih sering itu hanya lebih baik sampai titik ketika tak ada lagi yang memeriksa apakah cadangannya berhasil. Cadangan malam yang diperiksa mengalahkan cadangan tiap jam yang sudah gagal diam-diam sejak bulan Maret — lihat Membaca log pencadangan yang gagal.