Physical Backup

Logical backup membaca data lalu menuliskannya ulang sebagai teks SQL — pendekatan yang elegan tetapi boros tenaga. Keluarga kedua menempuh jalan yang jauh lebih langsung: salin saja file-nya. Inilah physical backup — pendekatan yang dipakai hampir semua sistem database besar, karena menyalin file selalu lebih cepat daripada membaca dan menulis ulang setiap barisnya. Kecepatan itu dibayar dengan dua syarat yang tidak bisa ditawar: hasil salinan harus konsisten (diambil saat tidak ada penulisan setengah jadi), dan file hasil terikat pada versi serta platform server. Chapter ini membedah cara kerjanya, teknik-teknik mencapai konsistensi, dan kapan keluarga ini layak dipilih di atas mysqldump.

Menyalin Apa, Sebenarnya? #

Semua data MySQL hidup di satu folder induk bernama data directory. Di dalamnya, setiap database punya subfolder sendiri, dan berkat pengaturan bawaan innodb_file_per_table, setiap table InnoDB menyimpan datanya dalam file tersendiri bernama <nama-table>.ibd di subfolder database tersebut. Mari kita periksa dua fakta ini di server latihan:

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

Sama seperti chapter sebelumnya, pola ini mengembalikan keadaan ke nol sebelum kita mengisi ulang produk — kali ini dengan keenam produk toko kopi:

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);

SELECT @@innodb_file_per_table AS file_per_table;

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

+----------------+
| file_per_table |
+----------------+
|              1 |
+----------------+
1 row in set (0.00 sec)

Nilai 1 menandakan mode file-per-table aktif — artinya seluruh isi produk berada dalam satu file produk.ibd. Karena produk memakai InnoDB, mari kita pastikan engine-nya:

SHOW CREATE TABLE produk\G

Output yang Dihasilkan:

*************************** 1. row ***************************
       Table: produk
