Backup VPS yang Benar-Benar Bisa Dipulihkan

Strategi backup tidak pernah diuji pada malam server itu mati. Ia diuji berminggu-minggu sebelumnya, lewat tiga keputusan sunyi yang tak pernah dicatat siapa pun: ke mana salinan itu pergi, siapa yang boleh menghapusnya, dan apakah ada orang yang benar-benar pernah membaca salinan itu kembali.

Hosting yang tidak pernah menanyakan identitas Anda memberikan sesuatu sebagai gantinya, dan inilah tempat yang jujur untuk mengatakannya. Tidak ada manajer akun yang bisa dihubungi, tidak ada tiket yang bisa menghidupkan kembali volume yang telah dihapus, dan kebijakan retensi kami sendiri terus terang soal alasannya: data server dihancurkan dalam 24 jam setelah terminasi, disk dihapus secara kriptografis alih-alih diformat, dan tidak ada backup yang disimpan. Itulah properti yang sama yang membuat platform ini layak dibeli, dilihat dari sisi lain. Apa pun yang ingin Anda kembalikan setelah malam yang buruk harus sudah berada di tempat lain, dan Andalah yang menaruhnya di sana.

Apa yang benar-benar merusak server

Hampir tidak ada orang yang kehilangan server dengan cara yang mereka bayangkan. Kegagalan perangkat keras yang fatal itu nyata tapi jarang terjadi, dan inilah satu-satunya kasus yang sudah diantisipasi oleh host yang kompeten. Kehilangan yang benar-benar terjadi jauh lebih membosankan, dan masing-masing mengalahkan jenis salinan yang berbeda — itulah sebabnya "saya punya backup" bukan jawaban sampai Anda sebutkan salinan mana yang bertahan dari yang mana.

Bacalah tabel itu sebagai daftar periksa, bukan daftar ketakutan. Salinan setiap malam ke disk kedua di mesin yang sama hanya menjawab baris pertama dan tidak lebih. Snapshot di panel yang sama menjawab baris pertama dan kedua. Hanya salinan yang disimpan di tempat yang tidak bisa dijangkau server, di bawah kunci yang masih Anda miliki, yang menjawab kelima-limanya.

Snapshot bukan backup, dan host Anda juga bukan

Snapshot unggul dalam tugasnya: ia mengembalikan upgrade yang gagal, dalam hitungan detik, tanpa transfer data. Yang tidak bisa dilakukannya adalah bertahan dari hal yang merenggut server itu sendiri, karena ia berbagi setiap failure domain dengannya — penyedia yang sama, akun yang sama, token billing yang sama, negara yang sama, sering kali storage cluster yang sama. Snapshot melindungi Anda dari diri Anda sendiri. Backup melindungi Anda dari segala hal lainnya.

Perbedaan ini lebih penting di sini dibanding di host mainstream, karena jaring pengaman yang biasa memang sengaja disingkirkan. Tidak ada yang login ke server pelanggan, jadi tidak ada yang menyadari bahwa job backup Anda sudah gagal sejak Maret. Tidak ada identitas yang melekat pada akun, jadi tidak ada jalur manusiawi untuk "buktikan siapa Anda dan kami akan me-restore-nya". Dan terminasi benar-benar final: saldo yang habis adalah peristiwa kehilangan data, bukan peristiwa penagihan.

Aturan 3-2-1, ditulis ulang untuk orang yang tak pernah menunjukkan KTP

Aturan klasiknya berbunyi tiga salinan, pada dua jenis media, salah satunya off-site. Aturan itu ditulis untuk era tape dan spinning disk, dan klausul soal media itu diam-diam sudah tak lagi berarti apa-apa: disk production Anda NVMe, disk target backup Anda juga NVMe, dan menyebutnya "dua media" hanyalah cerita yang Anda buat sendiri. Klausul yang masih layak dipertahankan adalah soal jarak, dan untuk infrastruktur offshore, jarak tidak diukur dalam kilometer.

