WIKI TKJ

Linux : Backup Otomatis dengan rsync, tar, dan cron

Banyak server mati bukan karena disknya meledak, tapi karena tidak ada satu orang pun yang pernah mencoba memulihkan salinannya. Backup bukan perintah menyalin file, tapi janji bahwa data bisa kembali. Artikel ini membahas backup sebagai sistem tiga lapis: yang menyalin, yang menjadwalkan, dan yang membuktikan.

🎯 Tujuan

Setelah membaca dan mempraktikkan artikel ini, kamu bisa:

  • membedakan salinan biasa, sinkronisasi, snapshot, dan backup yang benar;
  • memilih kapan memakai rsync dan kapan memakai tar;
  • menulis script backup yang berhenti dan berteriak kalau gagal, bukan diam-diam;
  • menjadwalkan backup harian dengan cron tanpa jebakan PATH dan format;
  • membuktikan bahwa backup benar-benar bisa dipulihkan, bukan cuma "file-nya ada".

💡 Tips: satu kalimat penentu sebelum kamu percaya pada backup — kalau belum pernah di-restore, statusnya masih "mungkin".

📍 Konteks nyata

Bayangkan kamu memfotokopi semua dokumen penting sekolah, lalu menyimpannya di lemari ruang guru. Fotokopinya ada, tebal, rapi. Tapi kalau ruang guru yang kebakaran, fotokopinya ikut hilang. Backup bekerja dengan logika yang sama: salinan harus berada di tempat yang tidak ikut mati bersama aslinya.

Di lab TKJ, objek yang paling sering perlu backup justru sederhana: folder nilai praktik, file konfigurasi layanan, database aplikasi ujian, dan foto kegiatan. Ukurannya tidak besar, tapi kalau hilang, urusannya bisa berminggu-minggu.

🔥 Kasus nyata: sebuah SMK punya "backup" rapor yang ternyata hanya folder salinan di disk yang sama dengan datanya. Saat HDD server mati menjelang pembagian rapor, dua semester nilai ikut hilang. Guru harus merekap ulang dari kertas dan spreadsheet lama — dua minggu kerja, ditambah kepercayaan orang tua yang rusak. Satu disk tidak pernah menjadi dua salinan.

Tabel berikut membedakan hal-hal yang sering disebut backup padahal belum.

Yang dilakukan Terlihat aman karena Kenapa belum backup
copy ke folder lain di disk yang sama file jadi dua disk mati, dua-duanya hilang
RAID 1 atau RAID 5 satu disk mati server tetap jalan RAID menyalin kerusakan dan penghapusan juga
snapshot VM bisa rollback cepat biasanya di storage yang sama, dan bisa ikut terhapus
sinkronisasi tiap jam isi selalu "sama persis" file yang terhapus hari ini ikut terhapus di tujuan

📊 Angka penting: aturan populer 3-2-1 — tiga salinan, dua jenis media berbeda, satu di lokasi lain. Versi realistis untuk lab sekolah: server, disk eksternal yang dicabut setelah backup, dan satu salinan di VM atau cloud sekolah.

🧠 Konsep singkat

Backup yang sehat selalu bisa dijawab dengan empat pertanyaan. Kalau satu pertanyaan belum dijawab, biasanya masalahnya baru ketahuan saat data sudah hilang.

🔹 Empat pertanyaan sebelum menekan Enter

Pertanyaan Jawaban yang benar Contoh jawaban yang berbahaya
Apa yang disalin? daftar folder, file config, dan hasil dump database "semua saja, dari / "
Ke mana? media dan lokasi berbeda dari sumber folder lain di disk yang sama
Kapan dan berapa lama? jadwal jelas + retensi, misal 7 harian "tiap hari, disimpan selamanya"
Sudah pernah dipulihkan? ada catatan uji restore dan tanggalnya "belum, tapi kayaknya aman"

🔹 Tiga lapis: penyalin, penjadwal, pembukti

Lapis Alat Gejala kalau lapis ini gagal
Penyalin rsync, tar file ada, tapi tidak lengkap atau rusak
Penjadwal cron, systemd timer backup tidak pernah jalan dan tidak ada yang sadar
Pembukti log, exit code, uji restore backup rajin jalan, tapi tidak bisa dipakai

