Logical Backup

Keluarga backup pertama yang kita praktikkan bekerja dengan cara yang hampir kekanak-kanakan: ia membaca database kita, lalu menuliskan perintah SQL yang akan membangun kembali database tersebut bila dijalankan ulang dari nol. Inilah logical backup — keluarga backup paling tua, paling portabel, dan paling sering dipakai administrator database di seluruh dunia. Chapter ini membedah cara kerjanya di balik layar, menimbang kekuatan dan kelemahannya secara jujur, lalu memperkenalkan alat-alatnya — termasuk satu jalur ekspor yang dikecualikan variabel keamanan secure_file_priv di server latihan kita, sebuah realita yang layak diketahui sebelum kita menabraknya di produksi.

Cara Kerja Logical Backup #

Sebuah logical backup adalah file teks berisi statement SQL yang tersusun dalam urutan yang masuk akal: CREATE TABLE untuk merekonstruksi struktur, lalu INSERT untuk mengisi kembali baris-barisnya. Restore pada hakikatnya bukan “menyalin kembali” data, melainkan memutar ulang perintah-perintah itu di server tujuan, persis seperti menjalankan file skema yang kita kenal di section persiapan lingkungan. Server tujuan tidak pernah tahu bahwa baris-barisnya berasal dari server lain — ia hanya menjalankan SQL seperti biasa.

Konsekuensi model kerja ini menjelaskan hampir semua sifat logical backup. Karena hasilnya teks SQL murni, file dump bisa dibuka, dibaca, dan disunting dengan editor apa pun, serta bisa dijalankan di versi MySQL lain atau bahkan engine lain yang kompatibel SQL-nya. Sebaliknya, karena restore harus memutar ulang statement satu per satu, kecepatan pemulihan dibatasi kecepatan server memproses INSERT — sebuah baris data besar tetap harus masuk lewat jalur SQL, melewati parsing, pemeriksaan constraint, dan penulisan ke storage engine.

Kelebihan dan Kelemahan #

Kombinasi “portabel tapi lambat” ini membuat logical backup menempati posisi manis untuk database kecil hingga menengah — kira-kira hingga puluhan gigabyte. Pada ukuran itu, dump penuh masih selesai dalam menit dan restore masih masuk akal dalam batas RTO. Melampaui itu, waktu restore yang memanjang mulai melanggar RTO dan keluarga physical backup (chapter setelah mysqldump) mengambil alih.

Alat-Alat Logical Backup #

Alat utama keluarga ini adalah mysqldump — program client yang terpasang bersama server MySQL sejak puluhan tahun dan akan kita gunakan tuntas di chapter berikutnya. mysqldump menghasilkan dump format SQL, mendukung mode tab-delimited untuk ekspor data mentah, dan menjadi patokan de facto yang dikenal setiap dokumentasi dan tutorial.

Saudaranya, mysqlpump, pernah diperkenalkan sebagai generasi baru dengan parallelism — memproses banyak table sekaligus untuk mempercepat dump. Namun mysqlpump resmi ditandai deprecated sejak MySQL 8.0.34, distribusi minimal MySQL 8.4 yang kita pakai bahkan tidak lagi menyertakan binary-nya, dan masa depannya adalah penghapusan. Praktik yang benar untuk proyek baru: bangun seluruh alur backup di atas mysqldump atau alat physical, dan perlakukan mysqlpump hanya sebagai pengetahuan sejarah saat membaca dokumentasi lama.

Jalur Ekspor Data Mentah: SELECT … INTO OUTFILE #

Sebelum mengangkat mysqldump ke panggung utama, mari kita uji jalur logical backup paling “asli”: SELECT ... INTO OUTFILE, yang menulis hasil query langsung menjadi file data di sisi server — bukan file SQL, melainkan baris data terpisah delimiter. Jalur ini dipadankan LOAD DATA saat memuatnya kembali, dan kombinasi keduanya dikenal sebagai jalur impor-ekspor tercepat di MySQL karena melewati pembentukan statement SQL. Siapkan dulu data latihan:

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

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

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

Output yang Dihasilkan:

