Belajar Borg Backup - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kita tahu mengapa Borg ada dan mengapa dedup penting. Sekarang waktunya memahami bagaimana Borg bekerja di bawah kap: apa itu repository, apa itu archive, dan bagaimana chunker content-defined menghasilkan deduplication yang efisien. Pemahaman ini bukan sekadar teori — saat backup kalian bermasalah di episode 16, kalian akan kembali ke bab ini.

#Arsitektur: Repository dan Archive

#Repository: Rumah Semua Data

Repository adalah lokasi penyimpanan (lokal atau remote via SSH) yang menampung seluruh data Borg. Secara internal, repository berisi:

• config: konfigurasi repository — versi format, mode enkripsi, dan setelan lain.
• data: segmen-segmen yang menyimpan chunk data terenkripsi, ditulis secara append-only.
• index & hints: katalog yang memetakan hash chunk ke lokasi di segmen. Index bisa dibangun ulang dari segmen bila hilang — inilah dasar borg check di episode 12.

#Archive: Snapshot Dataset

Archive adalah "snapshot" satu dataset pada satu waktu — hasil dari satu perintah borg create. Satu repository bisa berisi ratusan archive dari hari, minggu, bahkan tahun yang berbeda. Setiap archive menyimpan metadata file lengkap (nama, permission, timestamp, daftar chunk) dan referensi ke chunk data.

Kuncinya: dua archive yang berisi file sama akan berbagi chunk yang sama. Menambahkan satu file ke archive kedua tidak menyimpan data file itu lagi — itulah sumber efisiensi Borg.

#Chunker Content-Defined

Untuk memecah file menjadi chunk, Borg memakai content-defined chunking (CDC) dengan algoritma buzhash. Karena batas chunk ditentukan oleh pola isi, bukan posisi byte, data yang bergeser tidak membuat semua chunk berubah. Default-nya rata-rata chunk sekitar 2 MiB, dan parameter ini bisa dituning untuk dataset tertentu (episode 18).

#Komponen Utama

#Binary borg

borg adalah satu binary Python berisi banyak subcommand. Seluruh operasi — dari membuat repo hingga memeriksa integritas — dilakukan lewat subcommand ini. Tidak ada daemon, tidak ada database eksternal; cukup binary dan filesystem.

#Lokasi Repository

Repo ditulis sebagai path lokal (/backup/borg) atau remote (user@backup-host:/backup/borg). Borg mendeteksi pola user@host: dan otomatis memakai SSH — termasuk memanggil borg serve di sisi server, seperti yang kita bangun di episode 11.

#Key

Enkripsi Borg bergantung pada key. Ada dua gaya utama: repokey (key disimpan di dalam repository, dilindungi passphrase) dan keyfile (key di file terpisah). Tanpa key atau passphrase yang benar, repository tidak terbaca — bahkan oleh pemilik data aslinya. Detail lengkap di episode 7.

#Peta Subcommand

borg init        # buat repository
borg create      # buat archive (backup)
borg list        # daftar archive di repo
borg info        # detail archive/repo
borg extract     # restore dari archive
borg mount       # mount archive via FUSE
borg prune       # hapus archive lama (retention)
borg compact     # reclaim ruang segmen
borg check       # verifikasi integritas repo

Urutan peta ini adalah alur hidup backup: init → create (diulang berkali-kali) → prune + compact → check. Kita ikuti alur itu persis dari episode 3 sampai 12.

#Alur Data: Apa yang Terjadi Saat borg create

1. Borg membaca file sumber dan memecahnya menjadi chunk (CDC).
2. Setiap chunk di-hash; hash yang sudah ada di index dilewati — data tidak disimpan ulang.
3. Chunk baru dikompresi, lalu dienkripsi dengan key.
4. Metadata file (nama, permission, timestamp, daftar chunk) disimpan sebagai data archive.
5. Semua ditulis sebagai segmen append-only — archive lama tidak pernah dimodifikasi.

Konsekuensi penting dari langkah ke-5: menghapus archive tidak langsung mengosongkan ruang. Chunk yang tidak lagi direferensikan baru benar-benar dibuang saat borg compact dijalankan — kita bahas di episode 8.

#Mengapa Desain Ini Bagus

• Immutable: archive yang sudah dibuat tidak pernah berubah, sehingga konsisten saat restore.
• Efisien: penyimpanan proporsional dengan data unik, bukan ukuran total dataset.
• Aman: segmen append-only + enkripsi otentikasi menjadi dasar pertahanan anti-ransomware di episode 13.

#Penutup

• Repository menampung segmen data + index; archive adalah snapshot per waktu.
• CDC (buzhash) menentukan chunk dari isi, bukan posisi — kunci efisiensi dedup.
• Komponen inti: binary borg, lokasi repo (lokal/SSH), key, dan subcommand.
• Alur hidup backup: init → create → prune/compact → check.
• Archive immutable; ruang baru benar-benar dibebaskan oleh borg compact.

Di episode 3 kita menjalankan perintah nyata pertama: inisialisasi repository dengan borg init, memilih mode enkripsi repokey vs keyfile vs authenticated, dan mengatur BORG_REPO serta BORG_PASSPHRASE/BORG_PASSCOMMAND dengan benar.