Create Table: CREATE TABLE `produk` (
  `id` int NOT NULL AUTO_INCREMENT,
  `nama` varchar(100) NOT NULL,
  `harga` int NOT NULL,
  `stok` int NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

Baris ENGINE=InnoDB pada definisi table menegaskan bahwa file produk.ibd di data directory memuat struktur sekaligus keenam baris data kita. Lokasi data directory sendiri bisa ditanyakan langsung ke server:

-- @check
SHOW VARIABLES LIKE 'datadir';

Output yang Dihasilkan:

+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+

Nilai /var/lib/mysql/ adalah lokasi standar instalasi paket di Linux; server latihan course ini menunjuk ke folder data directory miliknya sendiri, dan instalasi manual menunjuk ke folder yang kita tentukan sendiri saat inisialisasi. Di dalam folder itulah kita akan menemukan belajar_backup/produk.ibd beserta file-file sistem server. Physical backup pada intinya menyalin file-file ini — per table, per database, atau seluruh data directory sekaligus.

Kelebihan dan Kelemahan #

Inti trade-off-nya: physical menang di kecepatan dan kalah di kelenturan. Sebuah file .ibd hasil MySQL 8.4 di Linux tidak bisa begitu saja diletakkan di server MySQL 8.0 atau di Windows — format binernya terikat versi dan platform. Sebaliknya, saat data sudah berukuran ratusan gigabyte, kecepatan menjadi segalanya: dump SQL yang memakan waktu berjam-jam untuk dibuat bisa memakan waktu lebih lama lagi untuk direstore.

Konsistensi: Syarat Mutlak #

Masalah terbesar physical backup bukan kecepatan, melainkan saat penyalinan dilakukan. Server yang sedang sibuk menulis akan meninggalkan file dalam keadaan setengah ter-update: sebagian halaman sudah ditulis, sebagian masih di memori. Salinan file yang diambil di tengah-tengah kondisi itu menghasilkan backup yang rusak secara halus — kelihatan utuh, gagal saat dibuka. Empat teknik menjawab masalah ini, dari yang paling kasar sampai paling halus:

Cold backup — matikan server sepenuhnya, salin filenya, nyalakan kembali. Tanpa proses yang menulis, file pasti diam dan konsisten. Ini teknik paling tua dan paling aman; harganya adalah downtime penuh selama penyalinan.

Read lock global — perintah FLUSH TABLES WITH READ LOCK (FTWRL) mengunci seluruh table untuk penulisan sambil memaksa semua buffer kotor ditulis ke disk. Selama kunci terpasang, penyalinan file dari luar aman; perintah UNLOCK TABLES membuka kembali gerbang penulisan:

FLUSH TABLES WITH READ LOCK;
UNLOCK TABLES;

Output yang Dihasilkan:

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Dua statement di atas berjalan berturutan dalam satu sesi latihan kita. Di skenario sungguhan, jendela di antara keduanya — sesi lain menyalin file dari data directory, atau snapshot diambil — adalah jendela backup yang konsisten. Perlu dicatat pula bahwa FTWRL menunggu semua statement yang sedang berjalan selesai lebih dulu, sehingga pada server yang sedang menjalankan query panjang, perintah ini bisa terasa menggantung.

Snapshot storage — bila disk berada di volume LVM atau storage yang mendukung snapshot, kita cukup memasang FTWRL sesaat, mengambil snapshot volume (operasi detik), membuka kunci, lalu menyalin file dengan santai dari snapshot yang beku itu. Aplikasi hanya terganggu hitungan detik.

Hot backup khusus engine — MySQL Enterprise Backup, alat komersial dari Oracle, memahami format internal InnoDB sehingga bisa menyalin file sambil server tetap melayani tanpa kunci global. Di ekosistem open-source, alat pihak ketiga yang setara menempuh pendekatan serupa dengan menggabungkan salinan file plus potongan redo log untuk menambal halaman yang berubah selama penyalinan.

Cold Backup Manual (Konsep, Tanpa Demo) #

Cold backup layak dipahami sebagai pola, bukan sebagai latihan di server yang sedang kita pakai belajar — server latihan ini sengaja tidak boleh kita matikan karena sesi belajar bergantung padanya. Di mesin produksi ber-systemd, polanya berbentuk tiga langkah: hentikan server, salin seluruh data directory, jalankan kembali:

-- @notest
sudo systemctl stop mysql
sudo cp -a /var/lib/mysql /backup/mysql-2026-01-12
sudo systemctl start mysql

Opsi -a pada cp menjaga permission dan kepemilikan file — detail kecil yang menentukan apakah server mau menyala kembali dari salinan itu. Restore-nya kebalikan pola yang sama: server dimatikan, isi data directory yang lama disingkirkan, salinan diletakkan di tempatnya, server dinyalakan. Kesederhanaan pola ini menjadikannya favorit server kecil yang punya jendela maintenance — misalnya toko yang boleh mati pukul 03:00 dini hari.

Transportable Tablespace (Konsep) #

Untuk kebutuhan yang lebih selektif, InnoDB mendukung transportable tablespace: memindahkan satu table — satu file .ibd — antar server. Pola di sisi sumber: FLUSH TABLES produk FOR EXPORT membekukan table agar filenya siap disalin, lalu file .ibd plus file metadata .cfg disalin. Di sisi tujuan, table kosong dibuat lebih dulu dengan struktur identik, lalu ALTER TABLE produk DISCARD TABLESPACE membuang file data kosongnya dan ALTER TABLE produk IMPORT TABLESPACE memasangkan file yang kita bawa. Kombinasi ini cepat untuk memindahkan table raksasa, tetapi menuntut struktur yang persis sama di kedua sisi dan pemahaman detail InnoDB — terlalu dalam untuk latihan kita, cukup kita catat sebagai pintu yang ada.

Logical vs Physical: Memilih Strategi #

Ketika kita berada di baris terakhir tabel itu, diskusi bergeser dari backup ke high availability — topik yang menjadi section menjelang akhir course ini.

Referensi #

• Backup Methods — MySQL 8.4 Reference Manual
• Copying a Database from One Server to Another — MySQL 8.4 Reference Manual
• Backup and Recovery — MySQL 8.4 Reference Manual

Dua keluarga backup kini kita pegang kartu-kartunya: logical yang portabel dan selektif, physical yang cepat tapi menuntut konsistensi. Namun sejauh ini kita baru memproduksi file cadangan — belum pernah sekali pun memakainya untuk memulihkan database yang benar-benar hilang. Chapter berikutnya mengakhiri penundaan itu: kita menjatuhkan belajar_backup dengan sengaja, lalu membangkitkannya dari dump sambil mencatat setiap jebakan klasik restore.