Perintah ini berhasil di server mana pun karena hanya statement standar. Hasil yang berbeda justru muncul ketika kita mencoba menulis file dari dalam SQL — dan hasilnya ditentukan sebuah variabel server bernama secure_file_priv. Mari kita periksa nilainya di server latihan:

SHOW VARIABLES LIKE 'secure_file_priv';

Output yang Dihasilkan:

+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| secure_file_priv | NULL  |
+------------------+-------+
1 row in set (0.00 sec)

Nilai NULL pada secure_file_priv berarti server menolak seluruh operasi file dari dalam SQL — INTO OUTFILE dan LOAD DATA INFILE sama-sama dicekal. Nilai ini sengaja dipilih sebagai bawaan banyak distribusi karena operasi file dari SQL membuka celah: penulis query sembarang bisa menaruh file di lokasi sensitif atau membaca file yang seharusnya tidak terbaca. Sekarang kita buktikan cekal itu benar-benar bekerja:

-- @error
SELECT id, nama, harga FROM produk INTO OUTFILE '/tmp/produk-latihan.tsv';

Output yang Dihasilkan:

Query OK, 0 rows affected (0.00 sec)

ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
Bye

Error 1290 inilah realita yang akan kita temui di instalasi yang ketat. Di server produksi yang mengizinkan, administrator justru mengatur secure_file_priv ke satu direktori khusus — misalnya /var/lib/mysql-files/ — sehingga ekspor hanya boleh menulis ke sana dan bisa dipantau. Tiga kemungkinan nilai secure_file_priv merangkum perilakunya: NULL berarti semua operasi file dalam SQL dilarang; string kosong '' berarti boleh menulis ke lokasi mana pun (paling longgar, paling berisiko); dan sebuah path berarti hanya direktori itu yang diizinkan.

LOAD DATA dan mysqldump –tab (Prosa) #

Pasangan INTO OUTFILE adalah LOAD DATA INFILE yang membaca file kembali menjadi baris table. Keduanya berbagi satu nasib di server kita: karena secure_file_priv bernilai NULL, keduanya tidak bisa didemokan di sini. Konsepnya tetap penting dipahami karena mysqldump punya mode --tab yang menggabungkan keduanya: untuk tiap table, mysqldump --tab=/direktori/ belajar_backup menghasilkan file produk.sql berisi struktur plus file produk.txt berisi data tab-delimited. Mode ini jauh lebih cepat dari dump SQL biasa untuk data besar, tetapi menuntut dua prasyarat yang tidak dimiliki semua lingkungan: variabel secure_file_priv yang mengizinkan server menulis ke direktori output, dan akses filesystem yang sama antara kita dan server. Bila salah satu tidak terpenuhi, kembali ke dump SQL biasa — itulah alasan mode --tab kita perlakukan sebagai pengetahuan, bukan latihan.

Kapan Memilih Logical Backup #

Rangkum keputusannya dalam tiga pertanyaan. Pertama, apakah ukuran data masih di kisaran puluhan gigabyte ke bawah dan jendela restore cukup longgar? Logical layak. Kedua, apakah hasil backup perlu dibaca, diaudit, atau dipindahkan lintas versi dan platform? Logical unggul. Ketiga, apakah kita butuh mencadangkan bagian-bagian tertentu saja — satu database, satu table, bahkan hasil query tertentu? Logical satu-satunya keluarga yang selektif itu secara alami. Bila ketiga jawaban itu mulai terbalik — data ratusan gigabyte, restore harus hitungan menit, seluruh server dicadangkan utuh — arah keputusan berpindah ke physical backup, yang kita bedah dua chapter ke depan setelah mahir mengendarai mysqldump.

Referensi #

• mysqldump — A Database Backup Program — MySQL 8.4 Reference Manual
• mysqlpump — MySQL 8.4 Reference Manual
• Backup Methods — MySQL 8.4 Reference Manual

Peta sudah tergambar: hasil berupa SQL, kuat di portabilitas, lemah di kecepatan, dan dua jalur ekspornya — dump SQL serta ekspor data mentah — dengan syaratnya masing-masing. Chapter berikutnya mengangkat alat terpenting keluarga ini ke meja praktik: mysqldump, dari dump pertama sampai opsi-opsi yang membedakan backup asal-asalan dari backup yang layak dipertaruhkan.