Analogi gampangnya: penyalin itu tukang pindah barang, penjadwal itu alarm pengingat, dan pembukti itu berita acara serah terima. Barang sudah dipindah belum tentu sampai dengan selamat — dan berita acara itulah yang kamu pegang saat panik.

🔹 rsync: yang pindah hanya bedanya

rsync terkenal karena algoritma delta-transfer: hanya bagian file yang berbeda yang dikirim. Untuk backup harian, ini menghemat waktu dan bandwidth luar biasa.

Tapi ada satu detail yang wajib kamu tahu. Pemeriksaan cepat bawaan rsync hanya melihat dua hal: ukuran file dan waktu modifikasi terakhir. Bukan isi file.

Akibatnya, file yang isinya berubah tetapi ukuran dan waktunya dipertahankan akan dianggap "tidak berubah" dan dilewati. Ini sering terjadi pada file yang dipulihkan dari arsip, aplikasi lama, atau server yang jamnya pernah mundur.

⚠️ Hati-hati: jangan mengandalkan rsync untuk mendeteksi perubahan isi secara mutlak. Kalau butuh benar-benar yakin, pakai --checksum. Lebih lambat karena membaca seluruh isi file, tapi tidak bisa tertipu waktu modifikasi.

Satu jebakan lagi: garis miring di akhir path sumber mengubah arti perintah.

  • rsync -av /data/nilai /backup/ menghasilkan /backup/nilai/...
  • rsync -av /data/nilai/ /backup/ menghasilkan isi folder langsung di /backup/

Dokumentasi rsync menyebut garis miring di akhir berarti "salin isi direktori ini", sedangkan tanpa garis miring berarti "salin direktori ini beserta namanya". Salah satu garis miring bisa membuat folder backup bersarang dua tingkat tanpa kamu sadari.

🔹 tar: satu file, satu titik waktu

tar mengemas banyak file menjadi satu arsip. Bentuknya beda dengan rsync: tar tidak menyamakan isi, tapi mengambil potret pada satu waktu, lalu membungkusnya jadi satu file.

Kelebihannya: mudah dipindah, mudah dihitung checksum-nya, dan mudah disimpan ke media lepas. Kekurangannya: setiap kali jalan, hasilnya arsip penuh — kecuali kamu memakai mode incremental dengan file snapshot.

📊 Angka penting: tar punya tiga kode keluar yang penting. 0 berhasil, 1 ada file yang berubah saat diarsipkan, dan 2 gagal fatal. Arsip yang "ada" tapi kode keluarnya 2 adalah arsip yang tidak bisa dipulihkan.

⚠️ Hati-hati: tar -czf hanya mengompres, bukan mengunci dan bukan mengenkripsi. Siapa pun yang memegang file arsipnya bisa membukanya.

🧩 Istilah penting

Istilah Arti singkat
rsync alat penyalin yang hanya memindahkan bagian file yang berubah
delta-transfer teknik mengirim perbedaan file, bukan seluruh isi
hardlink dua nama file menunjuk isi yang sama di disk, hemat ruang
--link-dest opsi rsync untuk membuat snapshot baru dari hardlink snapshot lama
arsip satu file berisi banyak file, hasil kerja tar
incremental hanya menyimpan yang berubah sejak backup sebelumnya
retensi aturan berapa lama backup disimpan sebelum dihapus
RPO berapa banyak data yang boleh hilang, dihitung dalam waktu
RTO berapa lama layanan boleh mati saat pemulihan
dry run menjalankan perintah tanpa benar-benar mengubah apa pun
exit code angka hasil akhir perintah, penentu berhasil atau gagal

Dua istilah terakhir yang paling sering dilupakan: RPO dan RTO. Backup harian berarti RPO-mu sekitar 24 jam — kamu siap kehilangan data satu hari. Kalau itu tidak bisa diterima, jadwalnya harus lebih rapat, bukan alatnya yang diganti.

🔧 Praktik: backup otomatis harian di VM Debian

