Otomasi Backup Data dari Server ke Google Drive Secara Terjadwal

TL;DR

• Backup ke Google Drive masuk akal untuk workload kecil sampai menengah jika prosesnya punya enkripsi, retensi, verifikasi, dan restore test.
• rclone sebaiknya dipakai sebagai transport layer, bukan sebagai satu-satunya logika backup.
• Backup dianggap sehat hanya jika arsip bisa dipulihkan, bukan hanya karena file berhasil terunggah.

Pendahuluan

Google Drive sering dipakai sebagai target backup karena murah, familiar, dan cepat dipasang. Itu valid untuk banyak VPS kecil, tetapi implementasi yang hanya berisi tar, rclone copy, dan cron harian biasanya gagal saat momen restore benar-benar datang. Masalahnya bukan pada Drive semata, melainkan pada pipeline backup yang tidak punya disiplin integritas.

Tutorial ini fokus pada jalur yang realistis untuk server Linux: dump data, arsipkan, enkripsi, unggah, verifikasi, dan jadwalkan secara aman. Targetnya bukan sistem backup enterprise penuh, tetapi baseline production-ready yang bisa diaudit dan diuji restore.

Prerequisites

• OS Linux berbasis Debian atau Ubuntu 22.04/24.04.
• Akses root atau user dengan sudo.
• Paket yang dibutuhkan: rclone, tar, gzip, gpg, jq, moreutils.
• Akun Google yang dipakai khusus untuk backup, bukan akun personal utama.
• Direktori data yang jelas, misalnya /srv/app/data.
• Jika ada database, pahami mekanisme dump yang konsisten untuk engine yang dipakai.

Problem di Production

Banyak backup terlihat sukses karena job selesai tanpa error, padahal arsip tidak pernah diverifikasi, token OAuth sudah tidak valid, atau dump database diambil pada state yang tidak konsisten. Saat incident datang, tim baru sadar bahwa yang disimpan hanyalah artefak, bukan jaminan pemulihan.

Mental Model

Pikirkan backup sebagai pipeline lima tahap: collect, dump, archive, encrypt, upload, verify. Setiap tahap harus menghasilkan bukti yang bisa diperiksa. Jika tidak ada bukti checksum, manifest, atau restore rehearsal, maka tahap berikutnya hanya memindahkan ketidakpastian ke cloud.

Konsep Utama

Backup file dan backup database tidak identik

Filesystem bisa diarsipkan langsung, tetapi database perlu dump yang konsisten. Mencampur keduanya tanpa disiplin biasanya menghasilkan backup yang tampak lengkap tetapi gagal di-restore.

Enkripsi harus dilakukan sebelum upload

Google Drive bukan boundary keamanan utama. Arsip sensitif sebaiknya sudah terenkripsi sebelum meninggalkan host.

Retensi lebih penting daripada sekadar menyimpan banyak file

Tanpa retensi, quota akan penuh. Saat quota penuh, backup terbaru justru yang gagal lebih dulu.

Arsitektur / Context

Arsitektur yang cukup sehat untuk VPS kecil biasanya seperti ini:

1. data aplikasi dan dump database dikumpulkan ke direktori staging
2. staging diarsipkan menjadi satu bundle per run
3. bundle dienkripsi dengan gpg
4. checksum dan manifest dibuat
5. rclone mengunggah artefak ke Google Drive
6. scheduler menjalankan job dan mencatat log lokal

Pola ini memisahkan proses pembentukan backup dari transport ke cloud. Jika upload gagal, tim tetap bisa melihat apakah artefak lokal berhasil dibuat dengan benar.

Practical Implementation

Step 1: Install dependency

sudo apt update
sudo apt install -y rclone gnupg jq moreutils

Pastikan host punya cukup ruang sementara untuk membuat arsip sebelum diunggah.

Step 2: Konfigurasi Google Drive remote

Jalankan konfigurasi interaktif sekali:

rclone config

