Cara Melakukan Restore Database MariaDB & MySQL

Restore adalah momen backup benar-benar diuji — file backup yang tidak pernah dicoba di-restore sama sekali tidak bisa dianggap dapat diandalkan. Panduan ini menjelaskan cara restore database MariaDB/MySQL di qVM dari file hasil mysqldump, baik untuk satu database spesifik maupun seluruh instance, termasuk langkah verifikasi setelah proses selesai dan notifikasi Telegram ke tim.

Pengenalan

Restore dari mysqldump pada dasarnya adalah menjalankan ulang seluruh statement SQL di dalam file dump — CREATE DATABASE, CREATE TABLE, lalu INSERT baris demi baris (atau bulk insert apabila dump dibuat dengan --extended-insert, default MySQL/MariaDB). Untuk dataset besar, proses ini bisa memakan waktu signifikan karena MySQL/MariaDB harus membangun ulang index setelah data masuk.

Poin krusial yang sering terlewat: restore ke database yang sudah berisi data akan menyebabkan error Table already exists kecuali dump dibuat dengan opsi --add-drop-table (default aktif di mysqldump modern), yang otomatis menyisipkan DROP TABLE IF EXISTS sebelum CREATE TABLE. Efeknya: restore akan menimpa data yang ada di database tujuan, bukan menggabungkan. Selalu pastikan Anda restore ke tempat yang benar.

Panduan ini mengasumsikan Anda sudah punya file backup hasil mysqldump dalam format .sql atau .sql.gz.

Persyaratan

Software

• MariaDB atau MySQL Server sudah terpasang dan berjalan
• File backup hasil mysqldump (.sql atau .sql.gz)
• Akses root atau user dengan privilege CREATE, DROP, ALTER ke database tujuan

Hardware / Spesifikasi VPS qVM

Panduan ini menggunakan paket qVM-2, dengan spesifikasi:

• vCPU: 1 core
• RAM: 2 GiB
• Storage: 50 GiB

Pastikan storage tersedia minimal 2x ukuran file backup terkompresi (ruang untuk file .sql.gz, hasil ekstraksi sementara apabila diperlukan, dan data hasil restore itu sendiri).

Tahapan

1. Persiapan Sebelum Restore

Sebelum mulai, lakukan pengecekan berikut:

• Konfirmasi file backup mana yang akan dipakai, dan pastikan integritasnya:

gzip -t /var/backups/mysql/app_db_2026-08-16_02-00-00.sql.gz && echo "File valid"

• Apabila restore dilakukan ke database production yang sedang aktif dipakai, hentikan dulu aplikasi atau set ke maintenance mode, supaya tidak ada write yang terjadi bersamaan dengan proses restore (race condition antara restore dan aplikasi bisa menyebabkan data tidak konsisten).

• Sebagai jaring pengaman, backup dulu kondisi database saat ini sebelum di-overwrite, meski kondisinya bermasalah — restore yang salah sasaran jadi bisa di-rollback:

mysqldump -u root -p app_db | gzip > /var/backups/mysql/app_db_before_restore_$(date +%Y-%m-%d_%H-%M-%S).sql.gz

2. Restore Database Tunggal (Database Sudah Ada)

Apabila database tujuan sudah ada dan Anda cuma ingin restore isinya (menimpa data lama, karena mysqldump default menyertakan DROP TABLE IF EXISTS):

zcat /var/backups/mysql/app_db_2026-08-16_02-00-00.sql.gz | mysql -u root -p app_db

Untuk file .sql biasa (tidak terkompresi):

mysql -u root -p app_db < /var/backups/mysql/app_db_2026-08-16_02-00-00.sql

3. Restore ke Database Baru (Belum Ada)

Buat database kosong terlebih dahulu dengan charset yang sesuai, baru restore ke dalamnya:

mysql -u root -p -e "CREATE DATABASE app_db_restored CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

zcat /var/backups/mysql/app_db_2026-08-16_02-00-00.sql.gz | mysql -u root -p app_db_restored

Pola ini berguna untuk restore ke database dengan nama berbeda — misalnya untuk keperluan investigasi data lama tanpa mengganggu database production yang sedang berjalan.

4. Restore Full Instance (Semua Database Sekaligus)

Apabila backup dibuat dengan --all-databases (bukan per-database), restore-nya tidak perlu menyebut nama database — dump sudah menyertakan statement CREATE DATABASE dan USE untuk setiap database:

