Membangun Sistem Backup Saya Sendiri – Bagian 1: Strategi Sebelum Skrip

 (it-notes.dragas.net)
3 poin oleh GN⁺ 2025-07-21 | 1 komentar | Bagikan ke WhatsApp
  • Pentingnya backup sering kali diremehkan
  • Banyak orang merasa cukup dengan ketergantungan pada cloud dan tidak menyadari tanggung jawab mereka dalam melindungi data
  • Mengandalkan salinan sederhana tanpa membuat rencana backup menimbulkan risiko besar
  • Metode backup seluruh disk atau file per file masing-masing memiliki kelebihan dan kekurangan
  • Backup yang andal bergantung pada pemanfaatan snapshot dan ketersediaan penyimpanan eksternal

Pentingnya Backup dan Realitas di Lapangan

  • Backup adalah area yang tidak dianggap serius oleh banyak orang
  • Banyak data hilang karena metode yang salah atau kesalahan konsep (misalnya, RAID bukan backup)
  • Data adalah aset penting yang harus dipertahankan dengan berbagai cara

Kesalahpahaman tentang Cloud dan Backup

  • Banyak orang menyerahkan semua data ke cloud tanpa pernah bertanya bagaimana data tersebut sebenarnya dilindungi
  • Penyedia cloud besar pun menerapkan model tanggung jawab bersama
    • Mereka menyediakan keamanan infrastruktur, tetapi tanggung jawab perlindungan data tetap ada pada pengguna
  • Di lingkungan seperti cloud, server privat, dan Kubernetes, risiko tidak adanya backup juga sering terjadi

Pengalaman Penulis dalam Pemulihan Data

  • Penulis pernah menghadapi berbagai kasus kehilangan data seperti kebakaran data center, ruang server yang kebanjiran, gempa bumi, ransomware, serangan berbahaya, dan kesalahan administrator
  • Untuk server yang terhubung ke internet (e-commerce, email, dan lain-lain), integritas data dan keberlanjutan layanan sama-sama penting
  • Backup bukan sekadar menyalin. Terutama, menyalin file database yang sedang aktif dapat sangat meningkatkan kemungkinan tidak bisa dipulihkan

Pertanyaan Penting saat Menyusun Strategi Backup

  • "Seberapa besar risiko yang siap ditanggung?", "Data apa yang harus dilindungi?", "Berapa lama downtime yang bisa ditoleransi jika data hilang?", "Berapa ruang penyimpanan yang tersedia?"
  • Menyimpan backup di mesin yang sama tidak berguna jika mesin tersebut gagal. Backup ke penyimpanan eksternal lebih aman
  • Faktor praktis seperti bandwidth jaringan, kecepatan pemulihan, dan kapasitas penyimpanan juga harus dipertimbangkan

Backup Seluruh Disk vs Backup Per File

Backup Seluruh Disk

  • Kelebihan
    • Dapat melakukan pemulihan penuh. Sistem bisa dipulihkan dengan cepat ke kondisi sebelumnya
    • Sangat berguna bila digabungkan dengan sistem virtualisasi. Proxmox dan sejenisnya mendukung backup penuh ini dengan mudah
    • Beberapa solusi juga mendukung pemulihan file individual dari backup penuh
  • Kekurangan
    • Untuk server fisik, diperlukan downtime
    • Menghabiskan banyak ruang karena data yang tidak perlu pun ikut disimpan
    • Tergantung karakteristik file system, proses bisa lambat atau menimbulkan masalah kompatibilitas

Backup Per File

  • Kelebihan
    • Bisa dilakukan dengan utilitas dasar sistem (tar, cp, rsync, dan lain-lain)
    • Bisa melakukan backup hanya pada perubahan sehingga menghemat ruang dan lalu lintas transfer
    • Memberikan fleksibilitas untuk pemulihan individual, pemindahan, kompresi, dan deduplikasi
    • Dapat dijalankan tanpa menghentikan sistem
  • Kekurangan
    • Salinan sederhana membutuhkan banyak ruang penyimpanan
    • Jika melakukan backup file system yang sedang aktif tanpa snapshot, dapat terjadi inkonsistensi dan error

