Setiap backup berfungsi baik sampai hari ia benar-benar dibutuhkan. Snapshot-nya berada di platform yang baru saja down. Tarball malam hari sudah gagal diam-diam sejak sebuah disk penuh pada bulan Maret. Dump database-nya adalah salinan file yang diambil di tengah proses tulis dan hasilnya nihil saat dipulihkan. Backup adalah satu-satunya bagian dari server yang tidak bisa Anda nilai hanya dengan melihatnya — hanya bisa dinilai dengan cara memulihkannya. Berikut cara membangun backup yang bertahan dari kegagalan hardware, tangan Anda sendiri, dan orang lain yang memegang kredensial Anda, tanpa memberikan salinan yang bisa dibaca dari mesin itu kepada siapa pun yang menyimpannya.
Empat hal menghancurkan server, dan masing-masing butuh penanganan yang berbeda
Rancang backup di sekitar kegagalannya, bukan di sekitar toolnya. Empat skenario ini mencakup hampir semua kehilangan data yang nyata, dan masing-masing menuntut hal berbeda dari salinan yang Anda simpan. Sebuah setup yang menangani salah satu skenario akan terasa sudah cukup memadai sampai ia bertemu skenario yang lain.
Kegagalan hardware atau host
Disknya, node-nya, atau datacenter-nya yang tumbang. Salinan apa pun yang disimpan di tempat lain akan menyelamatkan Anda. Ini satu-satunya kegagalan yang benar-benar bisa diandalkan untuk ditangani oleh snapshot pada platform yang sama, dan itulah persisnya kenapa begitu banyak orang percaya snapshot saja sudah cukup.
Tangan Anda sendiri
Flag yang salah, skrip migrasi yang diarahkan ke production, pembersihan yang menghapus lebih banyak dari yang dimaksud. Kerusakannya langsung tereplikasi ke mana pun yang melakukan mirroring, jadi yang menyelamatkan Anda adalah histori — versi dari sebelum kesalahan terjadi, bukan salinan terkini dari setelahnya.
Kompromi dan ransomware
Penyerang yang memegang akses root punya jangkauan yang persis sama dengan job backup Anda: kredensial yang sama, tujuan yang sama, jadwal yang sama. Jika server bisa menghapus backup-nya sendiri, backup itu akan dihapus. Kelangsungan hidupnya bergantung pada apakah salinannya append-only atau sepenuhnya di luar jangkauan.
Kehilangan akun, bukan server
Tagihan yang telat, akun yang disuspend, takedown di yurisdiksi yang salah. Hardware-nya baik-baik saja dan Anda sekadar tidak bisa menjangkaunya. Hanya salinan di bawah provider yang berbeda, dengan jalur pembayaran yang berbeda, yang bisa menolong di situasi ini.
Tuliskan yang mana dari keempat skenario ini yang sebenarnya sedang Anda antisipasi, sebelum memilih apa pun. Salinan setiap malam ke direktori kedua pada disk yang sama hanya menangani satu dari keempatnya — yang paling kecil kemungkinannya — sambil tetap terasa sepenuhnya seperti sebuah backup. Kebanyakan setup yang gagal di production gagal karena tidak ada yang pernah menamai skenarionya.
Snapshot bukan backup
Kedua istilah ini sering dipakai bergantian, padahal mendeskripsikan objek yang berbeda dengan domain kegagalan yang berbeda pula. Mengetahui yang mana yang sebenarnya Anda punya menentukan apakah Anda punya apa-apa sama sekali.
Gunakan snapshot untuk apa yang sungguh-sungguh menjadi keunggulannya: undo lima detik sebelum Anda menyentuh kernel, bootloader, atau skema database. Ambil satu snapshot, lakukan hal berisiko itu, hapus snapshotnya begitu semuanya berhasil. Yang tidak boleh pernah Anda lakukan adalah membiarkan "kan sudah ada snapshot" menjadi alasan untuk tidak punya backup — snapshot berbagi nasib dengan platform yang menyimpannya, dan satu akun yang disuspend akan membawa keduanya sekaligus.
3-2-1, dan dua angka yang selalu dilewatkan orang
Aturan lama ini masih bertahan karena ia mendeskripsikan independensi, bukan sekadar sistem penyimpanan berkas: tiga salinan data, pada dua jenis storage yang berbeda, satu di antaranya di tempat lain. Dua tambahan berikut menangani kegagalan yang dulunya jarang terjadi saat aturan ini ditulis, tapi sekarang sudah jadi hal rutin.
- Tiga salinan. Data live ditambah dua backup. Dua salinan berarti Anda hanya berjarak satu restore yang gagal dari tidak punya apa-apa sama sekali.
- Dua media, atau dua provider. Di infrastruktur sewaan, "media" sebenarnya berarti independensi administratif — salinan kedua di bawah akun yang sama, di platform yang sama, dibayar dari saldo yang sama, tetap saja satu salinan dengan langkah tambahan.
- Satu offsite. Gedung berbeda, jaringan berbeda, yurisdiksi berbeda jika itu penting bagi Anda. /locations adalah versi praktis dari prinsip ini: pilih region yang gagalnya independen dari region yang sedang Anda lindungi.
- Satu yang immutable atau offline. Salinan yang tidak bisa dihapus oleh server itu sendiri, karena siapa pun yang memiliki server juga memiliki kredensialnya.
- Nol restore yang belum diverifikasi. Backup yang belum pernah Anda restore hanyalah sebuah hipotesis. Angka yang benar-benar berarti adalah berapa kali Anda sudah menyelesaikan restore, bukan berapa kali job melaporkan sukses.
Backup datanya, bangun ulang sisanya
Insting pertama biasanya adalah meng-image semuanya. Cara ini mahal, lambat untuk di-restore, dan dengan setia melestarikan binary yang sudah dikompromikan, kondisi package yang rusak, dan config drift yang bahkan sudah tidak Anda ingat kapan terciptanya. Sebuah server menyimpan tiga jenis konten, dan hanya satu di antaranya yang layak masuk backup.
- Sertakan /etc, /home, /root, /srv, web root Anda, direktori state aplikasi Anda, named container volume, dan direktori berisi dump database yang segar.
- Sertakan juga resep deployment-nya sendiri — compose file, skrip Ansible atau shell, catatan yang Anda tulis jam 2 pagi. Simpan juga di version control, tapi taruh satu salinan di dalam backup supaya pemulihan tidak pernah bergantung pada bisa dijangkaunya sebuah service kedua.
- Kecualikan /proc, /sys, /dev, /run, dan direktori temporary. Semua itu adalah interface kernel dan scratch space; menyalinnya hanya membuang waktu atau membuat job-nya hang begitu saja.
- Kecualikan package cache, direktori build, dependency tree, dan virtualenv — apa pun yang akan dibuat ulang oleh langkah build. Di server aplikasi yang tipikal, ini adalah sebagian besar isi disknya.
- Kecualikan file database live jika Anda sudah men-dump database-nya dengan benar. Mem-backup keduanya sekaligus berarti salinan yang lebih besar dan tidak berguna itulah yang malah di-restore seseorang pada jam tiga pagi.
- Jangan kecualikan hidden file. Separuh dari hal yang penting di mesin Linux namanya dimulai dengan titik.
Database tidak akan selamat dari sekadar salinan file
Ini adalah alasan tunggal paling umum sebuah restore gagal. Database yang sedang berjalan menyimpan state di memori dan menulis tidak berurutan; menyalin file-filenya selagi ia berjalan menangkap state yang robek, setengah tertulis, yang bisa saja ter-restore, bisa saja ter-restore dengan korupsi diam-diam, atau bisa saja sama sekali tidak ter-restore. Ambil dump yang benar, baru backup dump itu.
- PostgreSQL: pg_dump per database, atau pg_dumpall untuk seluruh cluster termasuk role-nya. Di tempat yang tidak bisa menoleransi kehilangan satu hari data, tambahkan WAL archiving supaya Anda bisa memulihkan ke satu titik waktu tertentu, bukan sekadar ke semalam.
- MySQL atau MariaDB: mysqldump dengan --single-transaction memberi snapshot yang konsisten pada InnoDB tanpa memblokir penulisan. Ini tidak berlaku pada MyISAM — satu alasan lagi untuk tidak menjalankan MyISAM. Untuk dataset besar, tool fisik seperti mariabackup melakukan restore jauh lebih cepat dibanding memutar ulang sebuah dump.
- SQLite: jangan pernah menyalin filenya langsung. Gunakan perintah .backup atau VACUUM INTO, yang mengambil lock dengan benar. Menyalin database yang write-ahead log-nya sedang aktif adalah sebuah taruhan, dan cepat atau lambat Anda akan kalah.
- Redis: picu background save dan backup file snapshot yang dihasilkannya, atau jalankan dengan mode append-only dan backup log-nya. Menyalin snapshot yang live di tengah proses tulis akan menghasilkan file yang terpotong dan termuat sebagai dataset kosong.
- Container: volume-nya adalah datanya. Hentikan stack-nya selama beberapa detik yang dibutuhkan proses penyalinan, atau jalankan tool dump-nya di dalam container — tapi jangan mem-tar volume database yang sedang berjalan lalu menyebutnya backup.
- Apa pun lainnya yang punya proses persisten — search index, message queue, ledger daemon — punya perintah consistent-export miliknya sendiri. Temukan perintah itu sekarang, bukan saat outage sedang terjadi.
Filesystem snapshot menyelesaikan ini dari arah yang berlawanan: LVM, ZFS dan btrfs membekukan sebuah tampilan volume yang konsisten dalam hitungan milidetik, dan Anda mem-backup tampilan yang beku itu selagi database-nya terus melayani. Itu jawaban yang tepat untuk dataset yang proses dump-nya memakan waktu berjam-jam. Tapi itu bukan alasan untuk melewatkan dump pada database 200 MB, di mana dump justru lebih sederhana, portabel lintas versi engine, dan bisa dibaca manusia ketika sesuatu terasa janggal.
Memilih tool
Empat tool mencakup hampir semua kasus. Properti yang paling penting adalah di mana enkripsi itu terjadi. Jika data hanya dienkripsi in transit, lalu at rest oleh storage provider, storage provider itu bisa membacanya — dan backup-nya diam-diam menjadi titik terlemah dalam sistem yang sudah Anda hardening di semua tempat lain.
Apa pun yang Anda pilih, passphrase atau key-nya harus ada di tempat lain selain server yang sedang di-backup. Inilah jebakan yang menjerat orang-orang yang sudah berhati-hati: key repository tersimpan di /root, dengan setia ikut ter-backup di dalam repository yang dibukanya sendiri. Cetak key itu, atau simpan di password manager yang bisa Anda buka dari mesin yang masih hidup. Repository yang tidak bisa Anda dekripsi tidak ada bedanya dengan tidak punya backup sama sekali.
Di mana salinan kedua sebaiknya disimpan
Tujuannya adalah soal yurisdiksi dan hubungan penagihan, sama besarnya dengan soal ruang disk. Berikut empat opsi, disusun kira-kira berdasarkan seberapa independen masing-masing dari server yang sedang Anda lindungi.
Server kedua di region lain
Jawaban paling langsung: instance murah di negara lain, bisa dijangkau lewat SSH, yang tidak menjalankan apa pun selain sshd dan sebuah repository. Paket /vps 1 GB sudah cukup menampung backup untuk armada kecil, dan akunnya bisa dikunci ke satu forced command supaya key yang dicuri sekalipun tidak membuka shell apa pun.
Disk kelas storage
Begitu dataset-nya sudah mencapai ratusan gigabyte, kapasitas HDD pada uplink unmetered berbiaya jauh lebih murah per terabyte dibanding NVMe, dan penulisan backup tidak butuh latensi seringan NVMe. /storage dibangun untuk kebutuhan ini: disk RAID kelas terabyte, full root, tanpa inspeksi konten.
Object storage yang kompatibel S3
Praktis, harganya per gigabyte, dan sering dilengkapi dukungan object-lock yang memberikan immutability sungguhan. Baca dulu harga egress-nya sebelum mengandalkannya — menarik kembali satu terabyte data saat keadaan darurat adalah momen yang buruk untuk baru menyadari berapa biaya retrieval-nya.
Hardware milik Anda sendiri
Disk eksternal atau mesin di rumah, di-pull, bukan di-push. Lebih lambat dan manual, dan satu-satunya salinan dalam daftar ini yang tidak bisa disentuh oleh provider mana pun, perintah pengadilan, atau sengketa tagihan. Layak dipertahankan untuk data yang sungguh-sungguh tidak bisa Anda buat ulang, meskipun tertinggal seminggu di belakang.
Selaraskan properti privasi backup dengan properti privasi server aslinya. Mengenkripsi disk dengan LUKS lalu mengirim backup plaintext setiap malam ke sebuah bucket yang terdaftar atas nama kartu Anda membatalkan seluruh usaha itu: datanya kini bisa dibaca, dan tercatat atas nama Anda. Jika server itu layak dibayar secara anonim, begitu juga salinannya — enkripsi secara client-side, dan beli tujuannya dengan cara yang sama seperti Anda membeli asalnya.
Membangunnya, langkah demi langkah
- 1
Tentukan dulu dua angkanya
Berapa banyak data yang sanggup Anda relakan hilang — jarak antar-run — dan berapa lama Anda sanggup down. Segala sesuatu yang lain mengikuti dari kedua jawaban ini. Backup setiap jam untuk situs statis hanyalah sandiwara; backup setiap malam untuk database order adalah keputusan yang harus diambil secara sadar, bukan sekadar diwarisi dari sebuah tutorial.
- 2
Buat tujuannya
Instance kedua di region lain dengan SSH key-nya sendiri dan user unprivileged khusus yang home-nya adalah repository itu. Tidak ada yang lain berjalan di situ. Batasi key-nya ke sebuah forced command supaya kredensial yang dicuri hanya bisa menambahkan backup, tidak pernah bisa membuka shell.
- 3
Generate key-nya dan simpan di tempat lain
Passphrase acak yang panjang, dicatat di tempat yang tetap bertahan sekalipun server-nya hilang. Inisialisasi repository-nya, lalu buktikan Anda bisa menampilkan daftar isinya dari mesin ketiga hanya dengan bermodalkan apa yang Anda catat. Kalau tidak bisa, perbaiki dulu itu sebelum menulis satu pun backup.
- 4
Dump database-nya terlebih dahulu
Skrip pendek yang menulis dump-dump yang konsisten ke sebuah direktori staging dan keluar dengan status non-zero jika ada satu saja yang gagal — dijalankan sebelum backup file, bukan bersamaan dengannya. Job yang tetap melanjutkan setelah sebuah dump gagal adalah cara orang berakhir dengan tiga puluh hari file berukuran nol byte.
- 5
Backup path-path yang penting
Arahkan tool-nya ke include list, terapkan exclude-nya, dan sanity-check run pertamanya. Jika repository baru dari server 40 GB hanya menjadi 300 MB, ada sesuatu yang diam-diam terlewat; jika menjadi 38 GB, exclude Anda tidak bekerja.
- 6
Jadwalkan, dan buat kegagalannya berisik
Sebuah systemd timer dengan delay acak, atau cron kalau itu yang sudah menjadi kebiasaan Anda. Lalu buat job-nya melapor: sebuah heartbeat ke monitor saat berhasil, dan alert ketika heartbeat itu berhenti datang. Kegagalan diam-diam adalah mode kegagalan normal untuk backup, karena tidak ada yang terlihat rusak saat backup-nya berhenti — sampai akhirnya semuanya rusak.
- 7
Atur retensi, dan benar-benar pangkas
Per jam untuk satu hari, harian untuk dua minggu, mingguan untuk beberapa bulan, bulanan untuk satu tahun. Lalu jalankan pemangkasannya dan pastikan repository-nya berhenti membesar. Retensi yang sudah dikonfigurasi tapi tidak pernah benar-benar dijalankan akan memenuhi tujuannya dan menjatuhkan backup-nya bersamanya.
- 8
Restore sesuatu hari ini juga
Bukan sekadar test job — satu file sungguhan, ke direktori scratch, dibuka dan diperiksa. Lalu masukkan tanggal ke kalender untuk restore seluruh mesin. Restore penuh pertama selalu memunculkan sesuatu: path yang hilang, sebuah permission, sebuah sertifikat, user database yang ternyata cuma pernah ada di mesin lama.
Push backup dari server ke luar, dan Anda sudah menerima konsekuensi bahwa siapa pun yang punya akses root di situ bisa menghancurkan setiap salinannya. Jalankan dengan arah sebaliknya — host backup yang menghubungi ke dalam, melakukan pull, lalu memutus koneksi — dan server yang sudah dikompromikan sama sekali tidak bisa menjangkau repository-nya, karena ia tidak memegang kredensial apa pun untuknya. Pull memang lebih repot untuk disiapkan, tapi ini adalah perbaikan tunggal terbesar yang bisa dilakukan kebanyakan setup.
Retensi, dan kenapa lebih lama justru lebih murah dari kedengarannya
Retensi biasanya diatur sekadar mengikuti apa yang muat di disk, lalu dilupakan begitu saja. Ini layak dipikirkan secara sadar, satu kali saja, karena ia menentukan kesalahan mana yang masih bisa dipulihkan. Jendela tujuh hari akan menangkap file yang terhapus hari Selasa. Tapi tidak akan menangkap korupsi yang sudah mulai enam minggu lalu dan baru muncul ke permukaan ketika sebuah laporan keluar dengan hasil yang salah, atau penyusup yang duduk diam di mesin itu selama sebulan sebelum bertindak.
Deduplikasi membuat semua ini jauh lebih murah dari yang terkesan dari tabel di atas: run kedua terhadap server yang sebagian besar tidak berubah hanya menyimpan apa yang berubah, sehingga satu tahun restore point bulanan pada mesin 40 GB biasanya hanya berbiaya beberapa gigabyte, bukan setengah terabyte. Tetapkan kebijakannya berdasarkan apa yang perlu Anda pulihkan, lalu periksa tagihannya. Anda biasanya akan mendapati bahwa Anda sanggup memilih kebijakan yang lebih longgar.
Immutability: bagian yang menghentikan ransomware
Semua yang di atas mengasumsikan musuhnya adalah entropi. Jika musuhnya adalah seseorang yang memegang akses root, job backup yang biasa saja justru menjadi buku petunjuk baginya — kredensialnya ada di mesin itu, tujuannya ada di config, dan repository-nya akan dihapus sebelum proses enkripsi dimulai. Empat mekanisme berikut memutus rantai itu, dan satu saja dari keempatnya sudah mengubah hasil akhirnya.
- Repository append-only. Mode append-only server-side milik Borg, atau REST server milik restic dalam mode append-only, menerima data baru dan menolak penghapusan. Server-nya bisa menulis; hanya Anda, dari tempat lain, yang bisa memangkas.
- Backup berbasis pull. Host backup yang memulai koneksinya dan memegang satu-satunya kredensial yang ada. Server production tidak punya key, tidak punya alamat tujuan, dan sama sekali tidak punya jalur menuju repository-nya.
- Object lock. Storage yang kompatibel S3 dengan periode retensi yang dipaksakan pada level bucket, di mana penghapusan ditolak oleh storage layer itu sendiri, apa pun yang sebenarnya diizinkan oleh kredensialnya.
- Kredensial terpisah per host. Satu mesin yang dikompromikan tidak seharusnya membuka histori semua mesin lainnya. Key yang berbeda, path yang berbeda, pembatasan yang berbeda.
- Satu salinan yang sungguh-sungguh offline. Disk yang dicabut kabelnya kebal terhadap setiap serangan remote yang pernah dibuat. Kuno, tapi tidak terkalahkan.
Latihan restore
Restore adalah sebuah prosedur, dan prosedur yang belum pernah dijalankan siapa pun hanyalah fiksi. Jalankan ini sekali sekarang dan sekali setiap enam bulan, dan catat apa yang Anda pelajari — catatan itu pada akhirnya sama berharganya dengan datanya sendiri.
- 1
Deploy instance kosong
Versi sistem operasi yang sama, tidak ada yang lain terinstal. VPS yang berumur pendek saja sudah cukup, dan seluruh latihan ini biayanya kurang dari harga makan siang.
- 2
Restore hanya dengan bermodalkan apa yang sudah Anda catat
Alamat repository, passphrase, perintah-perintahnya. Jika Anda butuh sesuatu yang hanya ada di server yang sedang Anda anggap sudah mati, Anda baru saja menemukan celahnya — pada hari ketika menemukannya tidak berbiaya apa-apa.
- 3
Kembalikan datanya sebelum aplikasinya
Muat dump database-nya, taruh file-filenya di tempat semestinya, lalu perbaiki ownership dan mode-nya. Ownership biasanya jadi kejutan yang paling umum: user ID numerik dari mesin lama jarang cocok begitu saja di mesin yang baru.
- 4
Jalankan service-nya dan benar-benar gunakan
Bukan sekadar perintah status — login, muat sebuah halaman, jalankan sebuah query, kirim sebuah pesan. Service yang berhasil start bukanlah hal yang sama dengan service yang benar-benar berfungsi.
- 5
Ukur waktunya, dan catat angkanya
Berapa lama seluruh prosesnya berlangsung? Itulah recovery time Anda yang sebenarnya, dan hampir selalu berkali-kali lipat dari estimasi awal. Simpan catatannya berdampingan dengan passphrase, dan perbarui keduanya setiap kali stack-nya berubah.
Berapa biayanya, secara jujur
Backup adalah asuransi termurah dalam infrastruktur, dan justru rutin dilewatkan karena alasan harga. Berikut beberapa angka konkret untuk server kecil, dengan asumsi datanya terkompresi dan ter-deduplikasi selayaknya data pada umumnya.
Bandingkan angka mana pun di atas dengan biaya outage yang berhasil dicegahnya. Menyebutkan angkanya justru itulah intinya — argumen menentang backup nyaris tidak pernah benar-benar soal uang begitu uangnya sudah dituliskan dengan jelas.
Di mana host berperan
Sebuah rencana backup punya dua dependensi yang sama dengan server yang dilindunginya: tempat independen untuk menaruh salinannya, dan cara membayarnya yang tidak menciptakan catatan baru tentang siapa Anda. Keduanya justru lebih penting di sini dibanding di sisi asalnya, karena backup adalah salinan lengkap dari segala sesuatu yang dilindungi oleh server asal itu.
Setiap paket /vps dan /storage di sini di-deploy dari saldo crypto prabayar tanpa KYC, di lima belas region yang tercantum di /locations — sehingga salinan kedua bisa berada di bawah yurisdiksi yang berbeda dari yang pertama, tanpa satu pun pemeriksaan identitas tambahan di sepanjang rantainya. Snapshot instan disertakan di setiap instance untuk undo lima detik, bandwidth unmetered berarti baik upload pertama maupun restore darurat sama-sama bukan peristiwa yang dihitung meteran, dan /storage menambahkan disk RAID kelas terabyte mulai dari $8.99/mo tanpa inspeksi konten. /pay-with membahas koin yang diterima, /offshore-hosting menjabarkan apa yang sungguh-sungguh berubah karena yurisdiksi, dan /guides punya tulisan pendamping soal enkripsi disk serta soal apa yang bisa dan tidak bisa dilihat host tentang sebuah mesin.
Checklist-nya
- Namai dulu kegagalan yang sedang Anda antisipasi sebelum memilih tool.
- Perlakukan snapshot sebagai tombol undo, jangan pernah sebagai backup itu sendiri.
- Backup data dan konfigurasi; bangun ulang sistem operasinya dari sebuah skrip.
- Dump setiap database dengan perintah consistent-export miliknya masing-masing, lalu backup dump itu.
- Enkripsi secara client-side, sebelum apa pun meninggalkan mesin.
- Simpan passphrase repository di tempat yang tetap bertahan sekalipun server-nya hilang.
- Taruh setidaknya satu salinan di bawah provider, region, dan jalur pembayaran yang berbeda.
- Buat satu salinan bersifat append-only, berbasis pull, atau offline supaya akses root yang sudah dikompromikan tidak bisa menghapusnya.
- Beri alert atas ketiadaan run yang berhasil — kegagalan itu sunyi, dan kesunyian itulah gejalanya.
- Restore satu file hari ini, dan seluruh mesin dua kali setahun. Ukur waktunya dan catat.
Apakah snapshot dari provider saja sudah cukup?
Tidak, dan ini adalah celah paling umum pada setup yang sebenarnya sudah cukup berhati-hati. Snapshot hidup di platform yang sama dengan volume yang disalinnya, sehingga tidak akan selamat dari kegagalan level platform, suspensi akun, atau tagihan yang telat — tiga skenario yang justru paling Anda butuhkan snapshot untuk menghadapinya. Snapshot juga biasanya hanya menyimpan histori yang singkat, sehingga tidak akan bisa memulihkan file yang terhapus bulan lalu atau korupsi yang sudah mulai enam minggu lalu. Snapshot sangat unggul sebagai undo lima detik sebelum sebuah perubahan berisiko: simpan snapshot-nya, gunakan setiap hari, dan tetap simpan backup sungguhan di tempat lain.
restic atau Borg — mana yang sebaiknya saya pakai?
restic jika tujuannya object storage atau sekadar akun SSH biasa, karena ia tidak butuh apa pun terinstal di ujung sana dan mendukung S3 secara native. Borg jika tujuannya mesin Linux yang Anda kendalikan sendiri dan Anda menginginkan mode server append-only-nya serta kompresi yang sedikit lebih rapat. Keduanya sama-sama melakukan deduplikasi, sama-sama mengenkripsi dan mengautentikasi secara client-side, keduanya matang dan sudah dipakai secara luas, dan memilih yang mana pun bisa dipertanggungjawabkan. Jawaban yang salah adalah menghabiskan sebulan membanding-bandingkan keduanya selagi server Anda sama sekali belum punya backup — pilih salah satu sore ini juga, dan ubah pikiran Anda nanti kalau itu benar-benar jadi soal.
Seberapa sering saya harus mem-backup VPS?
Intervalnya sekadar jumlah maksimum pekerjaan yang rela Anda ulangi. Untuk situs statis, mingguan sudah jujur adanya. Untuk apa pun yang ditulisi oleh pengguna, setiap malam adalah batas minimalnya, dan setiap jam pun murah begitu deduplikasi sudah bekerja — run kedua di hari yang sama biasanya hanya menyimpan beberapa megabyte. Timbang nilai data satu hari terhadap biaya menyimpan dua puluh empat restore point dibanding hanya satu, dan jawabannya biasanya sudah jelas dengan sendirinya.
Haruskah saya mem-backup seluruh disk atau cukup data saya saja?
Data dan konfigurasi, di hampir semua kasus. Disk image penuh memulihkan mesinnya persis seperti apa adanya, termasuk kompromi yang sedang ingin Anda pulihkan dan kondisi package yang sudah tidak Anda pahami lagi, dan ia juga lebih lambat baik saat dibuat maupun saat di-restore. Backup tingkat file untuk /etc, data aplikasi Anda, dan dump database Anda, dipadukan dengan skrip yang membangun ulang sistem operasinya, ter-restore lebih cepat dan lebih bersih. Buat disk image hanya ketika Anda butuh preservasi forensik yang bit-exact, atau ketika mesinnya adalah black box buatan orang lain.
Provider saya bilang disknya terenkripsi — apakah backup saya juga terenkripsi?
Tidak, tidak dalam pengertian apa pun yang benar-benar menolong Anda. Enkripsi sisi provider melindungi dari kejadian drive dibawa keluar dari rak; provider itu sendiri yang memegang key-nya, sehingga datanya tetap bisa dibaca oleh provider dan oleh siapa pun yang bisa memaksa provider itu. Enkripsi client-side — restic, Borg, crypt layer milik rclone, atau sebuah arsip terenkripsi — berarti apa pun yang sampai di tujuan tidak bermakna apa-apa tanpa passphrase yang tidak pernah meninggalkan mesin Anda. Untuk stack yang privasinya kritis, perbedaan ini adalah keseluruhan intinya, karena backup adalah salinan lengkap dari segala sesuatu yang dilindungi server tersebut.
Bagaimana cara mencegah ransomware ikut mengenkripsi backup saya juga?
Anggap saja apa pun yang bisa dijangkau server, penyerang yang memegang akses root juga bisa menghancurkannya — kredensial, tujuan, dan jadwalnya semua duduk di mesin itu. Putus jangkauan itu dengan salah satu dari tiga cara: repository append-only yang menerima penulisan tapi menolak penghapusan, model pull di mana host backup yang menghubungi ke dalam dan server sama sekali tidak memegang kredensial apa pun, atau object storage dengan lock yang dipaksakan oleh storage layer itu sendiri. Lalu tambahkan retensi yang panjang, supaya kompromi yang lambat dan diam-diam tidak begitu saja keluar dari jendela retensi sebelum ada yang menyadarinya, dan simpan satu salinan offline di tempat yang tidak bisa dijangkau serangan remote mana pun.
