Konsep Backup

Sepanjang course ini kita membangun database table demi table dan baris demi baris, tetapi kita belum pernah bertanya: apa yang terjadi jika semuanya hilang malam ini? Disk server bisa rusak, perintah DROP DATABASE bisa terketik di server yang salah, atau aplikasi bisa menulis data rusak yang baru disadari berhari-hari kemudian. Backup adalah salinan data yang sengaja kita siapkan untuk momen-momen itu, dan recovery adalah prosedur memulihkan database dari salinan tersebut. Chapter pembuka section ini tidak menyentuh satu perintah backup pun lebih dulu — kita justru akan melatih kerangka keputusannya, karena alat backup apa pun yang kita pilih nanti harus tunduk pada dua angka sederhana: berapa banyak data yang boleh hilang, dan berapa lama layanan boleh berhenti.

RPO dan RTO: Dua Angka yang Menentukan Segalanya #

RPO (Recovery Point Objective) menjawab pertanyaan “berapa banyak data yang boleh hilang saat musibah terjadi?” Angka ini dihitung dari jarak waktu antara backup terakhir dan momen insiden. Jika kita mencadangkan database setiap hari pukul 02:00 dan insiden terjadi pukul 14:00, maka maksimal dua belas jam transaksi menguap — itu RPO kita, sekitar setengah hari. RTO (Recovery Time Objective) menjawab pertanyaan “berapa lama layanan boleh mati sebelum database pulih?” RTO diukur dari detik pertama insiden sampai aplikasi kembali melayani pelanggan.

Kedua angka ini bukan angka teknis semata, melainkan keputusan bisnis. Toko online kecil mungkin sanggup kehilangan pesanan satu jam dan meminta pelanggan memesan ulang, tetapi sistem kasir supermarket tidak boleh berhenti lebih dari beberapa menit karena antrean menumpuk di lapangan. Semakin kecil RPO dan RTO yang kita tetapkan, semakin mahal dan semakin rumit infrastruktur backup yang harus dibangun — itulah sebabnya setiap keputusan di section ini kita mulai dari kedua angka ini, bukan dari alatnya.

Logical dan Physical: Dua Keluarga Backup #

Semua teknik backup MySQL terbagi ke dalam dua keluarga besar. Logical backup menghasilkan file berisi perintah SQL — CREATE TABLE, INSERT — yang jika dijalankan ulang akan membangun kembali database dari nol; alat andalannya adalah mysqldump. Physical backup menghasilkan salinan file data itu sendiri: file .ibd milik InnoDB atau bahkan seluruh data directory tempat server menyimpan semuanya. Perbedaan “isi SQL” versus “salinan file” ini melahirkan kekuatan dan kelemahan yang saling bertolak belakang.

Kita akan membedah kedua keluarga ini secara praktis di dua chapter berikutnya; untuk sekarang, cukup pegang intuisinya. Logical backup fleksibel dan portabel, sehingga menjadi pilihan utama database kecil hingga menengah. Physical backup menang di kecepatan, sehingga menjadi pilihan wajib ketika data sudah ratusan gigabyte dan jendela restore tidak boleh lama.

Backup Online dan Offline #

Dari sudut pandang server, backup juga dibedakan menurut keadaan server saat salinan dibuat. Backup online diambil ketika server tetap melayani aplikasi — mysqldump dengan opsi --single-transaction bekerja seperti ini karena InnoDB menyediakan consistent snapshot tanpa mengunci table. Backup offline diambil ketika server dimatikan lebih dulu (cold backup), sehingga tidak ada transaksi yang menulis saat file disalin dan hasilnya pasti konsisten. Ada pula teknik yang menengahi keduanya: mengunci seluruh table sesaat (FLUSH TABLES WITH READ LOCK) atau memotret volume disk lewat LVM snapshot, lalu menyalin file dalam keadaan yang dibekukan sesaat.

Pilihan online atau offline adalah kompromi antara ketersediaan layanan dan kepastian konsistensi. Backup online mengutamakan aplikasi yang tetap hidup, tetapi menuntut mekanisme konsistensi yang benar; backup offline paling sederhana dan paling aman, tetapi layanan harus berhenti — sesuatu yang tidak dimiliki server produksi yang sibuk. Server latihan kita akan selalu memakai jalur online, sementara jalur offline kita bahas sebagai pola yang dipakai di server sungguhan.

Full, Incremental, dan Differential #

Frekuensi backup membentuk tiga strategi dasar. Full backup menyalin seluruh database setiap saat dijalankan — sederhana tetapi makin boros waktu dan ruang seiring data membesar. Incremental backup hanya menyimpan perubahan sejak backup terakhir (apapun jenisnya), sehingga ramping dan cepat, tetapi proses restore harus memutar ulang seluruh rantai incremental secara berurutan. Differential backup menyimpan perubahan sejak full backup terakhir, sehingga restore hanya butuh full backup terbaru plus satu file differential terbaru.