Tulis ulang menjadi tiga salinan, dua penyedia, dua yurisdiksi. Kegagalan yang melenyapkan kedua salinan sekaligus hampir tidak pernah bersifat fisik — melainkan akun yang aksesnya hilang, penyedia yang sedang mengalami minggu buruk, atau instrumen hukum yang menjangkau satu negara tapi tidak menjangkau negara lain. Dua server dalam rak yang sama hanyalah satu salinan dengan langkah tambahan; dua server di bawah rezim hukum yang sama pun nyaris tak lebih baik. Panduan yurisdiksi kami membahas cara memilih yurisdiksi kedua yang tidak sekadar mencerminkan risiko yurisdiksi pertama.

Dalam praktiknya ini murah. Target backup tidak butuh banyak core, dan nyaris tidak butuh jaringan — ia hanya butuh disk dan sebuah alamat. Tier VPS terkecil di salah satu dari tujuh lokasi kami sudah menjadi endpoint restic atau Borg yang mumpuni, dan untuk arsip berukuran terabyte, server dedicated dengan drive fisik lebih murah per terabyte dibanding object store mana pun. Ketika data benar-benar besar dan jarang dibaca, ekonominya jauh berpihak pada bare metal.

Satu hal yang sering dilakukan benar di production tapi salah di target backup: bayar dengan cara yang sama. Server kedua yang dibeli dengan kartu atas nama asli Anda diam-diam mengembalikan identitas yang sudah susah payah Anda hilangkan dari server pertama — dan sekarang server itu menyimpan salinan lengkap dari segalanya. Jika server production dibayar dengan Monero, server backup pun pantas mendapat perlakuan yang sama.

Salinan ketiga adalah yang paling sering dilewatkan orang, dan justru satu-satunya yang kebal dari semua kegagalan jarak jauh sekaligus: disk yang Anda pegang secara fisik, diperbarui sesekali, disimpan offline. Sebulan sekali sudah cukup bagi kebanyakan orang. Biayanya hanya secangkir kopi dari perhatian Anda, dan inilah salinan yang bertahan dari skenario yang bisa menghantam kedua salinan lainnya sekaligus.

Push, pull, dan kesalahan yang membuat satu malam buruk melahap kedua salinan

Inilah susunan yang hampir semua orang bangun pertama kali. Sebuah job di server production berjalan setiap malam, menyimpan kunci atau token untuk target backup, terhubung, dan melakukan push. Cara ini berjalan, sederhana, dan punya satu sifat yang baru terlihat pada hari terburuk dalam hidup server itu: siapa pun yang menguasai server production juga menguasai backup-nya.

Ini bukan hipotesis. Menghapus atau mengenkripsi backup korban sebelum mengumumkan diri adalah praktik standar bagi siapa pun yang melakukan ini secara komersial — kredensialnya nangkring di cron job atau file environment, dan menemukannya cuma butuh waktu semenit. Salinan yang bisa dihapus penyerang bukanlah salinan kedua. Itu cuma mirror dari salinan pertama dengan sedikit jeda.

Ada dua solusi bersih, dan keduanya cocok dipadukan dengan hardening dasar yang seharusnya sudah Anda lakukan.

• Target append-only. Kedua tool utama mendukung mode di mana klien bisa menambah data tapi tidak bisa menghapusnya. Borg melakukannya dengan mengunci SSH key di target ke borg serve --append-only; restic melakukannya dengan REST server yang dijalankan dengan --append-only. Server production menulis setiap malam dan secara struktural tidak mampu menghancurkan riwayat. Pruning snapshot lama kemudian terjadi di sisi target, dalam sesi yang tidak bisa dimulai oleh server production.
• Pull, bukan push. Balik arahnya: host backup yang terhubung ke production, membaca, lalu menyimpan. Production sama sekali tidak menyimpan kredensial untuk target, jadi tidak ada yang bisa dicuri. Batasi kunci yang digunakan di sisi production dengan restrict dan command= yang dipaksakan, sehingga backup key yang dicuri tidak bisa berubah menjadi shell.