zcat /var/backups/mysql/full-backup_2026-08-16.sql.gz | mysql -u root -p

Untuk mempercepat restore dataset besar, nonaktifkan sementara foreign key check dan autocommit lewat session variable di awal file dump (banyak tool backup modern sudah menyisipkan ini otomatis):

SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;
-- ... proses restore ...
SET foreign_key_checks=1;
SET unique_checks=1;
COMMIT;

5. Restore Struktur Tanpa Data (Schema-Only)

Kadang dibutuhkan restore struktur tabel saja tanpa data — misalnya untuk setup environment staging. Filter dump dengan sed untuk membuang baris INSERT INTO:

zcat /var/backups/mysql/app_db_2026-08-16_02-00-00.sql.gz | \
  sed '/^INSERT INTO/d' | \
  mysql -u root -p app_db_staging

6. Verifikasi Setelah Restore

Jangan anggap restore berhasil hanya karena tidak ada error di terminal — verifikasi datanya:

mysql -u root -p app_db -e "SHOW TABLES;"

mysql -u root -p app_db -e "SELECT COUNT(*) FROM nama_tabel_penting;"

Bandingkan jumlah baris dan beberapa sample data dengan ekspektasi Anda (misalnya dari monitoring aplikasi sebelum backup diambil). Untuk tabel dengan foreign key, cek juga tidak ada orphaned row:

mysql -u root -p app_db -e "SELECT COUNT(*) FROM child_table WHERE parent_id NOT IN (SELECT id FROM parent_table);"

Query di atas seharusnya mengembalikan 0 — apabila tidak, ada inkonsistensi referential integrity yang perlu diinvestigasi lebih lanjut.

7. Kirim Notifikasi Setelah Restore Selesai (Opsional)

Restore biasanya dilakukan saat insiden — tim lain perlu tahu begitu prosesnya selesai (berhasil atau gagal), tanpa harus standby di terminal yang sama menunggu. Kirim notifikasi ke Telegram lewat Bot API setelah proses restore selesai.

Siapkan bot dan chat tujuan (cukup dilakukan sekali):

1. Chat ke @BotFather di Telegram, kirim /newbot, ikuti instruksinya, lalu catat bot token yang diberikan.
2. Tambahkan bot tersebut ke channel/group monitoring Anda, atau chat langsung ke bot-nya.
3. Kirim satu pesan apa saja ke bot/channel-nya, lalu ambil chat ID lewat endpoint getUpdates:

curl -s "https://api.telegram.org/bot<BOT_TOKEN>/getUpdates"

Cari nilai "chat":{"id": ... } pada response JSON — itulah CHAT_ID yang dipakai di bawah.

Bungkus command restore dengan pengecekan exit status, lalu kirim notifikasi sesuai hasilnya:

BOT_TOKEN="<BOT_TOKEN>"
CHAT_ID="<CHAT_ID>"

if zcat /var/backups/mysql/app_db_2026-08-16_02-00-01.sql.gz | mysql -u root -p app_db; then
  curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
    -d chat_id="${CHAT_ID}" \
    -d text="✅ Restore app_db di qVM 161.248.116.110 berhasil, selesai pada $(date)"
else
  curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
    -d chat_id="${CHAT_ID}" \
    -d text="❌ Restore app_db di qVM 161.248.116.110 GAGAL, cek log segera"
fi

Ganti <BOT_TOKEN> dan <CHAT_ID> dengan nilai milik bot dan channel monitoring Anda. Pola if ... then ... else ... fi ini memanfaatkan exit status dari mysql — non-zero (gagal) otomatis masuk ke cabang else, jadi notifikasi yang terkirim selalu mencerminkan hasil sebenarnya, bukan asumsi.

Kesimpulan

Restore database MariaDB/MySQL di qVM pada dasarnya straightforward — mysql < backup.sql atau zcat backup.sql.gz | mysql — tapi bagian yang sering diabaikan adalah persiapan sebelumnya (stop aplikasi, backup kondisi saat ini sebagai jaring pengaman), verifikasi sesudahnya (cek jumlah baris, referential integrity), dan komunikasi ke tim lewat notifikasi Telegram begitu proses selesai. Jadikan proses restore ini sebagai bagian dari disaster recovery drill rutin — coba restore backup terbaru ke environment terpisah secara berkala, supaya saat insiden sungguhan terjadi, prosesnya sudah teruji dan bukan langkah yang baru pertama kali dicoba di bawah tekanan.