Backup otomatis MySQL menggunakan mysqldump dan crontab memindahkan pekerjaan pencadangan database yang berulang menjadi jadwal server Linux. Cara ini banyak digunakan untuk aplikasi PHP dan website yang perlu menyimpan salinan data secara berkala. Namun, backup yang berhasil bukan sekadar file .sql.gz: kredensial harus terlindungi, perintah harus mendeteksi kegagalan, dan hasilnya perlu pernah dipulihkan pada lingkungan uji.
Tutorial lama yang saya gunakan untuk blog menggabungkan mysqldump, kompresi gzip, jadwal crontab -e, serta script backupsekarang.sh. Artikel ini mempertahankan konsep itu sekaligus memperbaiki praktik yang tidak aman, seperti menuliskan password database langsung setelah opsi -p atau membuat nama file dengan tanda persen yang keliru di dalam crontab. Agar pemulihan konsisten, pelajari juga tahapan membuat VPS web server.
Apa Itu Mysqldump dan Mengapa Masih Berguna?
mysqldump merupakan alat logical backup MySQL: data dan definisi tabel diekspor menjadi perintah SQL yang dapat digunakan untuk membuat ulang struktur serta mengimpor data. Metode ini memudahkan transfer antarsistem dan cukup praktis pada database dengan ukuran yang masih wajar. Untuk database besar, pertimbangkan durasi dump, beban I/O, dan waktu pemulihan; MySQL juga memiliki utilitas dump paralel pada MySQL Shell.
Flag --single-transaction berguna untuk memperoleh tampilan data yang konsisten pada tabel InnoDB ketika kondisi sesuai, tetapi bukan jaminan konsistensi untuk MyISAM atau perubahan skema bersamaan. Gunakan --quick agar baris dibaca secara bertahap, dan diskusikan kebutuhan menyertakan stored routines, events, serta triggers dengan administrator database. Pengaturan izin dan layanan server dapat dibandingkan dengan tutorial administrasi VPS Webuzo.
Plugin WordPress dapat mengubah data dan skema yang perlu dipertimbangkan dalam proses backup.
Pemeriksaan akses bot sesudah pemulihan juga berkaitan dengan crawling website.
Periksa fungsi sitemap bila website dipindahkan ke domain atau host baru.
Persiapan Keamanan dan Akun Backup
Gunakan user database khusus backup dengan hak akses paling kecil yang diperlukan. Izin seperti SELECT, SHOW VIEW, dan TRIGGER dapat dibutuhkan tergantung objek yang diekspor; jangan selalu memakai akun root. Tentukan directory backup /var/backups/mysql di luar document root, lalu pastikan hanya pengguna yang berwenang yang bisa membaca hasil dump.
Pada contoh lama, password ditulis langsung ke command line dan berisiko masuk history shell. Untuk proses otomatis, simpan koneksi database pada file opsi MySQL yang hanya dapat dibaca pengguna backup. Jangan memasukkan rahasia asli ke artikel, repository, atau log server: Penentuan user dan nama database bisa dimulai dari panduan pembuatan database MySQL.
# /root/.mysql-backup.cnf
[client]
user=backup_user
password=GANTI_DENGAN_RAHASIA_PRIVAT
host=127.0.0.1sudo chmod 600 /root/.mysql-backup.cnf
sudo install -d -m 700 /var/backups/mysqlUntuk database jarak jauh, perhatikan koneksi TLS dan validasi identitas host. Contoh di sini mengasumsikan perintah dijalankan pada VPS yang diizinkan dan script serta file rahasia dikelola oleh administrator yang sesuai.
Saat restore, verifikasi pula pengaturan caching Cloudflare supaya konten lama tidak terus muncul.
Kualitas pemulihan dapat dievaluasi bersama audit performa SEO.
Cara Menjalankan Mysqldump Secara Manual
Mulailah dari pengujian manual pada database percobaan atau database yang memiliki izin pencadangan. Ganti catperku_blog dengan nama database Anda. Hasil akan menjadi arsip yang bisa diverifikasi dengan gzip -t, tetapi pipeline singkat belum menangani status kegagalan mysqldump seteliti script produksi. Untuk mengenali struktur tabel sebelum backup, baca panduan pengelolaan phpMyAdmin.
mysqldump --defaults-extra-file=/root/.mysql-backup.cnf \
--single-transaction --quick --routines --events --triggers \
--databases catperku_blog | gzip -c > /var/backups/mysql/test.sql.gz
gzip -t /var/backups/mysql/test.sql.gzIngat, file kosong atau hasil dump parsial belum tentu terdeteksi hanya dengan memeriksa apakah arsip muncul. Gunakan penanganan kegagalan pipeline serta pemindahan atomik pada script berikut. Dokumentasi resmi menjelaskan bahwa operasi DDL bersamaan dengan snapshot MySQL juga bisa menimbulkan masalah konsistensi.
Pengujian pasca-restore sebaiknya turut mengecek performa loading blog.
Contoh Script backupsekarang.sh yang Lebih Aman
Script berikut menggunakan shell Bash, set -Eeuo pipefail, file sementara, dan pemeriksaan arsip. Bila mysqldump atau gzip gagal, perintah tidak melanjutkan pemindahan file sebagai backup final. Simpan sebagai /usr/local/sbin/backupsekarang.sh setelah menyesuaikan konfigurasi. Kebutuhan database dan file dapat dipahami saat mengikuti instalasi WordPress.
#!/usr/bin/env bash
set -Eeuo pipefail
umask 077
DIR="/var/backups/mysql"
DB="catperku_blog"
NOW="$(date +%F_%H-%M-%S)"
TMP="$(mktemp "$DIR/.tmpdump.XXXXXX")"
trap 'rm -f "$TMP"' EXIT
mysqldump --defaults-extra-file=/root/.mysql-backup.cnf \
--single-transaction --quick --routines --events --triggers \
--databases "$DB" | gzip -c > "$TMP"
test -s "$TMP"
gzip -t "$TMP"
mv -- "$TMP" "$DIR/$DB-$NOW.sql.gz"
echo "Backup sukses: $DB $NOW"Berikan izin eksekusi seperlunya, kemudian uji manual sebelum membuat job otomatis. Gunakan path absolut agar script tidak bergantung pada direktori kerja saat dijalankan dari cron.
sudo chmod 700 /usr/local/sbin/backupsekarang.sh
sudo /usr/local/sbin/backupsekarang.shMigrasi yang memengaruhi status HTTP memerlukan audit technical SEO.
Menjadwalkan Backup MySQL dengan Crontab
Jalankan sudo crontab -e bila root merupakan pemilik script dan file opsi yang digunakan. Contoh di bawah menjalankan backup setiap pukul 02.00 menurut timezone host; bukan otomatis pukul 02.00 WIB. Pastikan lokasi log bisa ditulis dan tidak menyimpan password. Perbedaan tanggung jawab backup antara layanan dapat diperiksa dalam pengertian hosting.
0 2 * * * /usr/local/sbin/backupsekarang.sh >> /var/log/mysql-backup.log 2>&1| Ekspresi | Frekuensi | Kegunaan |
|---|---|---|
0 2 * * * |
Harian pukul 02.00 | Backup umum website |
0 3 * * 0 |
Mingguan pada Minggu | Salinan interval panjang |
0 4 1 * * |
Bulanan tanggal 1 | Arsip historis |
0 * * * * |
Setiap jam | Database dengan perubahan cepat |
@reboot |
Setelah sistem boot | Bukan pengganti backup harian |
Alias @yearly, @monthly, @weekly, @daily, @hourly, dan @reboot berguna tetapi pengguna harus memahami implementasi cronnya. Tanda % pada perintah crontab mempunyai arti khusus jika tidak di-escape. Menaruh date +%F di file script, bukan langsung pada baris cron, membantu menghindari salah tafsir tersebut.
Jika URL berubah setelah migrasi, tinjau kembali indexing Google.
Strategi Retensi, Backup Offsite, dan Restore
Jika ingin mempertahankan backup lokal 14 hari, periksa file kandidat lebih dahulu tanpa menghapus apa pun: Mengapa database penting dijelaskan pula dalam pembahasan website dinamis.
find /var/backups/mysql -maxdepth 1 -type f \
-name 'catperku_blog-*.sql.gz' -mtime +14 -printPerintah find di atas hanya menampilkan daftar. Hapus file lama melalui kebijakan yang telah diuji setelah memastikan nama dan folder target benar; jangan menyalin perintah penghapusan massal tanpa review. Salin backup penting ke penyimpanan terpisah, terapkan enkripsi, dan pastikan kunci pemulihan disimpan aman.
Uji restorasi menggunakan server staging atau database pengujian, bukan instance produksi. Karena dump dengan --databases dapat menyertakan instruksi pemilihan database, periksa isinya terlebih dahulu agar tidak menimpa database aktif. Plugin WordPress dapat mengubah data dan skema yang perlu dipertimbangkan dalam proses backup.
gzip -t /var/backups/mysql/NAMA_FILE.sql.gz
gzip -dc /var/backups/mysql/NAMA_FILE.sql.gz \
| mysql --defaults-extra-file=/root/.mysql-restore-test.cnfFile .sql.gz yang valid secara kompresi tetap mungkin tidak dapat memulihkan fungsi aplikasi, misalnya jika data media atau konfigurasi server hilang. Dokumentasikan pengujian, ukuran arsip, jumlah tabel, encoding, tanggal dan langkah pemulihan. Jangan menjadikan snapshot VPS sebagai satu-satunya backup.
Kesalahan yang Sering Terjadi
| Masalah | Penyebab umum | Perbaikan |
|---|---|---|
| File backup tidak valid | Kegagalan dump tidak terlihat | Gunakan pipefail, gzip -t, uji restore |
| Cron tidak bekerja | PATH, permission, timezone | Jalankan sebagai user cron, cek log |
| Access denied | Privilege dan kredensial salah | Audit akun backup serta file opsi |
| Disk penuh | Retensi dan kapasitas diabaikan | Pantau storage dan salinan offsite |
| Restore gagal | Skema atau versi tidak kompatibel | Uji pada server staging yang cocok |
Backup database harus menjadi bagian dari manajemen website, bukan pekerjaan terpisah setelah downtime. Pengelola yang melakukan migrasi perlu menguji aplikasi, koneksi database, gambar, login serta HTTP status sebelum mengubah DNS bagi pengunjung. Pemindahan cadangan besar dapat memerlukan bandwidth jaringan yang cukup.
Pertanyaan yang Sering Diajukan (FAQ)
1. Apa fungsi mysqldump?
Mysqldump menghasilkan logical backup SQL yang memuat definisi dan data database.
2. Apa fungsi crontab?
Crontab menjadwalkan perintah secara otomatis pada sistem Linux menggunakan cron.
3. Apakah mysqldump memerlukan akses root?
Tidak selalu. Gunakan user database khusus dengan privilege yang cukup untuk objek yang dicadangkan.
4. Apa kegunaan –single-transaction?
Memungkinkan snapshot konsisten untuk tabel InnoDB pada kondisi yang didukung, namun tidak menjamin hal yang sama pada MyISAM.
5. Apakah gzip mengenkripsi backup?
Tidak. Gzip hanya mengompres data; gunakan enkripsi terpisah bila backup menyimpan informasi sensitif.
6. Apakah password boleh disimpan dalam script?
Sebaiknya tidak. Gunakan secret manager atau file opsi dengan izin terbatas.
7. Bagaimana membuat backup harian?
Uji script secara manual, lalu tambahkan jadwal seperti 0 2 * * * pada crontab user yang sesuai.
8. Mengapa file SQL ada tetapi backup gagal?
Pipeline tanpa deteksi kegagalan dapat menghasilkan file walaupun mysqldump tidak sukses; periksa exit code dan restore.
9. Di mana file backup sebaiknya disimpan?
Simpan di luar webroot dengan akses terbatas dan salinan terenkripsi pada lokasi terpisah.
10. Bagaimana menguji restore MySQL?
Pulihkan arsip ke staging yang terisolasi, kemudian periksa struktur, sampel data, dan fungsi aplikasi.
11. Apakah backup SQL sudah cukup bagi WordPress?
Belum. File media, tema, plugin, konfigurasi, dan sistem lain mungkin juga dibutuhkan.
12. Berapa lama file backup harus disimpan?
Sesuai kebutuhan bisnis, risiko, kewajiban hukum, target pemulihan, dan kapasitas penyimpanan.
