[Beranda](https://servhidden.com/id) /
[Privasi Hosting Guides](https://servhidden.com/id/guides) /
Strategi Backup VPS: Terenkripsi, Off-Site, dan Bisa Dipulihkan






Operasional


# Backup VPS yang Benar-Benar Bisa Dipulihkan



Hosting no-KYC menghapus jaring pengaman sekaligus berkas identitas Anda: tidak ada backup yang disimpan, data server dihancurkan dalam 24 jam setelah terminasi, dan tidak ada jalur dukungan yang berujung pada salinan yang dipulihkan. Inilah rencana kerjanya — apa yang harus disalin, ke mana menaruhnya, cara mencegah penyerang menghapusnya, dan cara membuktikan bahwa itu benar-benar bisa dipulihkan.


[Baca panduan](#guide-body)
[FAQ](#guide-faq)






## Di halaman ini




- [Panduan](#guide-body)

- [FAQ](#guide-faq)

- [Panduan terkait](#guide-related)

- [Halaman yang direkomendasikan](#guide-cta)






Tanpa KYC
Hanya Kripto
Tanpa Log
DMCA Diabaikan
Root penuh
NVMe SSD





19 mnt baca
Diperbarui Aug 2026

Di halaman ini

[01Apa yang benar-benar merusak server](#apa-yang-benar-benar-merusak-server)
[02Snapshot bukan backup, dan host Anda juga bukan](#snapshot-bukan-backup-dan-host-anda-juga-bukan)
[03Aturan 3-2-1, ditulis ulang untuk orang yang tak pernah menunjukkan KTP](#aturan-3-2-1-ditulis-ulang-untuk-orang-yang-tak-pernah-menun)
[04Push, pull, dan kesalahan yang membuat satu malam buruk melahap kedua salinan](#push-pull-dan-kesalahan-yang-membuat-satu-malam-buruk-melaha)
[05Enkripsi di sumbernya, baru putuskan siapa yang memegang kuncinya](#enkripsi-di-sumbernya-baru-putuskan-siapa-yang-memegang-kunc)
[06Memilih tool, dalam satu tabel](#memilih-tool-dalam-satu-tabel)
[07Apa pun yang sedang berjalan bukanlah sebuah file](#apa-pun-yang-sedang-berjalan-bukanlah-sebuah-file)
[08Apa yang harus di-backup, dan bagian yang selalu dilupakan semua orang](#apa-yang-harus-di-backup-dan-bagian-yang-selalu-dilupakan-se)
[09Restore yang belum pernah diuji hanyalah rumor](#restore-yang-belum-pernah-diuji-hanyalah-rumor)
[10Mengotomatiskannya agar terus berjalan](#mengotomatiskannya-agar-terus-berjalan)
[11Versi singkatnya](#versi-singkatnya)
[FAQPertanyaan umum](#guide-faq)
[→Halaman yang direkomendasikan](#guide-cta)







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](https://servhidden.com/id/privacy) 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.

| Apa yang salah | Bagaimana biasanya terjadi | Apa yang bisa menyelamatkan Anda |
| --- | --- | --- |
| **Tangan Anda sendiri** | rm -rf saat variabel shell kosong, migrasi yang mengarah ke production, deployment yang menghapus tabel yang salah | Salinan off-box mana pun dari *sebelum* kesalahan terjadi — artinya retensi harus menjangkau lebih jauh ke belakang daripada waktu yang Anda butuhkan untuk menyadarinya |
| **Korupsi diam-diam** | NVMe yang sekarat, penulisan yang terpotong saat reboot, database yang sudah menulis baris rusak selama seminggu | Salinan berversi yang cukup dalam untuk mencapai titik yang diketahui baik. Satu salinan mirror hanya akan mencerminkan kerusakan itu dengan setia |
| **Peretasan** | Kunci yang dicuri, aplikasi yang tidak ditambal, dependency yang diracuni — lalu, dengan sengaja, backup Anda | Salinan yang tidak bisa dihapus oleh mesin yang sudah diretas. Tidak ada yang lain yang berlaku di sini |
| **Insiden penyedia atau negara** | Kehilangan perangkat keras, tindakan hukum di datacenter, akun atau token yang tak bisa lagi Anda akses | Salinan yang tidak berada di penyedia itu dan tidak berada di bawah yurisdiksi itu |
| **Kehilangan kunci** | Passphrase yang terlupakan, keyfile yang terhapus bersama server yang dilindunginya, header LUKS yang tak pernah diekspor siapa pun | **Tidak ada.** Ini satu-satunya baris tanpa kolom pemulihan, dan ini lebih sering terjadi daripada kegagalan perangkat keras |

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.

Target backup butuh disk dan sebuah alamat, bukan core. Mesin kedua termurah di yurisdiksi berbeda adalah endpoint yang mumpuni — dan satu-satunya salinan yang bertahan dari insiden di penyedia pertama.

## 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.

**Klausul 24 jam adalah keseluruhan argumennya.** Di platform ini, data server yang diterminasi dihancurkan dalam waktu sehari, dan disk dihapus secara kriptografis alih-alih diformat. Tidak ada undelete, tidak ada tingkat cold-storage tersembunyi, tidak ada hasil dukungan yang berakhir dengan "kami menemukan salinan lama" — karena menyimpannya berarti tetap menahan data Anda setelah Anda memintanya dihapus. Jaring pengaman dan privasi adalah pertukaran yang sama, dibuat sekali untuk selamanya.

## 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](https://servhidden.com/id/guides/choosing-an-offshore-jurisdiction) 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](https://servhidden.com/id/vps) terkecil di salah satu dari [tujuh lokasi](https://servhidden.com/id/locations) kami sudah menjadi endpoint restic atau Borg yang mumpuni, dan untuk arsip berukuran terabyte, [server dedicated](https://servhidden.com/id/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](https://servhidden.com/id/guides/how-to-pay-for-hosting-with-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](https://servhidden.com/id/guides/first-hour-vps-hardening-checklist) 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](https://servhidden.com/id/guides/full-disk-encryption-on-a-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.

| Tool | Mengenkripsi sebelum keluar | Deduplikasi | Target append-only | Cocok untuk |
| --- | --- | --- | --- | --- |
| **restic** | Ya, seluruh repository | Ya | Ya, lewat REST server-nya | Pilihan default. Mendukung SFTP, object storage, dan server-nya sendiri, jadi targetnya bisa hampir apa saja |
| **BorgBackup** | Ya, seluruh repository | Ya, terbaik di kelompoknya | Ya, native lewat SSH | Satu target Linux yang diakses lewat SSH. Tak tertandingi saat data besar dan repetitif |
| **rsync dengan rotasi** | Tidak — target melihat semuanya | Sebagian, lewat hardlink | Tidak | Mirroring ke mesin yang sepenuhnya Anda kendalikan, saat restore parsial instan lebih penting daripada privasi |
| **rclone** | Hanya dengan rclone crypt | Tidak | Tergantung penyedia storage | Memindahkan arsip yang sudah ada ke object storage, atau antar-penyedia |
| **Replikasi ZFS** | Hanya dengan dataset terenkripsi | Ya, level blok | Lewat izin snapshot | Replikasi antara dua mesin ZFS. Sangat cepat, sangat kaku soal kedua sisinya |
| **tar dengan age atau GPG** | Ya, jika Anda mengenkripsi arsipnya | Tidak | Tidak berlaku | Arsip kecil, sesekali, disimpan selamanya, di mana kesederhanaan mengalahkan efisiensi |

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](https://servhidden.com/id/guides/seedbox-setup-guide) 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.

**Sebagian kunci bukan data — kunci itu adalah identitas.** Private key layanan onion Tor *adalah* alamatnya: kehilangannya berarti situs tidak bisa kembali ke [nama .onion](https://servhidden.com/id/guides/how-to-host-a-tor-hidden-service) yang sama, apa pun lagi yang berhasil Anda restore. Server key WireGuard berarti menerbitkan ulang setiap konfigurasi klien yang pernah Anda bagikan. DKIM key server mail berarti selector baru dan awal yang baru untuk [deliverability](https://servhidden.com/id/guides/offshore-mail-server-setup). Seed dan channel state node Lightning bisa berarti dana, bukan sekadar file — [panduan hosting node](https://servhidden.com/id/guides/crypto-node-hosting-guide) kami tegas soal itu. Salin semua ini secara terpisah, simpan offline, dan perlakukan sebagai lebih berharga dibanding data yang dilindunginya.

## 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](https://servhidden.com/id/guides/server-opsec-staying-anonymous).

## 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](https://servhidden.com/id/vps) di yurisdiksi yang berbeda dari yang pertama, dan beri tempat mendarat untuk backup malam ini.





FAQ

## Backup VPS — pertanyaan yang sering diajukan





### 01
Apakah ServHidden mem-backup VPS saya?



Tidak, dan itu memang disengaja, bukan kelalaian. Kebijakan retensi kami menyatakan bahwa tidak ada backup yang disimpan, data server dihancurkan dalam 24 jam setelah terminasi, dan disk dihapus secara kriptografis alih-alih diformat. Menyimpan salinan data Anda setelah Anda meminta kami menghapusnya akan bertentangan dengan alasan platform ini ada. Segala sesuatu yang ingin Anda selamatkan dari server harus Anda salin sendiri keluar dari sana, idealnya ke penyedia kedua di yurisdiksi kedua.





### 02
Apakah snapshot sama dengan backup?



Tidak. Snapshot berbagi setiap failure domain dengan server asalnya — penyedia yang sama, akun yang sama, negara yang sama, sering kali storage yang sama. Snapshot sangat baik untuk membatalkan upgrade yang gagal, tapi tidak berguna melawan hilangnya akun, penyedia, atau mesin itu sendiri. Anggap snapshot sebagai tombol undo dan backup sebagai asuransi; keduanya menyelesaikan masalah yang berbeda dan Anda butuh keduanya.





### 03
restic atau BorgBackup — mana yang sebaiknya saya pakai?



Pakai restic jika targetnya mungkin object storage, SFTP, atau sesuatu yang belum Anda pilih, karena ia mendukung paling banyak back end. Pakai BorgBackup jika targetnya satu mesin Linux yang diakses lewat SSH dan datanya besar serta repetitif, karena deduplikasinya paling kuat di antara semua tool. Keduanya mengenkripsi di sumber sebelum apa pun meninggalkan mesin, dan keduanya mendukung target append-only, yang jauh lebih penting daripada pilihan di antara keduanya.





### 04
Bagaimana cara mencegah penyerang menghapus backup saya?



Hilangkan kemampuannya, bukan cuma motifnya. Buat targetnya append-only, sehingga kredensial di server production bisa menambah data tapi tidak pernah bisa menghapusnya, atau balik arah koneksinya sehingga host backup yang menarik data dari production, dan server production sama sekali tidak menyimpan kredensial. Menghapus backup korban sebelum mengumumkan diri adalah praktik standar bagi siapa pun yang melakukan ini secara komersial, dan salinan yang bisa dihapus penyerang bukanlah salinan kedua.





### 05
Di mana sebaiknya salinan kedua disimpan?



Di penyedia yang berbeda, di yurisdiksi yang berbeda, dan dibayar seprivat server production Anda. Kegagalan yang melenyapkan kedua salinan sekaligus jarang bersifat fisik — biasanya akun yang aksesnya hilang, penyedia yang sedang mengalami minggu buruk, atau instrumen hukum yang menjangkau satu negara tapi tidak negara lain. Dua server dalam rak yang sama hanyalah satu salinan dengan langkah tambahan. Karena tool-nya mengenkripsi di sumber, host kedua itu tidak perlu Anda percayai.





### 06
Seberapa sering saya harus backup?



Hitung mundur dari seberapa banyak pekerjaan yang rela Anda ulangi. Sebuah blog bisa kehilangan satu hari tanpa ada yang sadar; sebuah toko tidak boleh kehilangan satu jam pesanan. Setiap malam adalah default yang tepat untuk kebanyakan setup satu server, dengan dump database lebih sering jika penulisan datanya berharga. Yang lebih penting daripada frekuensi adalah kedalaman retensi: korupsi sering baru disadari berminggu-minggu kemudian, jadi simpan cukup riwayat untuk mencapai titik sebelum korupsi itu dimulai.





### 07
Apakah backup terenkripsi aman di server yang tidak saya kendalikan?



Untuk isinya, ya — restic dan Borg mengenkripsi sebelum data meninggalkan sumber, jadi target hanya menyimpan blob yang tidak bisa ia baca dan kuncinya tidak pernah ikut berpindah. Yang diketahui target adalah metadata: kira-kira berapa banyak data yang Anda simpan, bagaimana perubahannya, dan kapan job Anda berjalan. Biasanya itu bisa diterima. Jika tidak, ubah-ubah jadwalnya dan simpan repository di mesin yang kepemilikannya tidak terhubung dengan mesin production.





### 08
Apa yang terjadi jika saya kehilangan passphrase backup?



Arsipnya hilang, permanen, tanpa ada yang bisa dilakukan siapa pun. Ini kehilangan total paling umum di seluruh topik ini dan satu-satunya kegagalan tanpa jalur pemulihan. Simpan passphrase di luar semua mesin yang terlibat, lebih baik di atas kertas daripada di akun yang aksesnya juga bisa Anda hilangkan, dan tambahkan kunci kedua ke repository sehingga satu password yang terlupakan hanya jadi gangguan kecil, bukan akhir dari arsip.




Panduan terkait

## Terus membaca


[### Cara Memilih Yurisdiksi Hosting Offshore pada 2026

Pembelian


Kerangka keputusan praktis untuk memilih yurisdiksi offshore: undang-undang retensi data, paparan MLAT, posisi DMCA, kecepatan pengadilan, dan penegakan di dunia nyata — negara demi negara.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/choosing-an-offshore-jurisdiction)
[### VPS vs Server Dedicated for Privasi-Critical Workloads

Pembelian


Kapan VPS sudah cukup, kapan shared tenancy menjadi liabilitas, dan kapan bare metal adalah satu-satunya jawaban yang jujur. Isolasi hardware, risiko hypervisor, serta biaya dibanding model ancaman.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/vps-vs-dedicated-for-privacy)
[### VPN Self-Hosted di VPS Tanpa-KYC: WireGuard vs OpenVPN

Operasional


Mengapa VPN self-hosted mengalahkan provider komersial, dan bagaimana WireGuard serta OpenVPN benar-benar dibandingkan dari sisi privasi, performa, dan risiko operasional pada 2026.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 untuk Inferensi AI (dan Di Mana RTX 5090 Cocok)

Pembelian


Buying-decision guide: NVIDIA GPU mana untuk self-hosted LLM, image, video, voice, dan finetuning workloads pada 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token, dan kapan masing-masing menang.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/rtx-4090-vs-h100-for-ai-inference)
[### Windows RDP Offshore untuk Trading Forex MT4 / MT5 / cTrader

Operasional


Panduan lengkap: mengapa Windows RDP untuk trading forex, cara memilih yurisdiksi offshore berlatensi rendah, pengaturan MT4 / MT5 / cTrader / Expert Advisor, latensi ke server broker, dan jalur checkout no-KYC.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/offshore-windows-rdp-for-forex-trading)
[### Hosting DMCA-Ignored Dijelaskan: Apa Artinya Sebenarnya di 2026

Pembelian


Apa yang benar-benar didapat dari hosting "DMCA ignored", yurisdiksi mana yang sungguh-sungguh mendukungnya, beban kerja yang membutuhkannya, dan jebakan hak cipta yang tidak dicakup oleh istilah tersebut.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/dmca-ignored-hosting-explained)
[### Registrasi Domain Anonim dengan Kripto: Privasi WHOIS di 2026

Privasi


Panduan praktis 2026 untuk mendaftarkan domain tanpa mengungkap identitas Anda: rezim WHOIS per TLD, pilihan registrar, opsi pembayaran kripto, dan kesalahan operasional yang tetap membocorkan Anda.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/anonymous-domain-registration-with-crypto)
[### Kripto Payments for Hosting: Monero vs Bitcoin vs USDT

Privasi


Bagaimana coin pembayaran memengaruhi apa yang diketahui host tentang Anda. Privasi, biaya, finalitas, dan eksposur chain analysis untuk XMR, BTC, dan USDT, dengan rekomendasi jelas.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### Apakah Hosting Offshore Benar-Benar Anonim? Jawaban yang Jujur

Privasi


Hosting offshore tanpa KYC menghilangkan identitas yang biasanya dikumpulkan oleh hosting normal — tetapi status "anonim" bergantung pada metode pembayaran, logging provider, dan opsec Anda sendiri. Berikut ini yang sebenarnya masih bisa dilacak.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/is-offshore-hosting-truly-anonymous)
[### Jam Pertama Hardening VPS: Sebuah Checklist

Operasional


Checklist konkret dan berurutan untuk mengamankan VPS baru dalam waktu kurang dari satu jam: kunci SSH, firewall, fail2ban, update otomatis, dan pengurangan attack surface yang menghentikan sebagian besar serangan oportunistik.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/first-hour-vps-hardening-checklist)
[### Apa Itu Hosting Tanpa KYC? Definisi, Legalitas & Cara Kerjanya

Privasi


Hosting tanpa KYC memungkinkan Anda menyewa server tanpa verifikasi identitas apa pun — tanpa nama, email, maupun ID. Berikut penjelasan lengkapnya: apa artinya, cara kerjanya secara teknis, apakah legal, dan cara memilih penyedia yang benar-benar tanpa KYC.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/what-is-no-kyc-hosting)
[### Apakah Hosting Offshore Legal? Jawaban Jujur untuk 2026

Pembelian


Hosting offshore itu legal — baik untuk Anda maupun untuk penyedia layanan. Berikut penjelasan sesungguhnya tentang istilah ini, di mana garis hukum yang sebenarnya, mitos yang perlu dibuang, dan cara menggunakannya secara bertanggung jawab.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/is-offshore-hosting-legal)
[### Cara Membayar Hosting dengan Monero (XMR) — Panduan Langkah demi Langkah

Privasi


Panduan langkah demi langkah untuk membayar VPS atau server dedicated dengan Monero (XMR): mengapa XMR adalah pilihan paling privat, cara memperolehnya, dan cara kerja proses checkout — dari invoice hingga server yang berjalan dalam hitungan menit.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/how-to-pay-for-hosting-with-monero)
[### Cara Meng-host Website Secara Anonim — Panduan Praktis 2026

Privasi


Panduan berlapis yang praktis untuk meng-host website tanpa identitas yang terlampir: akun, pembayaran, domain, yurisdiksi, koneksi, dan konten — setiap lapisan dijelaskan secara rinci.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/how-to-host-a-website-anonymously)
[### Cara Menyiapkan WireGuard VPN di VPS — Panduan Langkah demi Langkah

Operasional


Bangun VPN pribadi di VPS menggunakan WireGuard: mengapa VPN yang di-host sendiri lebih unggul dari layanan komersial, panduan lengkap mulai dari instalasi hingga klien terhubung, dan cara memperkuat keamanannya.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### Cara Self-Host LLM di Server GPU — Panduan 2026

Operasional


Jalankan model bahasa besar milik Anda sendiri di server GPU sewaan: mengapa self-hosting lebih unggul dari API, cara memilih GPU dan model yang tepat, cara setup dengan Ollama atau vLLM, dan berapa biayanya.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof Hosting vs Offshore Hosting — Apa Perbedaannya?

Pembelian


Bulletproof hosting dan offshore hosting kerap tertukar — padahal keduanya tidak sama. Berikut perbedaan sesungguhnya, mengapa hal ini penting, dan mana yang sebenarnya Anda butuhkan.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/bulletproof-vs-offshore-hosting)
[### Cara Membeli VPS dengan Bitcoin — Panduan Lengkah demi Langkah (2026)

Pembelian


Panduan ramah pemula untuk membeli VPS dengan Bitcoin: mendapatkan BTC, memilih paket, membayar invoice, dan apa yang Anda peroleh — server yang berjalan tanpa kartu dan tanpa nama terlampir.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/how-to-buy-a-vps-with-bitcoin)
[### Negara Terbaik untuk Hosting yang Mengabaikan DMCA di 2026

Pembelian


Tempat menghosting konten agar jauh dari jangkauan proses penghapusan ala AS: yurisdiksi yang benar-benar efektif, apa arti sebenarnya hosting yang mengabaikan DMCA, dan cara memilihnya.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/best-countries-for-dmca-ignored-hosting)
[### Cara Meng-host Tor Hidden Service (Situs .onion) — Panduan 2026

Operasional


Siapkan onion service Tor di VPS: apa itu hidden service, mengapa ini adalah bentuk hosting anonim yang paling kuat, panduan setup lengkap, dan cara menjaganya tetap benar-benar anonim.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/how-to-host-a-tor-hidden-service)
[### Panduan Setup Mail Server Offshore — Self-Host Email Privat di 2026

Operasional


Jalankan server email privat Anda sendiri di VPS offshore: mengapa self-host email, apa yang dibutuhkan, setup realistis dengan stack mail all-in-one, dan cara memastikan deliverability yang tepat.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/offshore-mail-server-setup)
[### Panduan Hosting Node Kripto — Jalankan Node Blockchain di VPS

Operasional


Cara meng-host node blockchain di server: mengapa menjalankan node sendiri, menentukan spesifikasi server untuk Bitcoin, Ethereum, Monero dan lainnya, proses setup, dan cara menjaga privasi.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/crypto-node-hosting-guide)
[### Hosting GPU untuk Stable Diffusion — Jalankan Server Gambar Sendiri

Operasional


Jalankan Stable Diffusion di server GPU Anda sendiri: alasan self-hosting pembuatan gambar, cara memilih GPU, pengaturan dengan web UI, serta perbandingan biaya versus layanan hosted.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/gpu-hosting-for-stable-diffusion)
[### OpSec Server — Tetap Anonim Saat Menjalankan Server

Privasi


Keamanan operasional bagi siapa saja yang menjalankan server anonim: kesalahan-kesalahan yang membongkar identitas, kebiasaan yang mencegahnya, dan cara menjaga identitas tetap benar-benar terpisah.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/server-opsec-staying-anonymous)
[### Panduan Penyiapan Seedbox — Bangun Seedbox Privat Anda Sendiri di 2026

Operasional


Cara membangun seedbox Anda sendiri di server: apa itu seedbox, cara menentukannya, menginstal klien torrent dengan web UI, dan menjaganya tetap privat dan aman.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/seedbox-setup-guide)
[### Cara Melewati Sensor DPI dengan VPS Anda Sendiri (Panduan 2026)

Privasi


VPN Anda berhenti berfungsi? Cara melewati sensor DPI dengan VPS Anda sendiri: apa yang sebenarnya dideteksi oleh deep packet inspection, dari lima protokol 2026 mana yang mengalahkan pemblokiran mana, dan panduan lengkap VLESS+REALITY.


FAQ 6-pertanyaan](https://servhidden.com/id/guides/bypass-dpi-censorship-with-your-own-vps)
[### Enkripsi Disk Penuh di VPS: Setup LUKS dan Perlindungan Sebenarnya

Operasional


Cara mengenkripsi VPS dengan LUKS: volume data terenkripsi, full-root dengan remote unlock lewat SSH, pengaturan penting di server kecil, dan penjelasan jujur soal apa yang dicegah enkripsi disk.


FAQ 8-pertanyaan](https://servhidden.com/id/guides/full-disk-encryption-on-a-vps)
[### Menyembunyikan IP Origin Server: CDN, Reverse Proxy, dan Kebocorannya

Privasi


Apakah perlu memasang CDN di depan server offshore: apa yang disembunyikannya, meja aduan yang Anda warisi, enam cara IP origin tetap bocor, dan cara mengauditnya sendiri.


FAQ 8-pertanyaan](https://servhidden.com/id/guides/hiding-your-origin-server-ip)
[### Self-Hosting Server Matrix Sendiri: Synapse, Federation, E2EE

Operasional


Yang sungguh Anda dapatkan dari homeserver Matrix: Synapse vs Conduit, server_name yang tak bisa diubah, media pemenuh disk, dan yang tetap terlihat oleh federation.


FAQ 8-pertanyaan](https://servhidden.com/id/guides/self-host-a-matrix-server)
[### Cara Migrasi Website ke Hosting Offshore Tanpa Downtime

Operasional


Urutan yang membuat migrasi hosting jadi membosankan: turunkan DNS TTL beberapa hari sebelumnya, jalankan kedua server secara paralel, bekukan penulisan data hanya beberapa menit, bukan berjam-jam — lalu bersihkan jejak passive-DNS, Certificate Transparency, dan WHOIS yang ditinggalkan proses pindah ini.


FAQ 8-pertanyaan](https://servhidden.com/id/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Operasional


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


FAQ 8-pertanyaan](https://servhidden.com/id/guides/self-host-a-crypto-payment-gateway)




## Beri tempat mendarat untuk backup malam ini



Tujuh yurisdiksi, bandwidth unmetered di setiap paket, dan server mulai $7.50/bulan yang jadi endpoint restic atau Borg yang mumpuni. Tanpa KYC, tanpa email, crypto only — untuk target backup sama seperti untuk production.


[Lihat Paket VPS](https://servhidden.com/id/vps)
[Server Dedicated](https://servhidden.com/id/dedicated)
[All Lokasi](https://servhidden.com/id/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "VPS offshore dan server dedicated di 7 yurisdiksi offshore. Tanpa KYC, tanpa log, hanya kripto. Privasi sejak arsitektur.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Strategi Backup VPS: Terenkripsi, Off-Site, dan Bisa Dipulihkan",
    "description": "Host Anda tidak menyimpan backup. Apa yang benar-benar merusak server, kenapa backup push ikut mati, restic vs Borg, kunci yang sering dilupakan, dan cara menguji restore.",
    "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-20T00:00:00+00:00",
    "dateModified": "2026-08-20T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy",
    "inLanguage": "id",
    "keywords": "backup VPS, backup VPS terenkripsi, restic vs BorgBackup, backup off-site VPS, aturan backup 3-2-1, backup append-only, backup server no-KYC, cara test restore VPS",
    "articleSection": "Operasional",
    "wordCount": 3784
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "Apakah ServHidden mem-backup VPS saya?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Tidak, dan itu memang disengaja, bukan kelalaian. Kebijakan retensi kami menyatakan bahwa tidak ada backup yang disimpan, data server dihancurkan dalam 24 jam setelah terminasi, dan disk dihapus secara kriptografis alih-alih diformat. Menyimpan salinan data Anda setelah Anda meminta kami menghapusnya akan bertentangan dengan alasan platform ini ada. Segala sesuatu yang ingin Anda selamatkan dari server harus Anda salin sendiri keluar dari sana, idealnya ke penyedia kedua di yurisdiksi kedua."
            }
        },
        {
            "@type": "Question",
            "name": "Apakah snapshot sama dengan backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Tidak. Snapshot berbagi setiap failure domain dengan server asalnya — penyedia yang sama, akun yang sama, negara yang sama, sering kali storage yang sama. Snapshot sangat baik untuk membatalkan upgrade yang gagal, tapi tidak berguna melawan hilangnya akun, penyedia, atau mesin itu sendiri. Anggap snapshot sebagai tombol undo dan backup sebagai asuransi; keduanya menyelesaikan masalah yang berbeda dan Anda butuh keduanya."
            }
        },
        {
            "@type": "Question",
            "name": "restic atau BorgBackup — mana yang sebaiknya saya pakai?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Pakai restic jika targetnya mungkin object storage, SFTP, atau sesuatu yang belum Anda pilih, karena ia mendukung paling banyak back end. Pakai BorgBackup jika targetnya satu mesin Linux yang diakses lewat SSH dan datanya besar serta repetitif, karena deduplikasinya paling kuat di antara semua tool. Keduanya mengenkripsi di sumber sebelum apa pun meninggalkan mesin, dan keduanya mendukung target append-only, yang jauh lebih penting daripada pilihan di antara keduanya."
            }
        },
        {
            "@type": "Question",
            "name": "Bagaimana cara mencegah penyerang menghapus backup saya?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Hilangkan kemampuannya, bukan cuma motifnya. Buat targetnya append-only, sehingga kredensial di server production bisa menambah data tapi tidak pernah bisa menghapusnya, atau balik arah koneksinya sehingga host backup yang menarik data dari production, dan server production sama sekali tidak menyimpan kredensial. Menghapus backup korban sebelum mengumumkan diri adalah praktik standar bagi siapa pun yang melakukan ini secara komersial, dan salinan yang bisa dihapus penyerang bukanlah salinan kedua."
            }
        },
        {
            "@type": "Question",
            "name": "Di mana sebaiknya salinan kedua disimpan?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Di penyedia yang berbeda, di yurisdiksi yang berbeda, dan dibayar seprivat server production Anda. Kegagalan yang melenyapkan kedua salinan sekaligus jarang bersifat fisik — biasanya akun yang aksesnya hilang, penyedia yang sedang mengalami minggu buruk, atau instrumen hukum yang menjangkau satu negara tapi tidak negara lain. Dua server dalam rak yang sama hanyalah satu salinan dengan langkah tambahan. Karena tool-nya mengenkripsi di sumber, host kedua itu tidak perlu Anda percayai."
            }
        },
        {
            "@type": "Question",
            "name": "Seberapa sering saya harus backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Hitung mundur dari seberapa banyak pekerjaan yang rela Anda ulangi. Sebuah blog bisa kehilangan satu hari tanpa ada yang sadar; sebuah toko tidak boleh kehilangan satu jam pesanan. Setiap malam adalah default yang tepat untuk kebanyakan setup satu server, dengan dump database lebih sering jika penulisan datanya berharga. Yang lebih penting daripada frekuensi adalah kedalaman retensi: korupsi sering baru disadari berminggu-minggu kemudian, jadi simpan cukup riwayat untuk mencapai titik sebelum korupsi itu dimulai."
            }
        },
        {
            "@type": "Question",
            "name": "Apakah backup terenkripsi aman di server yang tidak saya kendalikan?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Untuk isinya, ya — restic dan Borg mengenkripsi sebelum data meninggalkan sumber, jadi target hanya menyimpan blob yang tidak bisa ia baca dan kuncinya tidak pernah ikut berpindah. Yang diketahui target adalah metadata: kira-kira berapa banyak data yang Anda simpan, bagaimana perubahannya, dan kapan job Anda berjalan. Biasanya itu bisa diterima. Jika tidak, ubah-ubah jadwalnya dan simpan repository di mesin yang kepemilikannya tidak terhubung dengan mesin production."
            }
        },
        {
            "@type": "Question",
            "name": "Apa yang terjadi jika saya kehilangan passphrase backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Arsipnya hilang, permanen, tanpa ada yang bisa dilakukan siapa pun. Ini kehilangan total paling umum di seluruh topik ini dan satu-satunya kegagalan tanpa jalur pemulihan. Simpan passphrase di luar semua mesin yang terlibat, lebih baik di atas kertas daripada di akun yang aksesnya juga bisa Anda hilangkan, dan tambahkan kunci kedua ke repository sehingga satu password yang terlupakan hanya jadi gangguan kecil, bukan akhir dari arsip."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Beranda",
            "item": "https://servhidden.com/id/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Privasi Hosting Guides",
            "item": "https://servhidden.com/id/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Strategi Backup VPS: Terenkripsi, Off-Site, dan Bisa Dipulihkan",
            "item": "https://servhidden.com/id/guides/vps-backup-strategy"
        }
    ]
}
```