Cara Backup Website + Database Otomatis (Rencana Disaster Recovery)

TL;DR

• backup website otomatis itu bukan cuma simpan file, tapi bikin rencana pemulihan saat ada error, hack, atau human error.
• Minimal: backup otomatis (file + database), disimpan di lokasi berbeda, dan rutin diuji restore-nya.
• Mulai dari yang sederhana dulu, yang penting konsisten dan bisa dipulihkan.

Kalau kamu punya website (blog, toko online kecil, landing page, apa pun), satu kebiasaan yang paling sering ditunda adalah: backup website otomatis. Masalahnya, kejadian buruk jarang ngasih sinyal. Bisa karena update plugin gagal, server penuh, database korup, credential bocor, atau sekadar kamu salah hapus folder. Di titik itu, kamu butuh dua hal: backup yang ada dan cara restore yang kamu ngerti.

Artikel ini fokus ke pendekatan yang praktis dan aman tanpa janji berlebihan. Kita akan bahas apa yang perlu dibackup, seberapa sering, disimpan di mana, dan checklist langkah yang bisa kamu eksekusi meski kamu bukan sysadmin. Targetnya: setelah baca, kamu bisa punya backup website otomatis yang jalan tiap hari (atau minimal tiap minggu), plus rencana disaster recovery yang masuk akal.

1) Apa Saja yang Harus Dibackup (Jangan Salah Prioritas)

Untuk kebanyakan situs berbasis CMS (WordPress, Ghost, Laravel, dan sejenisnya), komponen kritikalnya biasanya:

• Database: isi artikel, user, setting, komentar, transaksi. Ini paling penting.
• File aplikasi: theme, plugin, custom code, konfigurasi.
• Uploads / media: gambar, dokumen, video (kalau ada).
• Konfigurasi server (opsional tapi berguna): Nginx/Apache config, environment variables, cron.

Kalau kamu harus memilih karena keterbatasan waktu, mulai dari database + uploads. File aplikasi bisa diambil dari repo Git kalau kamu rapi versioning, tapi database dan uploads biasanya tidak.

2) Prinsip 3-2-1 Versi Realistis

Sering dengar prinsip backup 3-2-1: 3 salinan, 2 media berbeda, 1 offsite. Untuk skala personal atau UMKM, versi realistisnya begini:

• 1 backup lokal di server (cepat untuk restore kecil).
• 1 backup offsite (misalnya object storage atau drive terpisah).
• Retention: simpan harian 7 hari, mingguan 4 minggu (sesuaikan ruang).

Yang penting bukan sekadar punya backup, tapi backup itu tidak hilang saat server yang sama bermasalah.

3) Tentukan Frekuensi Backup: Harian, Mingguan, atau Tiap Jam?

Frekuensi ditentukan oleh seberapa sering data berubah dan seberapa besar kerugian kalau kamu kehilangan data terakhir.

• Blog pribadi: backup harian biasanya cukup.
• Website dengan update konten sering: harian + tambahan sebelum update besar.
• Website transaksi: idealnya lebih sering (bahkan per jam), tapi mulai dari harian dulu kalau resource terbatas.

Untuk banyak orang, backup otomatis harian sudah jadi lompatan besar dibanding “nanti aja”.

4) Strategi Sederhana: Backup Database + Folder Uploads

Konsep yang aman dan mudah:

1. Dump database ke file (misalnya .sql atau format yang disarankan sistem kamu).
2. Arsipkan uploads (misalnya folder content/images atau wp-content/uploads).
3. Kompres jadi satu paket (zip/tar.gz) supaya rapi.
4. Enkripsi bila backup keluar server (opsional tapi disarankan).
5. Kirim ke offsite (S3-compatible, drive, atau server lain).

Catatan penting: jangan menyimpan password atau token di script secara sembarangan. Gunakan environment variables atau file config yang permission-nya ketat.

5) Checklist Step-by-Step: Backup Website Otomatis (Versi Praktis)

Pakai checklist ini sebagai template. Kamu bisa menyesuaikan sesuai stack website kamu.

• [ ] Tentukan lokasi backup lokal (misalnya /var/backups/site/).
• [ ] Tentukan lokasi offsite (object storage atau server lain).
• [ ] Buat naming file yang konsisten: namaweb-YYYY-MM-DD.tar.gz.
• [ ] Backup database (dump) dan pastikan file hasilnya tidak kosong.
• [ ] Backup folder uploads/media.
• [ ] Kompres paket backup.
• [ ] Upload/sinkronisasi ke offsite.
• [ ] Terapkan retention (hapus backup lama otomatis).
• [ ] Buat notifikasi minimal (misalnya log file, atau email/telegram kalau gagal).
• [ ] Uji restore di lingkungan test (minimal 1x/bulan).

6) Disaster Recovery Plan: Apa yang Kamu Lakukan Saat Website Down

Backup tanpa rencana pemulihan itu setengah jalan. Disaster recovery plan versi ringkas:

1. Stabilkan dulu: stop perubahan (misalnya matikan deploy/auto update sementara).
2. Identifikasi jenis masalah: file hilang, database rusak, atau server mati total.
3. Pilih titik restore: backup terakhir yang “sehat”.
4. Restore bertahap: database dulu, lalu uploads, lalu konfigurasi.
5. Verifikasi: cek halaman penting, login, dan fungsi utama.
6. Catat: apa penyebabnya dan apa yang perlu diperbaiki supaya tidak terulang.

Tujuannya bukan jadi sempurna, tapi punya langkah yang jelas saat panik.

7) Kesalahan Umum yang Bikin Backup Tidak Kepakai

• Backup hanya di server yang sama: saat server jebol, backup ikut lenyap.
• Tidak pernah tes restore: baru sadar file rusak ketika dibutuhkan.
• Tidak ada retention: disk penuh, backup berhenti, kamu tidak sadar.
• Menumpuk file tanpa struktur: sulit cari backup yang benar.
• Mengandalkan “export manual” sesekali: lupa, tidak konsisten.

FAQ

1) Berapa lama sebaiknya menyimpan backup?

Mulai dari yang sederhana: simpan backup harian 7 hari dan backup mingguan 4 minggu. Kalau konten kamu jarang berubah, retention bisa lebih panjang. Sesuaikan dengan kapasitas storage.

2) Apakah perlu enkripsi untuk backup?

Kalau backup disimpan offsite atau di layanan pihak ketiga, enkripsi itu langkah aman. Minimal pastikan akses storage dibatasi dan token tidak bocor.

3) Backup otomatis itu cukup tanpa monitoring?

Idealnya ada monitoring, tapi kalau kamu baru mulai, minimal buat log dan cek secara rutin. Yang paling penting: backup berjalan dan bisa direstore.

Penutup: kalau kamu ingin cepat, mulai dari backup database harian dulu, lalu tambahkan uploads. Setelah itu, baru rapikan offsite dan jadwal retention. Yang penting konsisten. Itulah inti dari backup website otomatis.