Belajar Linux - Backup & Restore Strategy

#Pendahuluan

Setelah di episode 25 sebelumnya kita membahas hardening keamanan sistem Linux — SSH key authentication, firewall, fail2ban, hingga penguncian akses dengan user & sudo yang ketat — sistem kalian kini jauh lebih sulit ditembus. Namun ada satu kenyataan yang tidak bisa dihindari oleh admin sehebat apa pun: no matter how well you defend, eventually you must face data loss. Hard disk SSD yang rusak tanpa peringatan, file terhapus karena rm -rf yang salah sasaran, database korup karena listrik mati di tengah transaksi, atau bahkan satu server yang disandera oleh ransomware — semua itu bukan fiksi.

Pertanyaannya bukan lagi apakah itu akan terjadi, melainkan seberapa cepat kalian bisa pulih. Di episode kali ini kita membahas pertahanan terakhir sekaligus yang paling sering diabaikan: backup & restore strategy. Kita akan membedah prinsip 3-2-1, membandingkan tool seperti rsync, tar, restic, dan borgbackup, mempraktikkan backup database serta file server, lalu menutup dengan prosedur restore dan drill yang membuat kalian tidur nyenyak meskipun server bermasalah.

#Pembahasan Utama

#Mengapa Backup Bukan Opsi: Prinsip 3-2-1

Banyak admin pemula menganggap backup sebagai pekerjaan "kalau sempat". Pemikiran itu berbahaya. Anggap saja server kalian adalah sebuah lemari berisi ijazah, sertifikat, dan kontrak penting. Kalian bisa menjaga lemari itu dengan gembok terkuat dan alarm terbaik — tetapi jika rumahnya kebakaran, semua itu tetap lenyap. Solusi yang masuk akal bukan sekadar mengunci lemari, melainkan menyimpan salinan dokumen penting di lokasi lain.

Di dunia backup, solusi itu dirumuskan menjadi prinsip yang sangat terkenal: the 3-2-1 rule.

• 3 salinan data — satu data produksi aktif, satu backup utama, satu backup tambahan. Total tiga salinan dari data yang sama.
• 2 media berbeda — misalnya satu di hard disk internal/eksternal dan satu lagi di tape, NAS, cloud, atau server lain. Kenapa media berbeda? Karena kerusakan sering datang dari satu titik: hard disk yang sama bisa gagal, dan perangkat yang sama bisa dicuri bersama-sama.
• 1 salinan offsite — satu salinan di luar lokasi utama. Jika gedung kebakaran, banjir, atau diserang ransomware yang menginfeksi semua mesin lokal, salinan offsite adalah penyelamat terakhir.

+-----------------------+      +----------------------+      +------------------+
|  Data Produksi        |  --> |  Backup Utama        |  --> |  Backup Offsite  |
|  (server utama)       |      |  (NAS/disk eksternal)|      |  (cloud/DC lain) |
+-----------------------+      +----------------------+      +------------------+
  1 salinan (aktif)          2 salinan, media #1         3 salinan, media #2
                                                          = 1 lokasi terpisah

Sekarang kalian mengerti mengapa kita backup. Berikutnya, bagaimana caranya — dan pilihan tool sangat menentukan kualitas backup kalian.

#Memilih Tool yang Tepat

Linux memberi kalian spektrum tool yang lebar, dari yang sederhana hingga yang canggih. Kunci pemilihannya bukan "tool mana yang paling keren", melainkan tool mana yang cocok dengan kebutuhan recovery kalian. Setiap tool punya trade-off antara kesederhanaan, kecepatan, ruang penyimpanan, dan kemudahan restore.

#rsync: Sinkronisasi Diferensial yang Fleksibel

rsync sudah kita bahas di episode sharing file, dan di dunia backup ia adalah kuda beban utama. Kekuatannya terletak pada incremental transfer: rsync hanya mengirim data yang berubah, sehingga backup berikutnya sangat cepat dan hemat bandwidth. Ia juga mendukung hardlink-based deduplication bila dipadukan dengan struktur direktori ber-timestamp.

rsync -avz --delete \
  /var/www/ \
  backup@nas.local:/backups/www/latest/

Pola di atas adalah baseline. Untuk mendapatkan snapshot harian tanpa memakan ruang ekstra, banyak admin memakai trik rsync --link-dest: setiap hari kita backup ke direktori bertanggal, tetapi file yang tidak berubah hanyalah hardlink ke backup kemarin. Hasilnya, kalian punya 30 versi harian yang secara efektif hanya sebesar satu backup penuh.

TODAY=$(date +%F)
rsync -a --delete --link-dest=../latest \
  /var/www/ backup@nas.local:/backups/www/$TODAY/

#tar: Arsip Statis yang Portabel

tar adalah tool arsip tertua yang masih hidup sampai sekarang. Keunggulannya: satu file arsip yang self-contained dan mudah dipindahkan — cocok untuk snapshot konfigurasi, arsip proyek, atau migrasi server. Kelemahannya: setiap kali backup penuh, seluruh data dibaca ulang, sehingga kurang efisien untuk data yang berubah cepat dalam volume besar.