Backup dengan Memanfaatkan Snapshot

  • Jika target backup adalah file system yang sedang aktif, data bisa berubah di antara saat backup "dimulai" dan "selesai", sehingga konsistensi data bisa rusak
  • Database yang sedang terbuka seperti MySQL atau riwayat browser bisa menjadi tidak mungkin dipulihkan hanya dengan menyalin file
  • Untuk menjamin backup yang konsisten, fitur snapshot pada file system harus dimanfaatkan terlebih dahulu
  • Metode yang umum
    • Snapshot file system native (sistem yang mendukung BTRFS, ZFS)
    • Snapshot LVM: ada risiko pemborosan ruang dan kemungkinan sistem berhenti saat snapshot dihapus
    • DattoBD: kadang ada isu stabilitas, tetapi bisa dimanfaatkan bersama UrBackup

Metode Backup: Push vs Pull

  • Push: target backup terhubung ke server dan mengirim data
  • Pull: server backup pusat terhubung ke masing-masing server untuk menjalankan backup
  • Dari sisi keamanan, pendekatan pull lebih aman karena server backup memblokir akses dari luar dan hanya mengakses klien saat diperlukan
    • Untuk mencegah penghapusan data backup saat terjadi intrusi atau ransomware, snapshot server backup itu sendiri juga disimpan terpisah untuk jangka panjang

Karakteristik Utama Sistem Backup yang Direkomendasikan

  • Pemulihan instan dan pemrosesan cepat
  • Disimpan di penyimpanan eksternal (namun snapshot lokal tetap dipertahankan untuk rollback cepat)
  • Disarankan tidak menggunakan cloud komersial seperti Google Drive atau Dropbox. Data sebaiknya dimiliki dan dipegang sendiri
  • Pengelolaan ruang yang efisien seperti kompresi dan deduplikasi
  • Komponen tambahan yang dibutuhkan untuk beroperasi harus seminimal mungkin

Rencana Seri Berikutnya

  • Penulis akan memperkenalkan berbagai skenario backup, server yang benar-benar digunakan, pengaturan utama, serta berbagai perangkat lunak dan teknologi
  • Pada seri berikutnya, akan dibahas cara membangun server backup berbasis FreeBSD

Bacaan terkait

