Belajar Borg Backup - Hardening & Multi-host

#Pendahuluan

Di episode 13 repository kalian sudah menjadi benteng. Sekarang saatnya menerapkan pola itu di skala organisasi: banyak host, banyak tim, dan tuntutan recovery yang berbeda-beda. Godaan terbesar di sini adalah "satu repository besar untuk semuanya" — terlihat praktis, tetapi menyatukan risiko, key, dan kebijakan retention yang seharusnya terpisah. Episode 14 mengajarkan desain yang benar.

#Multi-host: Satu Repository per Host/Team

#Mengapa Bukan Satu Repository Raksasa

Satu repository berisi backup seluruh server memang menggoda — sekali setup, semua masuk. Tapi biayanya:

• Key berbagi: satu key untuk semua host. Bocor sekali, semua data terpapar.
• Kebijakan retention tercampur: host dengan data audit 2 tahun dan host dengan log 7 hari jadi satu aturan.
• Performa menurun: index repository membesar seiring archive bertambah, memperlambat semua operasi.
• Prune berbahaya: satu kesalahan --prefix bisa menghapus backup host lain (episode 8).
• Blast radius: repo korup = semua host kehilangan backup sekaligus.

#Desain yang Benar

Pisahkan per host atau per kelompok data dengan kebijakan sama:

/srv/borg/
├── web-01/        # repo host web-01 (restrict path sesuai host)
├── web-02/        # repo host web-02
├── db-primary/    # repo database cluster
└── team-data/     # repo bersama satu tim

Di sisi SSH, setiap repo dipetakan ke restricted command yang berbeda — dan idealnya key yang berbeda per host:

command="borg serve --restrict-to-repository /srv/borg/web-01",restrict,no-pty ssh-ed25519 AAAA...web01-key
command="borg serve --restrict-to-repository /srv/borg/web-02",restrict,no-pty ssh-ed25519 AAAA...web02-key

#Isolasi Key

Prinsipnya: satu key = satu host = satu repository. Ini memungkinkan pencabutan individu tanpa menyentuh host lain, dan membatasi kerusakan bila satu key bocor. Passphrase repo juga sebaiknya unik per repo — kelola dengan password manager atau secret management, bukan satu passphrase global.

#Monitoring Akses

Backup adalah jendela ke seluruh data server — akses ke repository harus terlihat:

• Audit SSH: pantau log /var/log/auth.log di host backup untuk koneksi user borg; alert untuk login di luar jadwal backup.
• Failed logins: percobaan SSH yang gagal berulang menandakan brute force — pasang fail2ban atau sejenisnya.
• Akses admin ke repo: siapa yang punya akses shell ke host backup? Batasi seminimal mungkin (episode 11: user borg tanpa password).
• Log borgmatic: pastikan on_error dan hasil check tercatat dan termonitor (episode 20).

#Best Practice: Off-site dan Uji Restore

#Backup Off-site di Host Berbeda

Prinsip 3-2-1 yang kita sebut di episode 1, sekarang dalam bentuk konkret:

• 3 salinan: data asli, backup lokal, backup off-site.
• 2 media: misal disk lokal + storage backup host lain (bukan partisi di disk yang sama).
• 1 off-site: host di lokasi berbeda — bukan ruangan yang sama dengan server produksi.

Untuk off-site, ada dua pola umum:

# borgmatic sudah mendukung beberapa repositories:
repositories:
  - path: /backup/borg
    label: local
  - path: borg@offsite-host:/srv/borg/backup
    label: offsite

# backup lokal dulu, lalu transfer repo ke host off-site
borg create /backup/borg::"{hostname}-{now}" /home /etc
borg prune --keep-daily 7 --keep-weekly 4 /backup/borg
borg compact /backup/borg
rsync -a /backup/borg/ borg@offsite-host:/srv/borg/backup/

Pola 2 menarik karena off-site hanya menerima salinan repo — tidak ada key yang berjalan di sana, dan transfer bisa dijadwalkan di luar jam backup.

#Uji Restore Terjadwal

Kita tekankan di episode 5, sekarang sebagai kebijakan:

• Bulanan: restore satu file/direktori dari archive terbaru, bandingkan checksum.
• Kuartalan: restore penuh satu host kritis ke VM staging.
• Tahunan: restore penuh + verifikasi data (borg check --verify-data) setelah.

Uji restore bukan "semoga berhasil" — ia adalah satu-satunya bukti bahwa backup benar-benar bekerja.

#Pitfall Umum

• Satu repo, banyak host, satu key: kombinasi terburuk. Pisahkan.
• Off-site di ruangan yang sama: kebakaran/serangan fisik yang sama memusnahkan keduanya.
• Repo lokal di disk yang sama dengan data: kegagalan disk menghapus data dan backup sekaligus.
• Uji restore hanya saat incident: terlalu terlambat. Jadwalkan seperti backup.
• Tidak memonitor host backup: kerusakan yang tidak diketahui selama bertahun-tahun sama buruknya dengan tidak punya backup.

#Penutup

• Desain multi-host: satu repository per host/team, satu key per host.
• Isolasi key memungkinkan pencabutan individu dan membatasi blast radius.
• Monitoring akses: audit SSH, alerting, dan log borgmatic.
• Off-site di host dan lokasi berbeda; hindari single point of failure.
• Uji restore terjadwal adalah bukti bahwa backup bekerja.

Di episode 15 kita menengok ranah keamanan yang lebih spesifik: CVE & security releases — dua CVE yang diperbaiki Borg 1.4.5 (metadata discarding dan cache corruption), mengapa kalian harus segera upgrade, dan praktik borg check rutin sebagai bagian dari postur keamanan.