Strategi Backup VPS yang Praktis (Aturan 3-2-1)

Ditulis oleh tim ApexVPS • Terakhir diperbarui: Juli 2026 • 7 menit baca

Strategi backup VPS yang andal adalah perbedaan antara pemulihan lima menit dan minggu yang sangat buruk. Server gagal, disk korup, deploy salah, dan satu perintah yang salah ketik dapat menghapus direktori. Cloudflare Learning Center dan sebagian besar tim infrastruktur menunjuk pada disiplin sederhana yang sama: aturan 3-2-1. Panduan ini menunjukkan cara menerapkannya pada server virtual nyata, alat apa yang digunakan, dan cara menjadwalkan serta menguji semuanya sehingga pemulihan benar-benar berfungsi saat Anda membutuhkannya.

Apa Arti Aturan 3-2-1

Aturan 3-2-1 adalah prinsip backup berusia puluhan tahun yang tetap berlaku di mana pun server Anda berada:

• 3 salinan data Anda — salinan langsung ditambah setidaknya dua backup.
• 2 media atau sistem penyimpanan yang berbeda — sehingga satu kegagalan tidak dapat menghancurkan kedua salinan sekaligus.
• 1 salinan di luar lokasi — terpisah secara fisik atau logis dari mesin yang Anda lindungi.

Pada VPS, ini biasanya berarti server yang berjalan, repositori cadangan lokal, dan salinan terenkripsi yang dikirim ke penyimpanan jarak jauh di lokasi yang berbeda. Tujuannya adalah redundansi tanpa satu titik kegagalan bersama.

Apa yang Harus Dicadangkan di VPS

Mencadangkan seluruh disk blok demi blok itu boros dan lambat. Rencana cadangan yang baik menargetkan tiga hal yang benar-benar sulit untuk dibuat ulang.

Data aplikasi dan file

File yang diunggah, root situs web, volume kontainer, dan apa pun yang dihasilkan pengguna. Jalur umum termasuk /var/www, /srv, /home, dan direktori volume Docker Anda. Jika Anda meng-host aplikasi sendiri seperti server file atau wiki, di sinilah konten Anda yang tak tergantikan berada — lihat panduan kami tentang menjalankan VPS untuk self-hosting untuk mengetahui bagaimana direktori tersebut biasanya ditata.

Database

Jangan pernah menyalin file database langsung saat layanan berjalan — Anda bisa mendapatkan status setengah tertulis atau korup. Sebaliknya, ekspor dump yang konsisten. Untuk MySQL atau MariaDB:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

Bendera --single-transaction memberikan snapshot konsisten dari tabel InnoDB tanpa menguncinya. Untuk PostgreSQL, gunakan pg_dump sebagai gantinya:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

Konfigurasi sistem dan layanan

File yang membuat server Anda menjadi milik Anda: /etc (nginx, unit systemd, cron, konfigurasi SSH), daftar paket, sertifikat TLS, dan aturan firewall. Membangun ulang ini dari ingatan setelah kegagalan adalah pekerjaan membosankan yang seharusnya dihindari oleh cadangan.

Memilih Alat Cadangan Anda

Tiga alat mencakup hampir semua kasus VPS. Pilih berdasarkan seberapa besar Anda menghargai deduplikasi dan enkripsi.

restic — snapshot terenkripsi dan terdeduplikasi

restic adalah alat cadangan modern biner tunggal yang mengenkripsi dan mendeduplikasi secara default. Inisialisasi repositori sekali, lalu jalankan cadangan terhadapnya:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — arsip deduplikasi

BorgBackup menawarkan deduplikasi dan kompresi serupa dengan alur kerja yang sedikit berbeda:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — pencerminan file sederhana

Ketika Anda hanya perlu cermin cepat file ke host lain, rsync melalui SSH sulit dikalahkan:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

Bendera -aAX mempertahankan izin, ACL, dan atribut yang diperluas; --delete menjaga cermin tetap sinkron dengan sumber. rsync saja tidak membuat riwayat versi, itulah sebabnya banyak tim menggabungkannya dengan restic atau borg.

Otomatiskan Jadwal dengan cron

Cadangan yang harus Anda ingat untuk dijalankan adalah cadangan yang tidak akan terjadi. Masukkan langkah-langkah Anda ke dalam skrip, buat dapat dieksekusi, dan jadwalkan dengan cron. Edit crontab Anda dengan:

crontab -e

Kemudian tambahkan baris seperti ini:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

Catat outputnya, dan buat skrip keluar dengan kode non-nol saat gagal sehingga Anda dapat menghubungkannya ke fitur pemantauan dan peringatan yang disertakan dengan paket Anda. Kegagalan cadangan yang senyap lebih buruk daripada tidak ada cadangan, karena terasa aman.

Simpan Salinan Offsite yang Nyata

