Belajar Borg Backup - Troubleshooting

#Pendahuluan

Pada satu titik, backup kalian akan gagal — itu bukan "jika", tapi "kapan". Yang membedakan operator berpengalaman bukan kemampuan menghindari masalah, melainkan kecepatan mendiagnosis dan memulihkannya tanpa memperparah keadaan. Episode 16 membekali kalian toolkit debugging Borg: borg check sebagai pemeriksa awal, --debug-topic untuk jejak detail, hingga log terstruktur dengan BORG_LOGGING_CONF.

#Toolkit Debugging

#Mulai dari borg check

Sebelum menyalahkan apa pun, verifikasi kesehatan repository dengan borg check /backup/borg. Hasilnya memberi arah: kesalahan di index/segment menunjukkan masalah repository; kesalahan saat membangun ulang cache menunjukkan masalah lokal klien.

#--debug-topic untuk Jejak Detail

Borg bisa mengaktifkan log debug per topik — jauh lebih berguna daripada debug penuh yang bising:

borg create --debug-topic=archive,chunker --list /backup/borg::test /home

Topik yang umum: archive (metadata archive), chunker (proses pemecahan chunk), repository, cache, ssh. Kombinasi --debug + --debug-topic memberi detail maksimal.

#Log Terstruktur dengan BORG_LOGGING_CONF

Untuk debugging jangka panjang di produksi, gunakan konfigurasi logging sendiri:

[loggers]
keys = root, repository
 
[handlers]
keys = file, console
 
[formatters]
keys = standard
 
[logger]
level = INFO
 
[logger.repository]
level = DEBUG
 
[handler_file]
class = FileHandler
level = DEBUG
args = ('/var/log/borg.log', 'a', 'UTF-8', 1)
 
[handler_console]
class = StreamHandler
level = WARNING
 
[formatter_standard]
format = %(asctime)s %(levelname)s %(name)s %(message)s

Aktifkan dengan export BORG_LOGGING_CONF=/etc/borg/logging.conf lalu jalankan perintah borg seperti biasa. Log detail masuk ke /var/log/borg.log sementara konsol tetap bersih — pola yang sehat untuk otomasi.

#Kasus Umum

#1. Repository Lock

Failed to create/acquire the lock on /backup/borg

Penyebab: proses borg lain sedang berjalan, atau lock lama dari crash/matilistrik. Pertama periksa proses dengan ps aux | grep "[b]org". Jika tidak ada proses tapi lock masih ada, itu stale lock — jangan pernah rm file lock secara manual; gunakan borg break-lock /backup/borg, dan hanya jika kalian yakin benar-benar stale.

#2. Repository Corruption

Repository or key data seem corrupt

Langkah pertama: jangan panik dan jangan langsung --repair. Diagnosis dengan borg check /backup/borg --debug-topic=repository:

• Jika index rusak tetapi segmen utuh: borg check membangun ulang index dari segmen.
• Jika segmen benar-benar korup: pertimbangkan borg check --repair, dengan salinan repository di tempat lain terlebih dahulu. Ingat peringatan episode 12: --repair menghapus data yang tak bisa diperbaiki.

#3. Version Mismatch

Repository was made with a different security feature level

Repo dibuat Borg 2.0 tidak bisa dibaca 1.4, dan sebaliknya. Diagnosis cepat: bandingkan borg --version dengan versi di config repository. Solusinya: samakan versi klien dan server (episode 15), atau untuk repo 2.0-beta jangan dipaksa dibaca 1.x — bangun repo baru dengan versi yang benar.

#4. SSH/Remote Gagal

Connection closed by remote host

Uji koneksi secara manual dengan BORG_RSH='ssh -v' borg list borg@backup-host:/srv/borg/backup. -v menampilkan handshake SSH; kegagalan di command= authorized_keys biasanya tampak jelas di sini.

#Recovery dari Segmen Rusak

Ketika segmen benar-benar rusak dan berisi chunk yang direferensikan archive:

1. Identifikasi chunk yang rusak lewat borg check --verify-data — chunk mana yang tidak lolos.
2. Cari archive yang bergantung pada chunk tersebut — hanya archive itu yang terdampak.
3. Restore dari salinan lain bila ada (pola 2 di episode 14 membuat off-site berfungsi sebagai jaring pengaman).
4. Sebagai jalan terakhir, borg check --repair membuang chunk korup — file terkait hilang dari archive, tetapi archive lain tetap utuh.

Praktik preventif yang paling efektif: selalu ada salinan repo kedua dan borg check rutin. Recovery terbaik adalah yang tidak pernah dibutuhkan.

#Pitfall Umum

• Menghapus file lock manual: selalu borg break-lock, bukan rm file di lock.exclusive.
• --repair sebagai refleks pertama: diagnosis dulu; sebagian korupsi bisa diselesaikan tanpa repair.
• Mengabaikan peringatan versi: membaca repo 2.0 dengan 1.4 merusak data metadata. Hormati batas versi.
• Debug tanpa konfigurasi logging: di produksi, gunakan BORG_LOGGING_CONF agar jejak tersimpan, bukan hilang di terminal.

#Penutup

• Diagnosis dimulai dari borg check, bukan asumsi.
• --debug-topic memberi jejak per topik; BORG_LOGGING_CONF menyimpan log untuk produksi.
• Kasus umum: repo lock (gunakan borg break-lock), korupsi (check → repair hati-hati), mismatch versi, dan SSH failure.
• Recovery dari segmen rusak: identifikasi dampak, gunakan salinan lain, --repair sebagai jalan terakhir.
• Salinan repo kedua + check rutin adalah praktik preventif terbaik.

Di episode 17 kita menengok masa depan: Borg 1.4.5 vs Borg 2.0 — mengapa 1.4.5 tetap pilihan produksi, apa saja yang dirombak 2.0 (format repo, hash index, --match-archives, segment management), dan kapan kalian boleh pindah.