Pilih n untuk remote baru, beri nama gdrive-backup, lalu pilih backend drive. Jika server tidak punya browser, gunakan mode headless dan salin URL otorisasi dari mesin lokal.

Verifikasi remote:

rclone lsd gdrive-backup:

Step 3: Siapkan direktori kerja backup

sudo mkdir -p /opt/backup/scripts
sudo mkdir -p /var/backups/staging
sudo mkdir -p /var/log/backup
sudo chown -R root:root /opt/backup /var/backups/staging /var/log/backup
sudo chmod 700 /opt/backup /var/backups/staging

Step 4: Buat kunci enkripsi atau import public key

Jika memakai public key GPG tim backup:

gpg --import backup-team-public.asc
gpg --list-keys

Gunakan recipient yang jelas, misalnya backup@example.com.

Step 5: Buat skrip backup

sudo tee /opt/backup/scripts/backup-to-gdrive.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

DATE="$(date +%F-%H%M%S)"
HOSTNAME="$(hostname -s)"
WORKDIR="/var/backups/staging/${HOSTNAME}-${DATE}"
ARCHIVE="/var/backups/staging/${HOSTNAME}-${DATE}.tar.gz"
ENCRYPTED="${ARCHIVE}.gpg"
MANIFEST="/var/backups/staging/${HOSTNAME}-${DATE}.json"
LOGFILE="/var/log/backup/backup.log"
REMOTE="gdrive-backup:server-backup/${HOSTNAME}"

mkdir -p "${WORKDIR}"

# Copy application data into staging.
rsync -a --delete /srv/app/data/ "${WORKDIR}/app-data/"

# Example PostgreSQL dump. Adjust if database engine differs.
pg_dump -U appuser -d appdb -Fc -f "${WORKDIR}/appdb.dump"

tar -C /var/backups/staging -czf "${ARCHIVE}" "$(basename "${WORKDIR}")"
gpg --batch --yes --recipient backup@example.com --encrypt "${ARCHIVE}"
sha256sum "${ENCRYPTED}" | awk '{print $1}' > "${ENCRYPTED}.sha256"

jq -n \
  --arg host "${HOSTNAME}" \
  --arg created_at "$(date --iso-8601=seconds)" \
  --arg file "$(basename "${ENCRYPTED}")" \
  --arg checksum "$(cat "${ENCRYPTED}.sha256")" \
  '{host: $host, created_at: $created_at, file: $file, checksum: $checksum}' > "${MANIFEST}"

rclone copy "${ENCRYPTED}" "${REMOTE}" --checksum
rclone copy "${ENCRYPTED}.sha256" "${REMOTE}" --checksum
rclone copy "${MANIFEST}" "${REMOTE}" --checksum

rm -rf "${WORKDIR}"
rm -f "${ARCHIVE}"

echo "$(date --iso-8601=seconds) backup completed ${ENCRYPTED}" | ts >> "${LOGFILE}"
EOF

Aktifkan permission eksekusi:

sudo chmod 700 /opt/backup/scripts/backup-to-gdrive.sh

Jika tidak memakai PostgreSQL, ganti bagian dump database dengan tool yang sesuai, misalnya mysqldump --single-transaction.

Step 6: Jalankan backup manual pertama

sudo /opt/backup/scripts/backup-to-gdrive.sh

Jangan langsung menjadwalkan cron sebelum satu run manual berhasil end-to-end.

Step 7: Jadwalkan dengan cron

sudo crontab -e

Tambahkan:

15 2 * * * /opt/backup/scripts/backup-to-gdrive.sh

Jika ingin log scheduler terpisah:

15 2 * * * /opt/backup/scripts/backup-to-gdrive.sh >> /var/log/backup/cron.log 2>&1

Step 8: Terapkan retensi di remote

Tambahkan job retensi mingguan:

sudo tee /opt/backup/scripts/prune-gdrive-backup.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
rclone delete gdrive-backup:server-backup/"$(hostname -s)" --min-age 30d
rclone rmdirs gdrive-backup:server-backup/"$(hostname -s)" --leave-root
EOF
sudo chmod 700 /opt/backup/scripts/prune-gdrive-backup.sh