"1" dalam 3-2-1 adalah bagian yang paling sering dilewati orang. Cadangan yang berada di server yang sama dengan yang dilindunginya akan hilang bersama server itu. Dorong salinan terenkripsi ke tempat yang independen — penyimpanan objek, kotak SFTP jarak jauh, atau penyedia lain. restic dan borg keduanya menulis langsung ke repositori jarak jauh, misalnya melalui SFTP:

restic -r sftp:[email protected]:/backups/restic backup /var/www

Karena restic dan borg mengenkripsi sebelum data meninggalkan VPS Anda, host jarak jauh tidak akan pernah melihat teks biasa Anda. Pangkas snapshot lama dengan kebijakan agar penyimpanan tidak tumbuh selamanya:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Uji Pemulihan Anda — Setiap Waktu

Cadangan yang tidak diuji adalah desas-desus. Jadwalkan pemulihan berkala ke lokasi sementara dan konfirmasikan bahwa file dan database kembali utuh:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

Jika pemulihan berhasil dan data cocok, Anda memiliki strategi. Jika tidak, Anda baru saja belajar pada Selasa sore, bukan saat terjadi gangguan nyata.

Snapshot Hanyalah Satu Lapisan, Bukan Seluruh Strategi

Setiap paket ApexVPS mencakup pencadangan otomatis — snapshot harian pada Starter Pro dan snapshot per jam pada Business — dan itu sangat berguna untuk pengembalian cepat setelah penerapan yang buruk atau penghapusan yang tidak disengaja. Tetapi jujurlah tentang apa itu: lapisan pertama yang nyaman yang hidup di platform kami. Itu bukan pengganti salinan offsite yang diverifikasi secara independen yang disyaratkan oleh aturan 3-2-1. Perlakukan snapshot platform sebagai titik pemulihan lokal yang cepat, dan jalankan pekerjaan restic atau borg Anda sendiri untuk memenuhi bagian offsite dan pemulihan teruji dari aturan tersebut. Pendekatan berlapis itulah yang membedakan pengaturan yang penuh harapan dari yang tangguh, baik Anda meng-host aplikasi seperti Nextcloud atau menjalankan database produksi.

Daftar Periksa Strategi Cadangan VPS Anda

Menggabungkan semuanya, strategi cadangan lengkap untuk server virtual terlihat seperti ini. Kerjakan sekali, buat skrip, dan biarkan cron melanjutkannya:

• Identifikasi apa yang penting — file aplikasi, dump database, dan konfigurasi di bawah /etc.
• Pilih alat — restic atau BorgBackup untuk cadangan terenkripsi, deduplikasi, dan berversi; rsync untuk mirror sederhana.
• Dump database secara konsisten — mysqldump --single-transaction atau pg_dump, jangan pernah salinan mentah file langsung.
• Otomatiskan — jadwalkan skrip dengan cron dan beri peringatan pada keluaran non-nol apa pun.
• Dorong satu salinan offsite — terenkripsi, di penyimpanan independen, dengan kebijakan retensi yang wajar.
• Uji pemulihan secara teratur — pulihkan ke lokasi sementara dan konfirmasi data utuh.

Lakukan enam hal ini dan aturan 3-2-1 berhenti menjadi teori dan menjadi kebiasaan yang dapat diandalkan infrastruktur Anda. Satu jam pengaturan di awal sangat sepele dibandingkan biaya menemukan, di tengah insiden, bahwa satu-satunya salinan Anda ada di disk yang baru saja mati.

Pertanyaan yang Sering Diajukan

Apakah snapshot penyedia dihitung sebagai strategi cadangan?

Snapshot adalah satu lapisan yang berguna, tetapi bukan strategi lengkap. Snapshot harian dan per jam kami melindungi dari sebagian besar kesalahan jangka pendek, namun mereka hidup di platform yang sama dengan server Anda. Strategi cadangan 3-2-1 yang lengkap masih membutuhkan salinan offsite independen yang Anda kendalikan dan pemulihan yang benar-benar Anda uji.

Seberapa sering saya harus mencadangkan VPS?

Sesuaikan frekuensi dengan seberapa banyak data yang mampu Anda hilangkan. File statis dan konfigurasi dapat dicadangkan setiap hari, sementara database aktif sering kali memerlukan dump per jam. Gunakan cron untuk mengotomatiskan jadwal sehingga cadangan tidak pernah bergantung pada ingatan untuk menjalankannya.

Apa alat terbaik untuk cadangan VPS?

restic dan BorgBackup sama-sama sangat baik: mereka melakukan deduplikasi, kompresi, dan enkripsi cadangan, serta mendukung repositori offsite. rsync bagus untuk mirror file sederhana, dan mysqldump atau pg_dump menangani ekspor database. Banyak pengaturan menggabungkan dump database dengan menjalankan restic atau borg.

Bagaimana saya tahu cadangan saya benar-benar berfungsi?

Uji pemulihan secara terjadwal. Pulihkan ke direktori sementara, verifikasi isi file dan checksum, dan impor dump database ke database percobaan. Cadangan yang belum pernah Anda pulihkan hanyalah tebakan penuh harapan, bukan rencana pemulihan.