Cara Membuat Backup Otomatis Website dengan Cron dan Strategi 3-2-1

Backup otomatis website bukan sekadar menyalin folder lalu berharap file itu bisa dipakai saat darurat. Backup yang benar harus mencakup data penting, berjalan terjadwal, disimpan terpisah, dipantau, dan—yang paling sering dilupakan—pernah diuji untuk restore.

CISA mendefinisikan backup sebagai salinan aman dari data penting yang disimpan terpisah dari sistem utama. Mereka juga menyarankan backup terjadwal dan recovery test untuk memeriksa integritas serta menyesuaikan target pemulihan bisnis.[1]

Di tutorial ini kita bikin fondasi yang praktis untuk website Linux/VPS: database dump, arsip file, checksum, cron, retensi, salinan off-site, dan simulasi restore. Contohnya generik, jadi sesuaikan path dan tool dengan stack lu.

💡 Tentukan dulu apa yang wajib dibackup

Jangan asal mengarsipkan seluruh server. Mulai dari komponen yang benar-benar dibutuhkan agar website bisa hidup lagi:

• database aplikasi;
• file upload pengguna dan media;
• source code yang belum tersimpan di Git remote;
• konfigurasi aplikasi yang diperlukan untuk pemulihan;
• dokumentasi versi runtime, dependency, dan langkah deploy.

Cache, file log lama, dependency yang bisa diunduh ulang, dan folder build sementara biasanya tidak perlu masuk setiap backup. Semakin jelas ruang lingkupnya, semakin cepat proses backup dan restore.

Jangan menaruh password database langsung di skrip. Untuk MySQL/MariaDB, gunakan file konfigurasi client dengan permission ketat atau mekanisme secret management yang sesuai server. Backup yang berisi credential terbuka justru menambah masalah baru.

🔐 Pakai strategi backup 3-2-1

Aturan 3-2-1 berarti punya tiga salinan data, memakai dua jenis media atau lokasi penyimpanan, dan menyimpan satu salinan di luar lokasi utama. CISA merekomendasikan pola ini sekaligus backup yang berjalan otomatis dan rutin.[1]

Contoh sederhana untuk website:

• Salinan 1: data aktif di VPS;
• Salinan 2: backup lokal di disk atau volume terpisah;
• Salinan 3: backup terenkripsi di object storage atau server off-site.

Salinan lokal membantu restore cepat, sedangkan salinan off-site melindungi saat VPS, akun hosting, atau lokasi utama bermasalah. Untuk menghadapi ransomware, CISA juga menganjurkan backup offline atau terlindungi, terenkripsi, dan diuji secara rutin.[2]

⚙️ Buat skrip backup yang gagal dengan jelas

Contoh berikut memakai Bash, mysqldump, tar, dan sha256sum. Simpan misalnya sebagai /home/user/bin/backup-website.sh. Ganti path dan nama database sesuai environment lu.

#!/usr/bin/env bash
set -Eeuo pipefail
umask 077

APP_DIR="/var/www/website"
BACKUP_DIR="/srv/backups/website"
DB_NAME="nama_database"
STAMP="$(date +%Y%m%d-%H%M%S)"
DEST="$BACKUP_DIR/$STAMP"

mkdir -p "$DEST"

# Credential dibaca dari konfigurasi client, bukan ditulis di skrip.
mysqldump --single-transaction --routines --triggers "$DB_NAME" \
  | gzip -9 > "$DEST/database.sql.gz"

tar --exclude='writable/cache' \
    --exclude='writable/logs' \
    -czf "$DEST/files.tar.gz" \
    -C "$APP_DIR" public/uploads .env.example composer.json composer.lock

( cd "$DEST" && sha256sum database.sql.gz files.tar.gz > SHA256SUMS )

printf '%s backup selesai: %s\n' "$(date --iso-8601=seconds)" "$DEST"

set -Eeuo pipefail membantu skrip berhenti saat ada error, variabel kosong, atau salah satu proses dalam pipeline gagal. umask 077 membuat file baru tidak terbuka untuk user lain secara default.

Daftar file aplikasi harus disesuaikan. Kalau file .env produksi memang wajib masuk backup, simpan hanya di arsip terenkripsi dan batasi aksesnya. Jangan pernah mengunggah arsip tersebut ke repositori publik.

⏰ Jadwalkan dengan cron

Crontab berisi instruksi untuk menjalankan perintah pada waktu tertentu, dan job berjalan sebagai user pemilik crontab.[3] Karena environment cron lebih terbatas daripada terminal interaktif, pakai path absolut dan arahkan output ke log.

Buka crontab user khusus backup dengan crontab -e, lalu tambahkan:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

30 2 * * * /home/user/bin/backup-website.sh >> /home/user/logs/backup-website.log 2>&1

Baris itu menjalankan backup setiap hari pukul 02:30 berdasarkan waktu server. Pastikan timezone server sesuai ekspektasi. Kalau website ramai pada jam tersebut, ukur dampak I/O dan pilih jadwal yang lebih sepi.