Pull adalah model yang lebih kuat dan sedikit lebih repot dijalankan; append-only nyaris gratis jika Anda sudah memakai Borg atau restic. Keduanya mengubah "penyerang menghapus backup saya" dari sebuah hasil akhir menjadi sekadar percobaan. Jika hanya satu hal yang Anda ambil dari panduan ini, ambillah bagian ini.

Enkripsi di sumbernya, baru putuskan siapa yang memegang kuncinya

Kedua tool serius ini mengenkripsi di mesin yang sedang di-backup, sebelum apa pun melintasi jaringan. Target hanya menyimpan blob yang tidak bisa ia baca — dan justru itulah yang membuat salinan lintas-penyedia ini aman. Host kedua Anda tidak perlu bisa dipercaya, bahkan tidak perlu ramah; ia hanya perlu bisa dijangkau dan punya disk. Satu sifat inilah yang mengubah "server di negara yang sama sekali tak saya kenal" dari sebuah risiko menjadi infrastruktur.

Ini mekanisme yang berbeda dari mengenkripsi disk server itu sendiri, dan keduanya menjawab pertanyaan yang berbeda — panduan kami tentang enkripsi disk penuh di VPS membahas apa yang dilindungi dan tidak dilindungi oleh enkripsi disk selama mesin menyala. Enkripsi backup lebih mudah dan lebih bernilai di antara keduanya, karena threat model-nya jujur: datanya diam (at rest), di perangkat keras yang tidak Anda kendalikan, dan kuncinya tidak pernah sampai ke sana.

Ini memindahkan seluruh risiko ke penjagaan kunci. Passphrase kini menjadi satu titik kegagalan total, dan ini lebih buruk dari yang dibayangkan orang, karena kehilangannya senyap — tidak ada yang rusak, backup tetap berjalan, dan Anda baru menyadarinya justru pada saat Anda paling membutuhkannya. Tiga kebiasaan berikut mengatasinya:

• Simpan passphrase di server hanya sebagai file yang hanya bisa dibaca root, dirujuk dengan --password-file, sehingga tidak pernah muncul di daftar proses atau riwayat shell.
• Simpan salinan yang bisa dibaca manusia di luar semua mesin yang terlibat. Kertas di laci sungguh-sungguh lebih unggul dibanding password manager yang sinkron ke akun yang aksesnya juga bisa Anda hilangkan.
• Tambahkan kunci kedua ke repository — restic key add, atau Borg key yang diekspor — sehingga satu passphrase yang terlupakan hanya menjadi gangguan kecil, bukan akhir dari arsip.

Aturan yang mendasari ketiganya: jika satu-satunya salinan kunci hidup di mesin yang seharusnya digantikan oleh backup itu, Anda tidak punya backup. Anda hanya punya tumpukan blok terenkripsi dan sebuah cerita tentangnya.

Memilih tool, dalam satu tabel

Pemilihan tool tidak sepenting arah koneksi dan status kunci Anda, itulah sebabnya bagian ini muncul di urutan keenam, bukan pertama. Meski begitu, perbedaannya nyata, dan memilih bentuk yang salah untuk pekerjaan ini akan menciptakan masalah di kemudian hari.

Untuk satu server, restic ke VPS kedua adalah jalur tercepat menuju sesuatu yang benar. Untuk seedbox, arsip media, atau apa pun dengan banyak file besar yang serupa, deduplikasi Borg adalah pembeda antara disk yang penuh dan disk yang lega — panduan seedbox kami membahas sisi storage dari beban kerja itu lebih detail.

Apa pun yang sedang berjalan bukanlah sebuah file