Lab ini memakai folder sendiri di /srv/lab-backup, jadi tidak menyentuh data produksi. Semua langkah bisa diulang dan dihapus tanpa risiko.

🔹 Langkah 1: siapkan bahan uji

sudo mkdir -p /srv/lab-backup/{sumber,tujuan,log}
sudo mkdir -p /srv/lab-backup/sumber/foto
sudo dd if=/dev/urandom of=/srv/lab-backup/sumber/nilai.csv bs=1M count=8 status=none
for i in $(seq 1 20); do
  sudo dd if=/dev/urandom of=/srv/lab-backup/sumber/foto/f$i.jpg bs=64K count=1 status=none
done
sudo chown -R "$USER": /srv/lab-backup
du -sh /srv/lab-backup/sumber

Delapan megabyte file utama dan 20 file kecil sudah cukup untuk melihat perbedaan ukuran snapshot. Kalau hardlink bekerja, snapshot kedua tidak akan menambah 8 MB lagi.

🔹 Langkah 2: latihan rsync tanpa mengubah apa pun

rsync -avn --itemize-changes /srv/lab-backup/sumber/ /srv/lab-backup/tujuan/

Opsi -n adalah dry run, -i menampilkan ringkasan perubahan per file. Perhatikan awalan pada tiap baris: >f berarti file akan dikirim.

🧪 Uji cepat: jalankan dua versi ini dan bandingkan struktur hasilnya. 

rsync -avn /srv/lab-backup/sumber  /tmp/uji-tanpa-garis/
rsync -avn /srv/lab-backup/sumber/ /tmp/uji-dengan-garis/

Yang pertama membuat /tmp/uji-tanpa-garis/sumber/, yang kedua menaruh isinya langsung di /tmp/uji-dengan-garis/. Coba tebak dulu sebelum menjalankan — ini cara tercepat mengingat bedanya.

Simpan sebagai /usr/local/bin/backup-lab.sh. 

#!/bin/bash
set -u
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export PATH

SUMBER="/srv/lab-backup/sumber/"
TUJUAN="/srv/lab-backup/tujuan"
LOG="/srv/lab-backup/log/backup.log"
SNAP="$TUJUAN/$(date +%F_%H%M)"

mkdir -p "$TUJUAN" "$(dirname "$LOG")"

LINK=""
if [ -d "$TUJUAN/terakhir" ]; then
  LINK="--link-dest=$TUJUAN/terakhir"
fi

rsync -a --delete $LINK "$SUMBER" "$SNAP" >> "$LOG" 2>&1
KODE=$?

if [ "$KODE" -eq 0 ] || [ "$KODE" -eq 24 ]; then
  rm -f "$TUJUAN/terakhir"
  ln -s "$SNAP" "$TUJUAN/terakhir"
  echo "$(date -Is) OK kode=$KODE snapshot=$SNAP" >> "$LOG"
else
  echo "$(date -Is) GAGAL kode=$KODE snapshot=$SNAP" >> "$LOG"
  exit "$KODE"
fi

Tiga hal yang membuat script ini berbeda dari perintah copy biasa:

  • --link-dest membuat file yang tidak berubah menjadi hardlink ke snapshot sebelumnya, jadi tidak memakan ruang lagi;
  • kode keluar diperiksa, bukan diabaikan; kode 24 diterima karena artinya hanya "ada file yang berubah saat disalin";
  • kalau gagal, script keluar dengan kode gagal sehingga cron punya alasan untuk berteriak.

Tambahkan rotasi sederhana di akhir script, misalnya menyimpan tujuh hari terakhir: 

find "$TUJUAN" -maxdepth 1 -type d -name '20*' -mtime +6 -exec rm -rf {} +

Karena snapshot baru memakai hardlink, menghapus snapshot lama tidak menghapus data yang masih dipakai snapshot yang lebih baru. Ini keuntungan besar dibanding menyalin folder penuh setiap hari.

🔹 Langkah 4: jalankan manual dan lihat buktinya