tar -czf /backups/etc-$(date +%F).tar.gz /etc

Untuk file yang jarang berubah seperti /etc, tar adalah pilihan yang sangat wajar. Kombinasi tar untuk konfigurasi dan rsync untuk data dinamis adalah pola umum yang sehat di banyak organisasi.

#restic & borgbackup: Deduplikasi dan Enkripsi Terpadu

Untuk skala yang lebih serius, tool modern seperti restic dan borgbackup menawarkan fitur yang dulu hanya ada di solusi enterprise berbayar: deduplikasi data (blok data yang sama hanya disimpan sekali, bahkan antar file yang berbeda), enkripsi end-to-end, dan snapshot berbasis waktu.

• restic — ditulis dalam Go, satu binary tanpa dependensi, mendukung repository lokal maupun remote (SFTP, S3, Backblaze, dan lainnya). Sangat populer karena sederhana dan modern.
• borgbackup — Python, dengan kompresi dan deduplikasi yang sangat efisien, memiliki fitur mountable archives sehingga kalian bisa me-mount backup seperti direktori biasa untuk inspeksi.

# 1. Inisialisasi repository + password
restic init --repo /backups/restic-repo
 
# 2. Backup direktori penting
restic -r /backups/restic-repo backup /etc /home /var/www
 
# 3. Lihat daftar snapshot
restic -r /backups/restic-repo snapshots

Perhatikan baris pertama: restic langsung meminta password untuk mengenkripsi repository. Semua data yang masuk ke repo sudah terenkripsi sebelum meninggalkan server — jadi mengirimnya ke cloud bukan masalah besar, karena isinya tidak bisa dibaca siapa pun tanpa password. Ini alasan mengapa restic/borg adalah pilihan utama untuk backup offsite.

#Otomatisasi dan Pengujian Berkala

Backup yang dijalankan manual adalah backup yang suatu saat tidak akan dijalankan. Otomatisasi lewat cron atau systemd timer adalah keharusan, bukan kemewahan. Pola yang paling umum:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin
 
# Backup database & file server setiap pukul 02.30
30 2 * * * root /usr/local/sbin/backup-server.sh >> /var/log/backup.log 2>&1

Satu aturan yang tidak boleh ditawar: backup harus diuji restore-nya secara berkala. Sebuah backup yang tidak pernah diuji restore nilainya sama dengan tidak punya backup sama sekali — mungkin malah lebih berbahaya, karena memberi rasa aman palsu. Uji restore minimal sebulan sekali, dan catat hasilnya.

#Backup Database dan File Server Kritis

Backup file seperti /etc dan /home relatif sederhana — tinggal disalin. Database adalah cerita yang berbeda: meng-copy file data mentah (misalnya *.frm, *.ibd, *.pgdata) saat database sedang berjalan hampir pasti menghasilkan backup yang korup. Database menulis ke disk dalam buffer dan transaksi yang tidak konsisten; menyalin di tengah proses itu seperti memotret buku yang sedang dijiplak orang sambil halaman-halamannya berpindah.

Solusinya adalah menggunakan tool dump bawaan database yang menghasilkan snapshot logis yang konsisten:

mysqldump --single-transaction --quick --routines \
  -u backup -p myapp_db | gzip > /backups/db/myapp-$(date +%F).sql.gz

pg_dump -U backup -Fc myapp_db > /backups/db/myapp-$(date +%F).dump

Beberapa hal yang perlu diperhatikan:

• --single-transaction pada mysqldump menghasilkan snapshot konsisten tanpa mengunci tabel untuk waktu lama.
• Format -Fc (custom) pada pg_dump menghasilkan file terkompresi yang bisa di-restore secara selektif per tabel.
• Database di server production sebaiknya dibackup lewat replika atau dengan buffer pool yang memadai agar dump tidak membebani instance utama.

#Prosedur Restore dan Verifikasi Integritas

Restore adalah sisi dari backup yang tidak pernah populer sampai dibutuhkan — dan di saat itulah semua kelemahan terungkap. Prosedur yang baik selalu berjalan dalam urutan yang jelas dan bisa dipraktikkan oleh siapa pun, termasuk orang yang baru bergabung:

1. Kenali cakupan kerusakan — file mana yang hilang? Database mana yang korup? Ini menentukan modul backup mana yang harus di-restore.
2. Isolasi — jika yang rusak adalah server utama, jangan langsung menimpa; restore dulu ke environment sementara dan verifikasi.
3. Restore — jalankan perintah restore sesuai tool yang dipakai.
4. Verifikasi integritas — cek checksum, hitung jumlah baris di tabel, pastikan aplikasi bisa berjalan.
5. Catat dan audit — dokumentasikan waktu, tool, dan hasilnya di runbook.