Backup rusak yang paling umum di dunia adalah salinan file langsung dari database yang sedang hidup. Prosesnya selesai tanpa error, ukurannya pas, dan saat di-restore menghasilkan tabel yang ditolak dibuka oleh engine-nya. Database sedang mid-write ketika salinan itu lewat; yang Anda simpan adalah foto dari halaman yang sedang dibalik.

Ada tiga jalan keluar, dengan usaha yang makin meningkat. Dump: mysqldump --single-transaction menghasilkan dump InnoDB yang konsisten tanpa mengunci proses penulis, dan pg_dump melakukan hal yang sama untuk PostgreSQL. Snapshot: bekukan filesystem atau ambil snapshot LVM atau ZFS, salin dari snapshot itu, lalu lepaskan — begini caranya menangani dataset yang terlalu besar untuk di-dump setiap malam. Atau hentikan: untuk layanan kecil, downtime dua menit pukul 04:00 adalah strategi konsistensi yang sangat masuk akal, dan ini satu-satunya cara tanpa edge case.

Logika yang sama berlaku di luar database. Writable layer sebuah container memang sekali pakai, tapi volume-nya tidak, begitu juga file docker compose dan environment di sampingnya — backup yang mengembalikan data tapi bukan definisinya membuat Anda harus menyusun ulang stack dari ingatan. Message queue, Redis dengan persistence aktif, dan mail spool yang sedang ditulis oleh MTA semuanya butuh perlakuan yang sama: quiesce, snapshot, atau dump, tapi jangan pernah asal-salin lalu berharap yang terbaik.

Apa yang harus di-backup, dan bagian yang selalu dilupakan semua orang

Kebanyakan orang mem-backup payload yang jelas — database dan direktori aplikasi — lalu membangun ulang sisanya secara manual di bawah tekanan. Pembangunan ulang inilah yang menghabiskan berjam-jam waktu. Backup yang mengembalikan Anda ke sistem yang berfungsi, bukan sekadar tumpukan data yang benar, mencakup lapisan yang membosankan ini:

• /etc secara utuh, plus systemd unit dan timer yang Anda tulis sendiri, dan crontab apa pun yang berada di luar itu.
• Sertifikat TLS dan private key-nya, atau minimal ACME account key, agar sertifikat diperbarui alih-alih dimulai lagi dari nol.
• Aturan firewall dan daftar paket, yang bersama-sama menyusun ulang bentuk mesin jauh lebih cepat dibanding mengandalkan ingatan.
• Secret aplikasi dan file environment — yang memang sengaja dikecualikan dari code repository Anda, dan karena itu tidak ada di tempat lain mana pun.
• Record DNS yang diekspor sebagai teks, termasuk entri reverse-DNS dan PTR, yang berada di sisi penyedia, bukan di server.

Restore yang belum pernah diuji hanyalah rumor

Software backup melaporkan dirinya sendiri, dan ia jujur soal hal yang salah. "Snapshot completed" berarti data sudah ditulis ke repository. Itu tidak mengatakan apa pun soal apakah repository itu bisa dibaca di mesin lain, oleh orang yang sudah lupa apa yang ia konfigurasikan sebelas bulan lalu.

Mulailah dengan pemeriksaan integritas yang murah — restic check --read-data-subset=5% atau borg check --verify-data secara terjadwal — dan pahami bahwa itu hanya memverifikasi arsipnya, bukan kemampuan Anda untuk memakainya. Latihan yang sesungguhnya berbeda dan hanya butuh satu sore, sekali saja. Pesan server baru per jam di lokasi yang biasanya tidak Anda pakai. Restore ke server itu hanya bermodalkan alamat repository, passphrase, dan catatan Anda sendiri. Nyalakan layanannya. Catat waktu keseluruhan prosesnya. Lalu hancurkan mesin itu. Total biaya: beberapa dolar saja, dan ini satu-satunya latihan yang menghasilkan angka yang bisa Anda percaya.