Sebelum menunggu cron, jalankan skrip sekali secara manual dengan user yang sama. Periksa exit code, isi log, ukuran arsip, checksum, dan apakah database dump benar-benar terisi.

🧹 Terapkan rotasi tanpa menghapus file yang salah

Backup tanpa retensi bisa memenuhi disk. Namun perintah hapus yang terlalu luas juga berbahaya. Gunakan direktori khusus backup, validasi variabel, lalu tampilkan kandidat terlebih dahulu:

find "/srv/backups/website" -mindepth 1 -maxdepth 1 \
  -type d -mtime +14 -print

Setelah hasilnya benar-benar sesuai, logika rotasi boleh ditaruh di skrip. Lebih aman lagi memakai tool backup yang mendukung retention policy, snapshot, enkripsi, dan verifikasi bawaan. Jangan menambahkan -delete sebelum path serta hasil seleksinya sudah diuji.

Pantau juga kapasitas disk sebelum proses dimulai. Backup yang gagal karena ruang habis harus menghasilkan notifikasi, bukan diam-diam dianggap sukses.

☁️ Kirim salinan terenkripsi ke lokasi off-site

Setelah backup lokal valid, sinkronkan satu salinan ke penyimpanan lain menggunakan tool yang mendukung enkripsi dan verifikasi. Gunakan akun dengan izin minimum: hanya bucket atau direktori backup yang diperlukan.

Hindari menyimpan satu-satunya salinan cadangan pada VPS yang sama. Kalau akun atau filesystem utama rusak, backup lokal bisa ikut hilang. Idealnya lokasi off-site punya versioning atau perlindungan agar file tidak mudah ditimpa dan dihapus oleh credential aplikasi.

✅ Uji restore, bukan cuma uji file

Checksum hanya membuktikan file tidak berubah sejak dibuat; checksum belum membuktikan aplikasinya bisa dipulihkan. Buat jadwal restore test ke environment terisolasi, jangan menimpa production.

1. Ambil satu set backup tanpa memilih yang paling nyaman.
2. Verifikasi dengan sha256sum -c SHA256SUMS.
3. Ekstrak file ke direktori sementara.
4. Restore database ke database pengujian.
5. Pasang konfigurasi test, lalu buka halaman penting.
6. Catat durasi, error, dan langkah manual yang masih diperlukan.

Dari sini lu bisa menilai RPO (berapa banyak data terbaru yang boleh hilang) dan RTO (berapa lama layanan boleh pulih). CISA menyebut scheduled recovery test sebagai bagian penting untuk memeriksa integritas backup dan menyempurnakan RPO/RTO.[1]

⚠️ Kesalahan backup otomatis website yang sering kejadian

• Backup tersimpan di disk yang sama: cepat, tapi tidak cukup untuk kegagalan disk atau kompromi akun.
• Cuma backup source code: upload dan database justru sering menjadi data yang paling sulit dibuat ulang.
• Tidak ada monitoring: cron bisa gagal karena permission, disk penuh, perubahan path, atau tool yang hilang.
• Tidak pernah restore test: arsip ada, tetapi ternyata dump kosong atau prosedurnya tidak lengkap.
• Credential bocor: password ditulis di skrip, log, chat, atau repository.
• Retention terlalu agresif: seluruh backup lama dihapus sebelum salinan baru terbukti valid.

Kalau lu tertarik pada keamanan sistem otomatis secara lebih luas, artikel Kuskuskuy tentang prompt injection pada AI agent membahas prinsip serupa: data dari luar tidak boleh otomatis dipercaya sebagai instruksi.

📌 Checklist implementasi

• Data kritis sudah diinventarisasi.
• Database dan file upload masuk backup.
• Credential tidak ditulis terang di skrip.
• Skrip berhenti dan memberi log saat gagal.
• Cron memakai path absolut dan user yang tepat.
• Ada retensi lokal yang sudah diuji dengan mode tampilkan dulu.
• Ada salinan off-site terenkripsi.
• Checksum diverifikasi.
• Restore test dilakukan secara berkala di environment terisolasi.
• Notifikasi kegagalan benar-benar diterima manusia.

Kesimpulan

Backup otomatis website yang matang punya empat unsur: jadwal yang konsisten, strategi 3-2-1, monitoring yang jelas, dan restore test. Cron hanya pemicu; kualitas backup ditentukan oleh isi, pemisahan lokasi, keamanan credential, dan kemampuan memulihkan layanan saat dibutuhkan.

Mulai dari satu website dan satu jadwal harian. Setelah skrip teruji, tambahkan off-site storage, retensi, alert, lalu latihan restore. Di Kuskuskuy, pendekatan bertahap seperti ini lebih masuk akal daripada automation besar yang terlihat canggih tetapi tidak pernah diuji saat kondisi darurat.

Sumber

[1] CISA — Back Up Business Data.

[2] CISA — #StopRansomware Guide.

[3] Linux man-pages — crontab(5).

Featured image: hard disk drive karya William Warby, Unsplash; tersedia gratis berdasarkan Unsplash License. Cek ketentuan lisensi terbaru sebelum penggunaan komersial.