Backup Retention

Backup yang sukses menumpuk dengan cepat: dump harian 50 GB berarti 1,5 TB baru setiap bulan, dan tanpa kebijakan, storage backup tumbuh lebih cepat daripada data produksinya sendiri. Di ujung lain, rotasi yang terlalu agresif menghapus salinan yang keliru dianggap tidak berguna — tepat sebelum dibutuhkan untuk audit. Backup retention adalah kebijakan yang menjaga keseimbangan itu: berapa salinan, berapa lama disimpan, di media apa, dan bagaimana dilindungi. Chapter ini menutup section backup dengan kerangka kebijakan lengkap — dari aturan 3-2-1 sampai enkripsi berkas backup.

Peta materi Chapter ini:

• Aturan 3-2-1 dan skema rotasi grandfather-father-son (GFS).
• Retensi hukum versus kebutuhan praktis, plus estimasi biaya penyimpanannya.
• Enkripsi backup dan contoh kebijakan retensi siap pakai.

Aturan 3-2-1 dan Rotasi GFS #

Standar industri yang paling bertahan lama bernama 3-2-1: minimal 3 salinan data (1 utama + 2 backup), tersimpan di 2 jenis media berbeda, dengan 1 salinan di luar lokasi. Aturan ini menyerang dua risiko sekaligus — satu jenis media bisa gagal serentak (maka dua jenis), dan satu lokasi bisa bermasalah (maka satu salinan offsite). Banyak tim memperpanjangnya menjadi 3-2-1-1-0: satu salinan tambahan yang immutable atau offline, dan nimalah — 0 — salinan yang gagal diverifikasi.

Berapa lama tiap salinan disimpan diatur skema rotasi grandfather-father-son (GFS): salinan harian (son) disimpan pendek, mingguan (father) lebih lama, dan bulanan (grandfather) paling lama. Hasilnya tangga pemulihan yang efisien: insiden hari ini dipulihkan dari salinan kemarin, insiden bulan lalu dari snapshot mingguan, dan kebutuhan audit dari salinan bulanan. Mari hitung konsekuensi storage-nya untuk dump produksi 50 GB dengan kompresi 60%:

const dumpGb = 50
const gfs = { harian: 7, mingguan: 4, bulanan: 12 }
const totalSalinan = gfs.harian + gfs.mingguan + gfs.bulanan
const kompresi = 0.6
const totalGb = dumpGb * totalSalinan * kompresi
print("salinan tersimpan : " + totalSalinan + " (7 harian + 4 mingguan + 12 bulanan)")
print("total terkompresi : " + totalGb + " GB")
print("aturan 3-2-1      : " + totalGb * 3 + " GB di 2 media berbeda, 1 salinan di luar lokasi")

Output yang Dihasilkan:

salinan tersimpan : 23 (7 harian + 4 mingguan + 12 bulanan)
total terkompresi : 690 GB
aturan 3-2-1      : 2070 GB di 2 media berbeda, 1 salinan di luar lokasi

Skema GFS 23 salinan menuntut 690 GB, dan menerapkan 3-2-1 menaikkannya menjadi 2 TB lebih. Itulah harga nyata dari kebijakan yang tampak sederhana di dokumen — dan alasan angka retensi harus dipilih berdasarkan kebutuhan, bukan kebiasaan.

Retensi Hukum versus Praktis #

Dua kebutuhan retensi yang berbeda sering dipaksakan masuk satu angka, lalu merugikan keduanya. Kebutuhan praktis mengikuti pola insiden: mayoritas kesalahan terdeteksi dalam hitungan hari, sehingga salinan 30-60 hari ke depan sudah menutup hampir semua skenario pemulihan. Kebutuhan hukum mengikuti regulasi: laporan keuangan dan data pribadi sering wajib dipertahankan 5-10 tahun, tergantung yurisdiksi dan industri.

Memisahkan keduanya dalam kebijakan adalah kunci efisiensi: salinan bulanan “diangkat” ke tier penyimpanan murah untuk memenuhi retensi hukum, sementara tier harian tetap cepat diakses. Di Atlas, pemisahan ini bahkan bawaan — policy item monthly dan yearly punya retensi dan biaya tersendiri, dan Backup Compliance Policy dapat mengunci salinan agar tidak bisa dihapus siapa pun selama periode proteksi. Untuk berkas mandiri, properti object lock / WORM pada S3 atau Azure Blob memberikan jaminan serupa.

Biaya dan Enkripsi #

Biaya retensi bukan hanya storage. Setiap salinan menambah biaya transfer (terutama lintas region), biaya request API, dan biaya tenaga menjaga rotasinya. Tiga tuas pengendali yang paling efektif: kompresi (bendera --gzip pada dump, atau snapshot terkompresi), tiering (panjang umur → media murah), dan seleksi namespace (--nsInclude untuk membackup hanya database yang benar-benar dipulihkan). Angka 690 GB pada perhitungan kita tadi turun ke 276 GB bila hanya separuh database yang layak dibackup penuh.

Sisi keamanan sama pentingnya: backup adalah salinan data yang sering luput dari pengawasan akses sekeras produksi, padahal berisi data yang sama. Enkripsi minimal diterapkan saat berkas backup meninggalkan server:

  # enkripsi berkas archive sebelum disimpan (contoh pola umum, sesuaikan
  # dengan kebijakan keamanan organisasi Anda)
gpg --symmetric --cipher-algo AES256 latihan_backup.archive

  # atau simpan ke object storage dengan enkripsi sisi server
aws s3 cp latihan_backup.archive s3://bucket-backup/ --sse AES256

Aturan pendampingnya satu dan tidak bisa ditawar: kunci enkripsi disimpan terpisah dari backup yang dienkripsinya. Backup yang terenkripsi bagus, tetapi backup yang terenkripsi bersama kuncinya hanya memberi rasa aman palsu. Pada layanan terkelola seperti Atlas, snapshot Cloud Backup terenkripsi secara bawaan — namun untuk salinan yang kita ekspor sendiri ke bucket sendiri, tanggung jawab enkripsi berpindah ke kita.

Contoh Kebijakan Siap Pakai #

Menggabungkan seluruh kerangka di atas, berikut contoh kebijakan retensi untuk sistem dengan kebutuhan audit keuangan:

Kebijakan yang ditulis selalu diikuti tiga kebiasaan pelengkap: uji restore berkala tetap dijalankan pada tiap tier (salinan tahunan pun bisa gagal dibaca), kebijakan ditinjau ulang setiap ada perubahan regulasi atau arsitektur, dan setiap pengecualian (“database ini tidak dibackup”) tercatat dengan alasannya — pengecualian yang tidak tertulis adalah insiden yang menunggu waktunya.

Rangkuman #

• Aturan 3-2-1: tiga salinan, dua jenis media, satu di luar lokasi — diperkuat 3-2-1-1-0 dengan satu salinan immutable dan verifikasi tanpa galat.
• Rotasi GFS (harian-mingguan-bulanan) memberi tangga pemulihan; 23 salinan untuk dump 50 GB sudah menuntut ±690 GB, tiga kalinya bila menerapkan 3-2-1.
• Retensi praktis (30-60 hari, untuk pola insiden) dipisahkan dari retensi hukum (5-10 tahun, cold storage/immutable, legal hold).
• Kompresi, tiering, dan seleksi namespace adalah tiga tuas biaya utama; enkripsi wajib saat berkas meninggalkan server, dengan kunci yang disimpan terpisah.
• Kebijakan retensi tertulis perlu ditinjau berkala dan selalu diuji restore-nya di setiap tier.