Lalu jadwalkan:

30 3 * * 0 /opt/backup/scripts/prune-gdrive-backup.sh >> /var/log/backup/prune.log 2>&1

Verification

Pastikan file benar-benar muncul di remote:

rclone ls gdrive-backup:server-backup/$(hostname -s)

Cek log eksekusi terakhir:

tail -n 20 /var/log/backup/backup.log

Unduh satu artefak untuk validasi checksum:

rclone copy gdrive-backup:server-backup/$(hostname -s) ./restore-test --max-age 1d
cd restore-test
sha256sum -c *.sha256

Uji dekripsi:

gpg --output restore-test.tar.gz --decrypt *.tar.gz.gpg
tar -tzf restore-test.tar.gz | head

Sukses berarti:

• file terenkripsi, checksum, dan manifest ada
• checksum valid
• arsip bisa didekripsi
• isi arsip dapat dibaca tanpa error

Studi Kasus / Masalah Nyata

Backup harian sukses tetapi restore gagal

Kasus ini biasanya terjadi karena tim hanya memverifikasi upload, bukan isi arsip. Dump database korup atau direktori penting ternyata tidak ikut terbawa.

Quota Drive penuh diam-diam

Retention tidak pernah dibersihkan. Job mulai gagal setelah ruang habis, tetapi operator baru sadar beberapa hari kemudian.

Troubleshooting

OAuth token tidak valid

Gejala:

rclone lsd gdrive-backup:

mengembalikan error autentikasi.

Perbaikan:

rclone config reconnect gdrive-backup:

Backup script gagal karena permission

Pastikan user yang menjalankan job bisa membaca data sumber dan menulis ke staging:

sudo -l
sudo ls -lah /srv/app/data
sudo ls -lah /var/backups/staging

Dump database gagal

Jika pg_dump meminta password atau koneksi ditolak, siapkan kredensial lewat .pgpass atau environment yang aman. Jangan hardcode password di skrip.

Production Notes

• Pisahkan akun Google Drive backup dari akun personal.
• Simpan public/private key GPG di jalur yang terdokumentasi dan punya rotasi yang jelas.
• Tambahkan notifikasi jika job gagal, misalnya lewat webhook atau mail lokal.
• Lakukan restore rehearsal bulanan ke host terpisah.
• Untuk data yang lebih besar, pertimbangkan object storage yang lebih cocok untuk automation daripada consumer drive.

Trade-offs

• Google Drive murah dan mudah dipakai, tetapi tidak seideal object storage untuk volume besar atau automation intensif.
• Enkripsi sisi klien menambah keamanan, tetapi manajemen key menjadi tanggung jawab tim.
• Retensi panjang meningkatkan peluang recovery, tetapi mempercepat konsumsi quota.

Failure Modes

• Token OAuth kedaluwarsa dan job diam-diam gagal beberapa hari.
• Arsip berhasil diunggah, tetapi checksum atau dump database tidak valid.
• Retensi tidak berjalan sehingga quota habis dan backup terbaru tidak pernah tersimpan.

Best Practices

• Uji restore, bukan hanya upload.
• Pisahkan backup file dan dump database di staging agar lebih mudah diaudit.
• Simpan checksum dan manifest bersama artefak terenkripsi.
• Batasi jam eksekusi agar tidak mengganggu workload utama.

Kesalahan Umum

• mengunggah data sensitif tanpa enkripsi
• tidak punya retensi yang jelas
• tidak pernah memverifikasi checksum
• menganggap cron sukses sama dengan backup valid

Kesimpulan

Backup server ke Google Drive bisa menjadi solusi pragmatis untuk banyak VPS Linux, tetapi hanya jika pipeline-nya diperlakukan sebagai sistem operasional penuh. Fokus utamanya bukan mengirim file ke cloud, melainkan memastikan data bisa dipulihkan dengan integritas yang terukur dan prosedur yang tidak bergantung pada improvisasi.