sudo install -m 755 /dev/null /usr/local/bin/backup-lab.sh
# salin isi script di atas, lalu:
sudo chmod 755 /usr/local/bin/backup-lab.sh
/usr/local/bin/backup-lab.sh; echo "exit=$?"

ls -li /srv/lab-backup/tujuan/*/nilai.csv
du -sh /srv/lab-backup/tujuan/*
tail -3 /srv/lab-backup/log/backup.log

Nomor inode yang sama pada dua snapshot adalah bukti hardlink bekerja. Kalau inode berbeda dan total ukuran berlipat, --link-dest tidak terbaca — biasanya karena path-nya relatif atau snapshot pembanding tidak ada.

📊 Angka penting: snapshot kedua seharusnya hanya menambah ukuran sebesar file yang berubah, bukan sebesar seluruh isi folder. Kalau meledak, curigai --link-dest gagal, bukan rsync-nya rusak.

🔹 Langkah 5: jadwalkan dengan cron

Cara paling pribadi, jalankan crontab -e sebagai user yang memiliki folder backup: 

SHELL=/bin/bash
MAILTO=""
30 1 * * * /usr/local/bin/backup-lab.sh

Kalau backup harus jalan sebagai root dan kamu ingin rapi, pakai file di /etc/cron.d/ — formatnya punya kolom user tambahan: 

SHELL=/bin/bash
MAILTO=""
30 1 * * * root /usr/local/bin/backup-lab.sh

Di Debian, file di /etc/cron.d wajib milik root dan tidak boleh bisa ditulis grup atau user lain. File di /etc/cron.daily juga harus executable karena dijalankan lewat run-parts.

⚠️ Hati-hati: cron tidak membaca .bashrc atau profil shell-mu. Variabel yang tersedia hanya lingkungan minimal, jadi perintah seperti rsync bisa "hilang" padahal di terminal biasa jalan. Itulah alasan baris PATH di awal script tidak boleh dihapus.

Satu jebakan format lagi: tanda persen dalam baris cron diubah menjadi baris baru, kecuali ditulis dengan garis miring terbalik. Kalau perintahmu mengandung date +%F langsung di crontab, tulis date +\%F.

🔹 Langkah 6: buktikan dengan restore

Backup yang tidak pernah dipulihkan hanya dugaan. Uji ke folder terpisah, jangan menimpa sumber. 

rm -rf /srv/lab-backup/uji-restore
rsync -a /srv/lab-backup/tujuan/terakhir/ /srv/lab-backup/uji-restore/

diff -r /srv/lab-backup/sumber /srv/lab-backup/uji-restore && echo "ISI SAMA"

( cd /srv/lab-backup/sumber     && find . -type f -exec sha256sum {} + | sort -k2 ) > /tmp/asli.sha
( cd /srv/lab-backup/uji-restore && find . -type f -exec sha256sum {} + | sort -k2 ) > /tmp/pulih.sha
diff /tmp/asli.sha /tmp/pulih.sha && echo "CHECKSUM SAMA"

🧪 Uji cepat: setelah restore, jalankan rsync -an --delete --itemize-changes /srv/lab-backup/sumber/ /srv/lab-backup/uji-restore/. Kalau tidak ada baris perubahan, hasil restore identik dengan sumber.

🔹 Langkah 7: uji rusak terkendali

Enam uji berikut sengaja membuat backup gagal. Tujuannya bukan merusak server, tapi memastikan kamu bisa membaca gejalanya.

  • Uji A — sumber hilang. Pindahkan folder sumber, jalankan script. rsync keluar dengan kode 23 (transfer sebagian karena error), log menulis GAGAL, dan snapshot lama tetap utuh. Di sinilah pentingnya tidak menghapus snapshot lama di awal script.
  • Uji B — arah --delete terbalik. Jalankan rsync -a --delete -n /srv/lab-backup/tujuan/terakhir/ /srv/lab-backup/sumber/. Dry run akan menampilkan daftar file sumber yang akan dihapus. Inilah bentuk kesalahan yang paling mahal: satu arah salah, data asli yang jadi korban.
  • Uji C — cron tanpa PATH. Jalankan env -i /usr/local/bin/backup-lab.sh. Tanpa baris PATH di script, hasilnya rsync: command not found. Ini meniru lingkungan cron yang tidak mewarisi shell-mu.
  • Uji D — ruang habis. tar -czf /dev/full -C /srv/lab-backup/sumber . menghasilkan pesan No space left on device dan kode keluar 2. Arsip gagal total, bukan "hampir jadi".
  • Uji E — perubahan yang tidak terlihat. Buat file kecil, backup, ubah isinya dengan ukuran sama, lalu kembalikan waktu modifikasinya dengan touch -r. rsync biasa akan melewatinya; --checksum akan menangkapnya.
  • Uji F — arsip rusak. Potong file tar dengan truncate -s -100 file.tar.gz, lalu tar -tzf file.tar.gz. Perintah daftar isi gagal dengan kode 2. File yang ada di disk belum tentu file yang bisa dibuka.

⚠️ Hati-hati: uji B dan uji D bisa menghapus atau memenuhi disk kalau dijalankan di folder yang salah. Pastikan path-nya benar-benar di /srv/lab-backup, dan biasakan menambahkan -n sebelum perintah destruktif.

🏭 Dipakai di dunia kerja

  • Sekolah: folder nilai, bank soal, dan database aplikasi ujian dibackup tiap malam. Kalau server CBT mati saat ujian, panitia bisa memulihkan tanpa menunda ujian — ini yang membedakan teknisi siap dari teknisi panik.
  • Kantor distributor: faktur, data pelanggan, dan database penjualan disalin ke NAS dan disk eksternal. Kehilangan data faktur berarti sengketa tagihan dan audit yang tidak bisa ditutup.
  • Warnet dan RT-RW Net: konfigurasi billing, daftar pelanggan, dan config router dibackup sebelum perubahan. Saat router di-reset atau salah konfigurasi, pemulihan hitungan menit, bukan hitungan hari.
  • Klinik dan rumah sakit: rekam medis punya kewajiban retensi bertahun-tahun. Backup bukan soal kenyamanan, tapi kepatuhan aturan dan keselamatan pasien.
  • Industri: log proses, resep produksi, dan program PLC disalin rutin. Kalau HMI mati dan tidak ada salinan, lini produksi bisa berhenti berhari-hari menunggu vendor.
  • Penyedia layanan internet: konfigurasi perangkat dan data pelanggan dibackup sebelum setiap perubahan. Rollback cepat adalah bagian dari janji layanan, bukan kemewahan.

✅ Verifikasi

Yang diperiksa Perintah Hasil yang benar
cron hidup systemctl status cron active (running)
jadwal terpasang crontab -l baris backup muncul, jam masuk akal
backup jalan tail -3 /srv/lab-backup/log/backup.log baris OK dengan tanggal hari ini
snapshot terbaru ls -1dt /srv/lab-backup/tujuan/*/ | head -1 folder bertanggal terbaru
hardlink bekerja ls -li .../nilai.csv inode sama antar snapshot
ukuran wajar du -sh /srv/lab-backup/tujuan/* snapshot baru tidak sebesar total
isi sama diff -r sumber uji-restore tidak ada keluaran
checksum sama diff /tmp/asli.sha /tmp/pulih.sha tidak ada keluaran
arsip utuh tar -tzf file.tar.gz > /dev/null; echo $? 0

⚠️ Kesalahan umum & troubleshooting

Gejala Penyebab Perbaikan
rsync: command not found di log PATH cron minimal tulis PATH di script atau pakai path absolut
log kosong, snapshot tidak bertambah cron mati atau file cron.d salah owner cek systemctl status cron dan izin file
Permission denied (13) user cron tidak berhak baca sumber atau tulis tujuan jalankan sebagai user yang tepat, perbaiki izin
snapshot kedua sebesar pertama --link-dest tidak menemukan snapshot pembanding pakai path absolut ke snapshot terakhir
file terhapus ikut hilang di tujuan opsi --delete aktif untuk arsip harian, buat snapshot per tanggal tanpa hapus data lama
kode keluar 23 tiap malam sebagian file gagal dibaca atau I/O error baca log rsync, cek file yang berubah saat disalin
kode keluar 24 file berubah atau hilang saat penyalinan normal untuk data hidup; jadwalkan saat sepi atau dump database dulu
backup ada tapi restore gagal arsip belum pernah diuji, atau path absolut tersimpan uji tar -tzf, hindari opsi -P saat membuat arsip
disk tujuan penuh retensi tidak pernah jalan tambahkan rotasi berbasis -mtime dan pantau df
jadwal meleset beberapa jam jam server salah atau zona waktu keliru cek timedatectl dan sinkronisasi NTP

🔥 Kasus nyata: sebuah kantor distributor menyalin script backup dari internet lalu menukar posisi sumber dan tujuan saat "merapikan" path. Selama 40 detik, folder kosong di NAS menimpa data faktur tiga tahun di server. Tidak ada yang sadar sampai staf keuangan membuka aplikasi pagi hari. Pemulihan butuh dua hari dari image disk lama, dan beberapa faktur tetap hilang. Sejak itu, setiap perintah destruktif wajib lewat dry run dulu.

🔥 Kasus nyata: warnet dengan billing sederhana punya cron backup tiap malam. Setahun kemudian router di-reset dan pemilik membuka folder arsip: semua file berukuran 0 byte. Ternyata perintah tar tidak pernah diberi daftar file sehingga gagal setiap malam dengan kode 2. Tidak ada yang membaca log. Backup yang gagal diam-diam lebih berbahaya daripada tidak punya backup, karena membuat orang berhenti waspada.

🔐 Catatan keamanan & etika

  • Backup adalah kumpulan data pribadi. Nilai siswa, foto, faktur, dan database berisi nama serta alamat. Simpan folder backup dengan izin ketat, misal chmod 750 dan pemilik yang jelas — jangan di /tmp atau share terbuka.
  • Kompresi bukan enkripsi. tar -czf hanya mengecilkan ukuran. Untuk data sensitif, enkripsi arsipnya, dan simpan kunci di tempat terpisah. Kunci yang hilang membuat backup ikut hilang selamanya.
  • Script menyimpan rahasia tanpa sengaja. Path, nama database, dan kadang password sering tertinggal di script. Set izin 700, milik root, dan jangan menaruh password di crontab karena bisa dibaca dengan crontab -l.
  • Kunci SSH untuk rsync remote. Pakai kunci khusus backup, batasi perintah yang boleh dijalankan di sisi tujuan, dan jangan biarkan kunci tanpa passphrase tersebar. Siapa pun yang memegang kunci itu memegang datamu.
  • --delete tidak punya tombol undo. Biasakan -n dulu, periksa daftar yang akan dihapus, baru jalankan tanpa -n. Satu arah keliru cukup untuk menghapus sumber.
  • Retensi adalah keputusan sadar. Menghapus backup tua adalah tindakan destruktif. Catat di log, dan jangan biarkan script menghapus snapshot terakhir tanpa syarat.
  • Etika di lab bersama. Jangan memulihkan data orang lain ke mesin praktik, jangan menyalin data pribadi ke media sendiri tanpa izin, dan jangan menguji backup produksi saat jam ujian atau jam sibuk.

📌 Kesimpulan

Backup yang benar bukan yang paling canggih, tapi yang bisa dijawab dengan empat pertanyaan: apa, ke mana, kapan, dan sudah pernah dipulihkan. rsync mengurus lapis penyalin, cron mengurus lapis penjadwal, dan log serta uji restore mengurus lapis pembukti.

Kalau salah satu lapis dilewati, hasilnya selalu sama: rasa aman yang tidak berdasar. Server bisa mati kapan saja, tapi data yang punya salinan teruji selalu punya jalan pulang.

Langkah berikutnya: buka VM lab-mu, jalankan Langkah 1 dan 2, lalu jadwalkan backup pertamamu malam ini — dan uji restore-nya besok pagi, sebelum kamu mulai percaya.

🔗 Materi terkait

📚 Referensi

Retrieved from "https://noctkj.net/index.php?title=Linux_:_Backup_Otomatis_dengan_rsync,_tar,_dan_cron&oldid=1707"