Perhatikan jalur differential di diagram: setiap differential menggantung pada full backup yang sama, bukan pada differential sebelumnya, sehingga restore di Rabu hanya membutuhkan dua file (full + differential Rabu). Di MySQL, incremental backup secara alami diperankan oleh binary log yang mencatat setiap perubahan data — topik yang akan kita bedah tuntas di chapter khusus, dan yang menjadi bahan bakar point-in-time recovery.

Aturan 3-2-1 #

Backup yang tersimpan di server yang sama dengan databasenya bukan backup — ia ikut lenyap saat server itu mati total. Prinsip 3-2-1 yang dipakai luas di industri memberikan kerangka minimal: sediakan 3 salinan data (1 data utama + 2 cadangan), simpan di 2 jenis media yang berbeda (misalnya disk server dan penyimpanan eksternal atau object storage), dan letakkan 1 salinan di lokasi terpisah secara geografis. Bangsa “media berbeda” melindungi dari kerusakan satu perangkat, sedangkan “lokasi luar” melindungi dari kebakaran, banjir, hingga ransomware yang mengenkripsi seluruh jaringan kantor.

Backup Bukan Arsip #

Dua kata ini sering dipakai bergantian padahal perannya bertolak belakang. Backup hidup singkat dan sengaja dirotasi: file backup minggu lama ditimpa atau dihapus karena fungsinya hanya memperpendek RPO. Arsip (archive) justru hidup lama karena tujuannya kepatuhan dan audit — laporan pajak lima tahun lalu harus tetap bisa dibuka meski tidak pernah dipulihkan ke server. Menyimpan backup bertahun-tahun menaikkan biaya penyimpanan tanpa nilai recovery, sementara memakai backup sebagai satu-satunya arsip berisiko karena rotasi otomatis bisa menghapusnya. Kalau data memang harus bertahan lama, arsipkan secara eksplisit di luar siklus rotasi backup.

Praktik: Data yang Akan Kita Lindungi #

Sisa section ini memakai satu database latihan yang sama supaya setiap teknik bisa dibandingkan apel dengan apel. Kita siapkan belajar_backup berisi table produk untuk toko kopi fiktif:

DROP DATABASE IF EXISTS belajar_backup;
CREATE DATABASE belajar_backup;
USE belajar_backup;

Output yang Dihasilkan:

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 1 row affected (0.00 sec)

Database changed

Pola tiga statement pembuka ini sengaja mengembalikan keadaan ke nol sebelum membangun ulang, supaya chapter aman dijalankan berulang. Selanjutnya kita ciptakan table beserta isinya:

CREATE TABLE produk (
  id    INT AUTO_INCREMENT PRIMARY KEY,
  nama  VARCHAR(100) NOT NULL,
  harga INT NOT NULL,
  stok  INT NOT NULL DEFAULT 0
);

INSERT INTO produk (id, nama, harga, stok) VALUES
  (1, 'Kopi Toraja', 52000, 15),
  (2, 'Teh Melati', 28000, 40),
  (3, 'Gula Aren', 32000, 8);

INSERT INTO produk (nama, harga, stok) VALUES
  ('Susu Kental', 38000, 12),
  ('Kopi Robusta', 48000, 20),
  ('Teh Hijau', 30000, 25);

Output yang Dihasilkan:

Query OK, 0 rows affected (0.00 sec)

Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

Enam produk senilai total stok 120 unit ini akan menjadi “harta” yang kita cadangkan, jatuhkan, dan bangkitkan berulang kali. Table ini sengaja kecil supaya setiap operasi backup selesai dalam hitungan detik — di data produksi berukuran ratusan gigabyte, perintah yang sama akan memakan waktu bermenit-menit, dan justru di situlah perbedaan strategi antar keluarga backup mulai terasa.

Keputusan Berdasarkan Tingkat Kritis #

Kerangka akhir sebelum praktik: tingkat kekritisan data menentukan seberapa jauh kita berinvestasi. Data latihan cukup dicadangkan begitu saja karena satu-satunya kerugian adalah waktu mengetik ulang. Data aplikasi internal perlu jadwal otomatis agar tidak bergantung pada ingatan manusia. Data yang mencatat uang dan pelanggan menuntut RPO kecil — kombinasi backup terjadwal plus binary log — serta uji restore berkala. Ketika setiap menit downtime bernilai jutaan rupiah, backup saja tidak cukup lagi dan kita berbicara tentang replikasi dan high availability, yang menjadi section penutup course ini.

Dengan kerangka keputusan di tangan, kita siap turun ke praktik. Chapter berikutnya membahas keluarga pertama secara mendalam: logical backup — bentuknya, kekuatannya, kelemahannya, dan mengapa mysqldump tetap menjadi alat yang wajib dikuasai setiap orang yang mengelola MySQL.

Referensi #

• Backup and Recovery — MySQL 8.4 Reference Manual
• Backup Methods — MySQL 8.4 Reference Manual
• Backup Policy — MySQL 8.4 Reference Manual