1 komentar

 
GN⁺ 2025-07-21
Komentar Hacker News

  • Mesin yang cadangannya wajib memakai model push perlu dibatasi agar hanya bisa mengakses ruangnya sendiri, dan yang lebih penting adalah server cadangan menyimpan snapshot filesystem-nya sendiri untuk jangka waktu tertentu demi keamanan, sehingga bahkan dalam skenario terburuk ketika workload rusak lalu berhasil mengakses server cadangan dan menghapus backup untuk menuntut tebusan, snapshot masih tersisa di server; pendekatan yang saya sukai adalah klien hanya boleh menulis backup baru dan sama sekali tidak boleh menghapus, sementara penghapusan ditangani lewat prosedur terpisah (manual atau cron dan sejenisnya), dan ini bisa diimplementasikan di rsync/ssh dengan fitur allowed command pada .ssh/authorized_keys

    • Saya memakai keduanya, memang backup harus disimpan di dua tempat, dan arsitektur backup ganda ini memang yang saya incar sejak awal; sumber backup melakukan push ke lokasi perantara, lalu penyimpanan backup utama melakukan pull dari sana, lokasi perantara menyimpan snapshot dengan kapasitas kecil, tetapi storage utama dan sumber sama sekali tidak saling terautentikasi, artinya masing-masing hanya bisa mengautentikasi ke lokasi perantara dan tidak ada autentikasi arah balik; jika satu atau dua dari tiga lokasi ini diretas, sisanya kemungkinan besar tetap aman; backup sertifikat saya tangani sepenuhnya terpisah agar tidak semuanya tersimpan di server yang terhubung internet; data yang benar-benar penting bahkan punya backup offline tambahan; pemisahan struktur ini memang membuat verifikasi backup aktual jadi merepotkan, tetapi storage backup secara berkala memverifikasi checksum lalu mengirim hasilnya ke host perantara dan membandingkannya dengan hash yang dibuat host asal untuk mendeteksi kejadian korupsi; hasil pengaturan ini adalah semacam backup ‘soft offline’ di mana snapshot backup itu sendiri tidak bisa dirusak langsung dari sumber

    • Salah satu cara lain adalah memakai container terpisah atau user khusus backup; dengan systemd-nspawn misalnya, ini bisa dipakai seperti chroot jail ringan, dan di dalamnya eksekusi rm bisa diblok sama sekali; cukup buat chroot dengan pacman/pacstrap dan kelola lewat systemd-nspawn/machinectl; pendekatan ini fleksibel karena memungkinkan berbagai kontrol seperti kontrol akses yang mirip systemd biasa, pembatasan path file, batas memori/CPU, hanya mengizinkan akses dari rentang IP tertentu, syarat boot yang lebih rinci, dan sebagainya; saya juga memanfaatkan subvolume BTRFS, dan bila perlu seluruh sistem bisa dipisahkan sepenuhnya dengan systemd-vmspawn; otomatisasi replikasi dengan importctl juga sangat nyaman

    • Saya lebih suka model pull di mana “server backup sama sekali tidak punya hak terhadap server yang dibackup”; bahkan jika server live diretas sampai root, sistem backup tetap tidak terdampak

    • Saya memakai rclone copy untuk backup, dengan API key yang tidak punya izin menghapus objek; kalau disinkronkan seperti rclone sync, datanya bisa ikut terhapus, jadi pendekatan ini lebih aman

    • Saya berharap syncoid punya opsi “klien hanya menyalin snapshot/backup dan penghapusan dikelola langsung oleh server backup”; saat ini kita tetap harus memberi hak hapus, dan itu cukup disayangkan

  • Mengejutkan betapa banyak orang tidak menganggap backup itu penting, dan ini berlaku di perusahaan besar maupun kecil; perusahaan dengan omzet tahunan 1 miliar euro yang saya konsultani pun tidak punya backup sendiri dan hanya bergantung pada salinan disk tidak teratur yang dilakukan penyedia datacenter; mereka juga tidak pernah menguji pemulihan sendiri; belum lama ini, karena kesalahan pengguna, DB produksi benar-benar hilang total, dan backup terbarunya berumur 4 hari, sehingga semua transaksi selama itu harus direkonstruksi; tetapi bahkan setelah insiden seperti ini, tidak ada yang benar-benar terguncang dan semuanya berlalu seperti hari biasa

    • Sepertinya mereka menganggap itu tidak masalah selama memang tidak benar-benar fatal bagi bisnis

    • Saya juga sering melihat kebutuhan backup dibuat terlalu rumit secara berlebihan

    • Mungkin juga karena isu hukum; akibat gugatan atau kewajiban retensi hukum, backup itu sendiri justru bisa menjadi faktor risiko

    • Ini efek samping dari kebijakan disaster recovery yang lolos audit soc2; di perusahaan tempat saya bekerja, kami meninjau kebijakan disaster recovery semua tim, semuanya disetujui soc2, dan pada akhirnya kami sampai pada kesimpulan bahwa kalau terjadi insiden besar sungguhan, menutup perusahaan lalu pulang ke rumah akan lebih cepat daripada pemulihan normal

    • Kalau kehilangan data 4 hari penuh dari DB produksi itu benar-benar terjadi, saya penasaran apakah pelanggan tidak marah; di perusahaan sebesar itu rasanya dampaknya pasti sangat besar, jadi saya ingin tahu bagaimana mereka menanganinya dalam praktik

  • Terima kasih sudah membagikan ini; setelah 10 tahun mengembangkan software backup dan disaster recovery, ada satu nasihat yang selalu muncul: “jangan menyuruh teman membangun solusi backup/disaster recovery sendiri”; membangun BCDR penuh dengan jebakan yang mudah terlewat, jadi saya ingin membagikan beberapa poin penting; backup bukanlah ‘disaster recovery’; ketika insiden sungguhan terjadi, pemulihan harus bisa dilakukan dalam hitungan menit sampai jam agar kepercayaan bisnis tetap terjaga; waktu pemulihan (RTO) dan titik pemulihan (RPO) adalah kuncinya; replikasi file dengan model rsync copy saja bukan backup titik waktu karena filesystem terus berubah; untuk backup titik waktu yang benar dibutuhkan backup yang ‘crash consistent’ atau ‘application consistent’, dan yang terakhir berarti aplikasi penting menuliskan state-nya ke disk lalu dihentikan selama proses backup; fitur seperti Microsoft VSS menangani bagian ini; jangan pernah terlalu percaya pada rsync copy atau bahkan backup yang crash consistent; pada storage, hukum Murphy selalu berlaku, jadi backup di beberapa lokasi (strategi 3-2-1) itu wajib; dari pengalaman langsung saya, semua jenis disk pada akhirnya gagal; NVMe SSD > SSD > HDD memang lebih baik dari sisi daya tahan, tetapi tidak ada pengecualian; masih banyak yang ingin saya tulis, tetapi sudah larut jadi cukup sampai di sini

    • Analogi 3-2-1 itu cara lama; sekarang lokasi penyimpanan data nyaris tak terbatas, jadi snapshot lokal, replikasi jarak jauh, serta backup ganda atau rangkap tiga dengan metode berbeda jauh lebih penting; saya memakai snapshot dasar dengan zfs dan tambahan Borg, dan kombinasi ini cukup untuk hampir semua bencana

    • Nasihat itu mengingatkan saya pada ucapan serupa yang pernah saya dengar di konser Alice in Chains; solusi BCDR adalah simbol kepercayaan antarbisnis; sistem seperti ini melindungi data senilai puluhan sampai ratusan triliun, dan kalau saya CTO, saya tidak akan pernah mempercayakan backup perusahaan pada pendekatan open source; pengeluaran IT perusahaan pada umumnya meningkat bertahap sesuai nilai aset dan strategi anti-vendor lock-in; dari pengalaman profesional, untuk pencegahan ransomware, immutability dan backup WORM adalah inti, dan saya juga melihat banyak kasus di IT pemerintah yang bermasalah karena ketidakpatuhan regulasi; vendor BCDR menjual ransomware sebagai poin penjualan, tetapi immutability yang sesungguhnya dibuktikan lewat replikasi data di banyak lokasi, dan di sinilah strategi 3-2-1 menunjukkan nilainya; saya ingin mendengar lebih banyak pandangan tentang prinsip backup lainnya

    • Jika memakai NAS, sebaiknya jangan gunakan hard disk dari pabrikan dan model yang sama di kedua sisi

    • Saya sangat setuju dengan “backup di beberapa lokasi itu wajib (3-2-1)”, tetapi bagi kebanyakan orang, angka “1” itu, yaitu offsite, secara realistis mustahil, dan pada akhirnya tidak ada alasan membuat backup sendiri kecuali memakai layanan backup; saya tidak punya siapa pun di sekitar saya yang mau menjalankan komputer 24 jam di luar kota saya dan mengelolanya

    • Bagian “jangan pernah percaya pada rsync copy atau bahkan backup yang crash consistent” pada akhirnya mengarah pada kesimpulan bahwa karena semua sistem/layanan bisa dibangun ulang dengan tool infrastruktur, yang perlu dibackup secara serius hanya DB dan penyimpanan file/objek; backup seluruh VM secara rumit sebenarnya tidak terlalu berarti

  • Tulisannya rapi, tetapi ada satu kekurangan: sistem backup yang benar-benar bagus harus punya kejelasan soal kecepatan dan prosedur pemulihan; saya berkali-kali melihat orang tenang karena merasa backup mereka baik-baik saja, tetapi saat pemulihan justru hanya sebagian yang pulih atau butuh berhari-hari sehingga kerugiannya sangat besar; alat bernama restic berguna karena bisa melakukan backup snapshot deduplikasi tingkat file ketika tidak ada filesystem snapshot seperti ZFS; dan untuk model backup push, ransomware bisa saja menghapus backup juga, jadi model pull memang lebih tepat; kalau tetap push, menurut saya lebih baik memakai media read-only (seperti Bluray) atau setidaknya auto-snapshot/ZFS agar pemulihan titik waktu memungkinkan

    • Meski ransomware bisa menghapus backup push, itu bukan masalah jika hak akses server dibatasi dengan benar; Borg dan Restic bisa menjamin append-only lewat ssh, dan secara lokal saya merotasi drive backup offline sebagai lapisan pertahanan terakhir; caranya ada di sini

    • Saya penasaran, kalau pada mode append-only restic pruning berkala hanya dijalankan dari dalam server, apakah tetap aman tanpa memakai model pull? Setahu saya ini adalah rekomendasi resmi restic untuk perlindungan dari ransomware

    • “Kecepatan pemulihan” itu benar-benar bergantung pada kebutuhan; kalau backup foto keluarga saya butuh 6 bulan untuk dipulihkan pun saya tidak masalah

    • Sebagai alternatif media read-only, server push dengan izin terbatas juga bisa dipakai; misalnya ssh hanya mengizinkan scp, dibatasi ke lingkungan chroot, dan backup diputar per folder setiap hari, maka bahkan ransomware pun tidak bisa menghapus data lama; prosedur backup saya juga dikelola dengan server ssh yang hanya mengizinkan chroot+scp, dan sebagai tambahan saya tetap memakai media read-only

  • Saya tidak merasa perlu sistem backup terpisah; yang saya butuhkan hanya cara standar yang efisien untuk mengumpulkan 25 tahun foto dari keluarga beranggotakan 4 orang—ponsel, kamera, unduhan, hasil scan, dan sebagainya; sampai sekarang saya belum menemukan metode yang benar-benar memuaskan

    • Saya menjalankan Immich di NAS, dan setiap hari membackup media serta dump DB Immich ke AWS S3 Deep Archive; Immich sudah cukup menyediakan fitur seperti Google Photos, dan kalau foto desktop/hasil scan ditambahkan ke NAS, Immich akan mengimpornya otomatis; bagi pengguna HN, pengaturannya tidak terlalu sulit

    • Sambil bercanda bertanya apakah “foto 25 tahun” itu satuan data khas Amerika Utara, dia menunjukkan bahwa sistem backup pada dasarnya tetap wajib; saya menjalankan syncthing dalam mesh di gnu/linux/windows/android, lalu meng-snapshot arsip secara berkala ke dua VM Debian dan membuat backup kedua dengan borgbackup; RPO-nya 24 jam, tetapi bisa diperkecil kalau mau; hanya saja perangkat Apple tidak cocok dengan susunan ini karena syncthing tidak bisa berjalan di background; dalam kasus saya ada 500GB foto dan puluhan sampai ratusan GB dokumen lain, tetapi backup berbasis diff membuatnya efisien

    • Unduhan dan hasil scan, kalau memang tidak penting, pada akhirnya hanyalah data yang akan dibuang juga; ponsel/kamera saya sinkronkan lewat Nextcloud dan backup hanya dijalankan di home network sendiri; setelah itu NAS melakukan backup harian dan pemeriksaan kesehatan; tahap terakhir adalah cloud backup tepercaya atau drive di rumah lain, dan dengan begitu backup sekunder juga selesai

    • Solusi self-hosting seperti PhotoPrism atau Immich berguna untuk deduplikasi foto serta pencarian/tagging; untuk cloud backup, kombinasi Backblaze B2 + Cryptomator memungkinkan storage terenkripsi dengan skrip upload DIY, biayanya sekitar 1 dolar per TB per bulan

    • Saya memakai syncthing; memang secara resmi Android tidak didukung, tetapi fork-nya berjalan baik; selain itu saya merekomendasikan ente.io atau self-hosting immich untuk backup foto, dan dokumen sebaiknya dikelola terpisah dengan sesuatu seperti paperless ngx

  • Dirvish layak dicoba sebagai wrapper rsync ringan; ia menawarkan fitur yang sangat baik seperti rotasi, incremental, retensi, skrip pra/pasca-proses, dan lain-lain; selama lebih dari 20 tahun ia sudah menyelamatkan data saya, dan sangat cocok dengan poin-poin yang dibahas di artikel; situs resmi dirvish, situs resmi rsync

    • Saya penasaran, dibandingkan rsync, bagian mana dari dirvish yang lebih mudah atau lebih unggul?

  • Saya menangani kegagalan hardware sampai isu pencurian dengan pendekatan yang cukup malas sekalipun; kombinasinya adalah penyimpanan sementara internal desktop, disk eksternal di rumah, dan disk eksternal offsite, semuanya Samsung T7 Shield; saya mereplikasi setiap hari dengan robocopy /MIR ke penyimpanan sementara atau setelah selesai bekerja, backup ke disk eksternal seminggu sekali, dan menukar disk eksternal offsite sebulan sekali

    • Untuk disk eksternal, Anda wajib setidaknya memakai batch yang berbeda, atau lebih baik lagi model yang berbeda; kalau model dan lot-nya sama, biasanya kemungkinan gagal bersamaan lebih tinggi, terutama saat beban pemulihan sangat besar

  • Waktunya pas, jadi saya membagikan pengaturan archlinux dan strategi backup saya, serta merilis skrip otomatisasi konfigurasi/backup dan lapisan otomatisasi borg

    • Saya mengotomatisasi snapshot 51 block device SAN, backup 71 filesystem, dan sinkronisasi S3 dengan python+borg; pemulihan sudah saya uji nyata dari lokasi offsite dan boot VM berhasil tanpa masalah; otomatisasinya masih kompleks dan belum tuntas sehingga kecepatan pemulihannya lambat, tetapi sistem ini dibangun dengan biaya sangat murah; borg benar-benar kuat, siapa pun bisa mencoba hal seperti ini, dan hasil akhirnya sangat ekonomis

  • Data berharga yang saya miliki kurang dari 100MiB, jadi saya cukup membackup path yang dipilih dengan tar+kompresi+enkripsi dua kali seminggu, menyimpan rotasi untuk beberapa bulan, dan menaruhnya di dalam maupun di luar rumah; hampir tidak butuh inspeksi atau pemeliharaan, dan beberapa baris skrip sh saja sudah cukup untuk mengotomatisasi semuanya tanpa masalah

    • Jika saya tiba-tiba meninggal besok, saya perlu memikirkan data apa yang benar-benar layak dipulihkan oleh keluarga dan keturunan saya; bisa jadi yang penting bukan ratusan ribu file, melainkan hanya beberapa foto, video, dan teks inti

    • Komentar ini benar-benar membuat saya berpikir ulang tentang data apa yang sebenarnya berharga; foto saya bahkan setelah dikompresi tetap minimal beberapa GB, kontak dan hal yang kurang penting ukurannya kecil, dan selain itu umumnya tidak masalah jika hilang; kunci pemulihan memang harus saya simpan lebih aman, tetapi justru akun-akun terpenting saya malah tidak punya recovery key; foto saja sudah mendekati 2TB (nestapa fotografer hobi)

  • Bagian tersulit dalam konsistensi backup adalah kenyataan bahwa membackup data aplikasi secara konsisten tanpa downtime layanan pada praktiknya hampir mustahil; dengan snapshot disk, pada saat pengambilan snapshot pasti ada layanan yang sedang mid-write, sehingga saat dipulihkan besar kemungkinan langsung masuk ke keadaan rusak; dump DB banyak membantu mengurangi masalah ini, tetapi sering kali backup juga harus dilakukan dari luar layanan sehingga bisa saja terjadi di tengah query; kalau ada yang punya pengalaman atau teknik untuk hal ini, saya ingin mendengarnya

    • Secara umum DB cukup tangguh dalam hal ini, jadi menurut saya snapshot disk kapan saja tetap cukup untuk keperluan backup; yang lebih mengkhawatirkan adalah situasi khusus seperti cache tanpa baterai, tetapi di cloud modern dan sejenisnya struktur seperti itu hampir tidak ada lagi jadi biasanya bukan masalah besar

    • Selain DB, strateginya juga bergantung pada apakah ada state aplikasi lain yang perlu ditangkap, misalnya apakah cache juga harus dibackup; pg_dump/mysqldump memang memungkinkan snapshot DB live dengan aman, tetapi agak lambat dan dump-nya bisa membesar; untuk menghindari masalah ini, saya juga pernah memakai replica read-only khusus backup pada DB PostgreSQL yang besar, menghentikan replikasi sebentar lalu menjalankan backup, dan setelah itu melanjutkan replikasi lagi