Belajar Borg Backup - Sejarah, Latar Belakang & Mengapa Membutuhkannya
Sebelum menulis perintah pertama, kalian perlu tahu dari mana Borg berasal (fork Attic tahun 2010), filosofi desainnya yang fokus pada deduplicating backup, status rilis Borg 1.4.x yang stabil dan Borg 2.0 yang masih beta, serta alasan nyata mengapa backup berbasis dedup dan enkripsi penting untuk server dan workload harian.
#Pendahuluan
Di episode 0 kalian sudah menyiapkan environment: borg 1.4.5 terinstall dan repository siap dipakai. Sebelum menulis borg create pertama, ada baiknya kita memahami dari mana Borg berasal, mengapa ia didesain seperti ini, dan masalah nyata apa yang ia selesaikan. Mengenal latar belakang membuat kalian lebih bijak memilih tool dan tidak mudah tergoda oleh fitur yang tidak relevan.
#Sejarah & Filosofi
#Fork dari Attic
Borg berawal dari Attic, proyek backup Python yang dibuat oleh Jonas Borgström. Pada tahun 2010, sekelompok maintainer mengambil kode Attic dan mengembangkannya secara independen — lahirlah BorgBackup. Filosofi utama Borg sejak awal: deduplicating backup — hanya data yang benar-benar berubah yang disimpan, sekali pun snapshot yang dihasilkan tampak utuh.
Tagline resminya ringkas dan menjadi kompas desain sampai sekarang: "Deduplicated, encrypted, authenticated and compressed backups."
#Status Rilis: 1.4.x Stabil, 2.0 Masih Beta
Peta versi Borg penting agar tidak salah pilih di produksi:
- Borg 1.4.x (stabil sepanjang 2025-2026): branch yang layak produksi. Borg 1.4.5, rilis 1 Juli 2026, adalah security release — kita bedah CVE-nya di episode 15.
- Borg 2.0: masih beta (2.0.0b10). Format repository dirombak total. Menarik untuk dieksplorasi, tetapi jangan dipakai untuk produksi — kita bandingkan keduanya di episode 17.
Warning
Jangan pernah mengelola data penting dengan rilis beta. Repo yang dibuat Borg 2.0 tidak bisa dibaca oleh Borg 1.x dan sebaliknya. Untuk produksi, gunakan Borg 1.4.5.
#Mengapa Borg
#Deduplication via Content-Defined Chunking
Borg memecah file menjadi chunk dengan ukuran variable yang ditentukan oleh isi file, bukan posisinya. Karena pembagian chunk berbasis isi, pergeseran kecil di awal file tidak memicu perubahan seluruh file. Akibatnya, backup harian yang hanya mengubah sebagian kecil data memakan ruang yang sangat sedikit. Analoginya: menambahkan satu baris ke file log berukuran 1 GB tidak akan menyimpan ulang 1 GB — yang disimpan hanya baris baru itu.
#Kompresi
Setelah dedup, Borg mengompresi chunk dengan zstd, lz4, atau zlib (episode 6). Data teks, log, dan config biasanya menyusut drastis, mengurangi ruang penyimpanan dan bandwidth untuk repo remote.
#Enkripsi Otentikasi
Borg tidak hanya mengenkripsi data — ia juga memastikan data tidak bisa diubah tanpa terdeteksi (authenticated encryption). Ini menjaga integritas backup, dan di episode 13 kita tambahkan lapisan append-only sebagai pertahanan terhadap ransomware.
#Archive Mount (FUSE)
Arsip Borg bisa di-mount sebagai direktori biasa dengan borg mount. Tidak perlu restore penuh untuk sekadar melihat atau mengambil satu file — kita praktikkan di episode 5.
#Efisien untuk Backup Harian
Gabungan dedup + kompresi + enkripsi membuat Borg ideal untuk jadwal harian: waktu dan ruang yang dibutuhkan sebanding dengan jumlah perubahan, bukan ukuran dataset.
#Realita: Mengapa Kita Membutuhkan Backup yang Benar
- Ransomware menargetkan data, bukan sekadar hardware. Backup yang tidak append-only bisa ikut terenkripsi atau terhapus.
- Kesalahan manusia —
rm -rfdi direktori yang salah — adalah penyebab kehilangan data paling umum di lapangan. - Hardware mati tanpa aba-aba. Rasio kegagalan disk tahunan (AFR) kecil, tetapi pada skala ratusan disk hampir dijamin terjadi.
- Backup tanpa test restore bukan backup. Prinsip ini akan kita ulang di hampir setiap episode.
Rule of thumb yang wajib diingat: 3-2-1 — tiga salinan data, di dua media berbeda, dan satu di antaranya off-site.
Note
Backup yang baik bukan sekadar "menyalin file". Backup yang baik menawarkan tiga properti sekaligus: efisien ruang (dedup), aman (enkripsi otentikasi), dan bisa diverifikasi (check + test restore). Borg didesain untuk tiga-tiganya.
#Penutup
- Borg lahir tahun 2010 sebagai fork Attic, fokus pada deduplicating backup.
- Filosofinya: Deduplicated, encrypted, authenticated and compressed backups.
- Borg 1.4.5 stabil untuk produksi; Borg 2.0 (2.0.0b10) masih beta — hindari di produksi.
- Dedup chunking membuat backup harian hemat ruang dan waktu.
- Enkripsi otentikasi, mount FUSE, dan efisiensi adalah alasan utama memilih Borg.
Di episode 2 kita masuk ke inti teknis: konsep dasar & arsitektur utama — apa bedanya repository dan archive, bagaimana chunker content-defined bekerja, peran key, dan peta subcommand Borg. Ini fondasi yang membuat semua episode selanjutnya terasa ringan.