Yang selalu terungkap dari latihan ini bukanlah datanya. Melainkan paket yang hilang dan tak pernah dicatat siapa pun, config yang hidup di luar path yang di-backup, passphrase yang hanya pernah ada di riwayat shell server yang sedang Anda gantikan, dan versi tool yang bisa membaca format repository Anda. Semua itu sepele untuk diperbaiki lebih dulu dan menyiksa untuk ditemukan saat terjadi outage.

Catat dua angka yang dihasilkan latihan ini: berapa lama restore berlangsung, dan berapa banyak pekerjaan yang boleh hilang menurut jadwalnya. Itulah kebijakan backup Anda. Semua yang dibahas di atas hanyalah detail implementasi yang melayani kedua angka itu.

Mengotomatiskannya agar terus berjalan

Jalankan job dari systemd timer, bukan cron. Anda mendapat log di satu tempat, catatan nyata dari eksekusi terakhir, dan jadwal yang bertahan dari reboot — semuanya tidak diberikan cron tanpa kerja ekstra. Jauhkan passphrase dari file unit itu sendiri, karena siapa pun dengan akses shell bisa membacanya langsung lewat systemctl cat.

Lalu selesaikan mode kegagalan yang sebenarnya paling sering menjebak orang, yaitu bukan error melainkan kesunyian. Backup yang berhenti berjalan enam minggu lalu terlihat persis seperti yang berjalan sempurna, karena keduanya tidak menghasilkan output apa pun. Beri alert atas ketiadaan, bukan atas kegagalan. Buat job mengirim ping ke monitor saat berhasil, dan biarkan monitor itu yang mengeluh kalau pingnya tidak kunjung datang — dan letakkan monitor itu di mana saja kecuali di server yang diawasinya, karena mesin yang mati tidak bisa melaporkan bahwa dirinya mati.

Tetapkan retensi dengan sengaja, bukan sekadar memakai default. Sesuatu seperti --keep-daily 7 --keep-weekly 4 --keep-monthly 6 mencakup kesalahan yang Anda sadari malam ini dan korupsi yang baru Anda sadari saat musim semi, tanpa terus membesar selamanya. Jalankan pruning di sisi target jika Anda sudah menerapkan append-only, karena itulah gunanya menerapkan append-only. Volume transfer jarang jadi kendala di jaringan kami — bandwidth unmetered di setiap paket — jadi jadwalkan demi konsistensi, bukan demi kuota, dan sesuaikan waktunya dengan jam-jam sepi Anda sendiri. Kebiasaan yang lebih luas seputar semua ini dibahas di panduan OpSec server.

Versi singkatnya

Jika Anda tidak melakukan hal lain dari halaman ini, lakukan enam hal berikut, kurang lebih dalam urutan ini:

• Taruh satu salinan di penyedia kedua, di yurisdiksi kedua, dibayar dengan cara privat yang sama seperti yang pertama.
• Jadikan salinan itu append-only, atau tarik dari sisi target, sehingga server yang diretas tidak bisa menghancurkannya.
• Biarkan tool mengenkripsi di sumbernya, dan jauhkan kunci dari kedua mesin yang terlibat.
• Dump database dan hentikan atau snapshot apa pun yang sedang berjalan; jangan pernah asal-salin state yang masih hidup.
• Backup kunci identitas secara terpisah — onion, WireGuard, DKIM, node seed — karena semua itu tidak bisa dibuat ulang.
• Restore ke server sekali pakai satu kali, catat waktunya, dan tulis apa saja yang hilang.

Tidak ada satu pun dari ini yang eksotis, dan tidak ada yang butuh waktu seakhir pekan. Ini cuma satu sore untuk setup dan satu latihan, melawan kategori kehilangan yang bisa mengakhiri proyek. Di platform yang sengaja tidak menyimpan apa pun tentang Anda, salinan yang Anda buat sendiri adalah satu-satunya yang benar-benar ada — itulah harga dari kesepakatan ini, dan itu harga yang adil. Buat server kedua di yurisdiksi yang berbeda dari yang pertama, dan beri tempat mendarat untuk backup malam ini.