Untuk arsip tar, verifikasi bisa dilakukan langsung dengan perintah berikut:

tar -tvzf /backups/etc-2026-08-01.tar.gz | head -20

Untuk database, uji paling kuat adalah restore ke environment kosong lalu bandingkan jumlah baris:

createdb myapp_restore
pg_restore -d myapp_restore /backups/db/myapp-2026-08-01.dump
psql -d myapp_restore -c "SELECT count(*) FROM orders;"

mysql -u root -p myapp_db < /backups/db/myapp-2026-08-01.sql.gz

#Praktik: Script Backup restic dan Restore Drill

Saatnya menggabungkan semuanya menjadi satu script yang bisa dijadwalkan. Script berikut melakukan backup file kritis dan database, menambahkan snapshot restic, lalu membersihkan snapshot lama dengan kebijakan retention:

#!/usr/bin/env bash
set -euo pipefail
 
REPO="/backups/restic-repo"
export RESTIC_PASSWORD_FILE="/etc/restic/passphrase"
 
log() { echo "[$(date +%F_%T)] $*"; }
 
log "Backup database..."
mysqldump --single-transaction -u backup myapp_db \
  | gzip > /var/tmp/myapp-$(date +%F).sql.gz
 
log "Backup file server dengan restic..."
restic -r "$REPO" backup /etc /home /var/www /var/tmp/myapp-*.sql.gz
 
log "Bersihkan snapshot lama (retention 7/4/6)..."
restic -r "$REPO" forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
 
log "Selesai."

Penjelasan baris yang penting:

• set -euo pipefail membuat script berhenti dan mengembalikan status gagal jika ada satu langkah yang error — inilah dasar dari alerting yang dibahas di atas.
• Password restic disimpan di file /etc/restic/passphrase dengan permission 600, bukan di dalam script. Script versi kalian seharusnya mengambil dari secret manager, bukan di-commit ke Git.
• forget dengan --keep-daily/--keep-weekly/--keep-monthly adalah kebijakan retention yang umum: simpan 7 snapshot harian, 4 mingguan, dan 6 bulanan, lalu hapus sisanya dengan --prune.

Setelah script berjalan, jalankan restore drill. Drill yang baik mensimulasikan bencana nyata: restore file /etc yang terhapus, dan restore database ke environment kosong:

SNAP=$(restic -r /backups/restic-repo snapshots --latest -q)
restic -r /backups/restic-repo restore "$SNAP" \
  --target /mnt/restore --include /etc
ls -la /mnt/restore/etc/ssh/

SNAP=$(restic -r /backups/restic-repo snapshots --latest -q)
mkdir -p /mnt/restore && \
  restic -r /backups/restic-repo restore "$SNAP" --target /mnt/restore
gzip -dc /mnt/restore/var/tmp/myapp-*.sql.gz | mysql -u root myapp_db

#Common Pitfalls

Setelah puluhan tahun praktik backup, pola kegagalan yang sama terus berulang. Kenali dan hindari:

Kasus rsync --delete pantas mendapat perhatian khusus. Jika kalian menjalankan rsync -av --delete /sumber /tujuan dan sumber ternyata kosong atau ter-mount dengan salah, rsync dengan patuh menghapus semua file di tujuan. Ini adalah salah satu cara paling cepat menghancurkan backup. Guard terhadapnya dengan --dry-run terlebih dahulu, atau gunakan tool dengan model snapshot seperti restic yang tidak pernah menghapus data lama tanpa kebijakan yang eksplisit:

rsync -av --delete /var/www/ /backups/www/
rsync -av --dry-run /var/www/ /backups/www/
# Selalu review output dry-run sebelum menjalankan versi asli

#Penutup

Di episode ini kita telah membangun pertahanan terakhir dari sebuah server: strategi backup & restore. Kita memahami prinsip 3-2-1 sebagai fondasi, memilih tool berdasarkan kebutuhan restore — rsync untuk sinkronisasi incremental, tar untuk arsip statis, dan restic/borgbackup untuk deduplikasi serta enkripsi. Kita juga membahas cara backup database dengan benar lewat mysqldump/pg_dump, otomatisasi dengan cron, prosedur restore yang terurut, dan drill yang terukur. Yang paling penting, kita mempelajari bahwa backup bukan produk — ia adalah proses yang harus diuji, diukur, dan dirawat terus-menerus.

Dengan backup yang solid, kalian sudah siap menghadapi skenario terburuk. Namun backup hanyalah separuh cerita; separuh lainnya adalah bagaimana layanan dijalankan dan di-scale. Di episode 27 berikutnya kita akan membahas containerization & virtualization — Docker untuk application containers, LXD untuk system containers, dan KVM untuk virtual machine penuh. Kalian akan melihat bagaimana konsep-konsep yang sudah kita pelajari dari episode 0 hingga 26 bermuara ke cara modern menjalankan layanan: ringan, terisolasi, dan mudah dipindahkan. Sampai jumpa di episode 27!