SSD Nodes Learn 🎉 VPS mulai $5.50/bln
Panduan Matt ConnorOleh Matt Connor

Cara Menjadikan VPS Target Backup Off-Site

Snapshot provider bukan backup off-site. Simpan salinan di VPS berbeda dengan Proxmox Backup Server atau restic, lalu hitung biaya retensi sebelum memilih.

Target backup off-site sebenarnya

Target backup off-site adalah mesin kedua yang menyimpan salinan data Anda dan mengalami kegagalan secara independen dari mesin asli. VPS pada provider lain merupakan pilihan termurah yang dapat digunakan sebagian besar pembaca. Ada tiga bentuk yang realistis: Proxmox Backup Server yang berjalan pada VPS, repositori restic yang diakses melalui SSH atau S3, atau mirror rsync yang ditarik oleh host backup. Pilihan yang sesuai bergantung pada data yang perlu Anda pulihkan dan seberapa cepat data tersebut harus tersedia kembali. Siapa yang diizinkan menghapus salinan tersebut akan menentukan pilihan lainnya.

Off-site berarti domain kegagalan yang berbeda. Artinya, gunakan provider yang berbeda dan akun yang tidak menggunakan kredensial login yang sama dengan akun untuk menjalankan server Anda. Server kedua di region lain pada provider yang sama dapat bertahan jika terjadi kebakaran di satu gedung. Namun, server tersebut tidak akan bertahan jika login ke control panel disusupi, karena satu akun mengendalikan kedua salinan.

Snapshot pada provider Anda bukan salinan kedua tersebut. Snapshot berada di balik password control panel yang sama. Jadi, siapa pun yang memperoleh password itu dapat menghapus server dan snapshot-nya dalam satu sesi. Layanan snapshot juga mengenakan biaya per gigabyte per bulan dengan tarif yang jauh lebih tinggi daripada disk biasa, sehingga penggunaan selama ninety days menjadi mahal. Perbedaan antara snapshot VPS dan backup layak dibaca sebelum Anda mengandalkan salah satunya.

Bentuk mana yang sesuai untuk Anda

  • Proxmox Backup Server (PBS): sumbernya adalah Proxmox VE (virtual environment), dan yang dipulihkan adalah seluruh virtual machine. Sistem ini mencadangkan pada tingkat disk image, dan tugas verifikasinya membaca ulang data yang tersimpan di target.
  • Repository restic: sumbernya adalah satu atau beberapa host Linux, dan yang dipulihkan adalah direktori atau dump database. Sistem ini mengenkripsi data di sisi client, serta mendukung SSH dan S3, selain protokol REST bawaannya.
  • rsync over SSH, ditarik oleh backup host: Anda ingin file di target tetap berupa file biasa, yang dapat dibaca dengan ls dan cat, tanpa memerlukan software client untuk memulihkannya.

Jika Anda tidak dapat menentukan pilihan, gunakan restic. restic mengenkripsi data sebelum meninggalkan mesin, dan pada target hanya memerlukan akun SSH serta disk. Menyiapkan backup restic di VPS membahas sisi client secara lebih mendalam, sedangkan restic dan BorgBackup berdampingan membahas pilihan tersebut jika Anda sudah menjalankan Borg.

Ukuran target: biaya penyimpanan satu bulan

Deduplicasi membuat angka ini lebih kecil daripada perkiraan umum. restic dan PBS sama-sama membagi file menjadi chunk berukuran variabel, lalu melakukan hashing pada setiap chunk. Setiap chunk unik hanya disimpan satu kali. Backup kedua untuk dataset berukuran 500 GB tidak menambah 500 GB lagi. Backup tersebut hanya menambahkan chunk yang berubah.

Jadi, ukuran repository mengikuti usia snapshot tertua, bukan jumlah snapshot. Misalkan terdapat data sebesar 500 GB dan data unik baru sebesar 5 GB per hari. Repository kemudian menyimpan data dasar sebesar 500 GB, ditambah sekitar 5 GB untuk setiap hari hingga snapshot tertua yang masih dipertahankan oleh kebijakan.

ChartRepository size for 500 GB of data at 5 GB of new unique data per day
The data behind this chart
[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

Kolom dolar menghitung harga repository tersebut dengan tarif 10 US dollars per TB per month. Nilai ini hanya digunakan sebagai placeholder untuk perhitungan, bukan penawaran dari provider mana pun. Ganti dengan harga nyata per TB dari paket yang Anda pertimbangkan. Penyimpanan backup harian selama satu minggu berjumlah sekitar 535 GB. Riwayat lengkap selama satu tahun berjumlah 2,325 GB, dengan biaya $23.25 per bulan dibandingkan dengan $5.35 untuk satu minggu. Riwayat backup biayanya rendah. Salinan dasar adalah komponen yang paling banyak Anda bayar.

Deduplicasi tidak membantu data yang sejak awal sudah dikompresi atau dienkripsi. Dump database dalam format gzip berubah sepenuhnya pada setiap proses, sehingga setiap dump disimpan sebagai chunk baru dan repository bertambah sebesar satu dump penuh setiap malam. Tulis dump dalam format tidak terkompresi dan biarkan tool backup yang melakukan kompresi. restic telah mendukung repository terkompresi sejak 0.14, dan versi 0.19 menambahkan mode zstd fastest dan better. Library foto dan video juga memiliki tingkat deduplikasi yang rendah karena alasan yang sama. Karena itu, hitung ukurannya berdasarkan laju pertumbuhan aktual, bukan berdasarkan baris di atas.

Dalam kasus ini, yang Anda beli adalah disk yang menganggur, bukan CPU. Ini adalah kondisi yang tepat ketika storage VPS lebih unggul daripada VPS biasa.

Mengapa bandwidth dan waktu pemulihan menentukan rencana

Disk adalah bagian yang murah. Unggahan pertama dan pemulihan nantinya adalah bagian yang mahal. 500 GB setara dengan 4 triliun bit, sehingga pembagian dengan kecepatan koneksi memberikan batas minimum waktu yang diperlukan untuk pemulihan penuh.

ChartElapsed hours to pull 500 GB back, at line rate
The data behind this chart
[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

Angka tersebut menggunakan kecepatan jalur tanpa overhead protokol, jadi anggap sebagai kondisi terbaik. Pada 100 Mbit/s, pemulihan penuh memerlukan 11.1 jam sebelum data dapat digunakan. Dengan kecepatan unggah dari koneksi rumah sebesar 40 Mbit/s, proses tersebut memerlukan 27.8 jam. Pada port 1 Gbit/s, pemulihan yang sama memerlukan 1.1 jam. Banyak file kecil dapat membuat proses berjalan lebih lambat daripada hasil perhitungan, karena overhead per file menjadi faktor dominan saat ukuran file kurang dari beberapa ratus kilobyte.

Ada dua konsekuensi. Jika sasaran waktu pemulihan (RTO), yaitu durasi gangguan yang dapat Anda toleransi, adalah empat jam, pemulihan 500 GB melalui koneksi 100 Mbit/s sudah melampaui batas tersebut, dan disk yang lebih murah tidak membantu. Selain itu, sebagian besar paket VPS membatasi transfer keluar, sehingga satu kali pemulihan penuh menggunakan 0.5 TB dari kuota bulanan host backup. Periksa kuota tersebut dan periksa tindakan provider saat kuota terlampaui sebelum Anda memerlukan data tersebut.

Backup pertama mencakup seluruh dataset dan merupakan proses paling lambat yang akan Anda jalankan. Mulai pada hari Jumat dan batasi kecepatannya agar tidak memenuhi kapasitas uplink sumber: restic menerima --limit-upload dalam KiB per detik, sedangkan rsync menerima --bwlimit.

Bentuk 1: Proxmox Backup Server sebagai datastore jarak jauh

PBS sesuai jika sumbernya adalah Proxmox VE dan unit pemulihannya adalah mesin virtual. VPS tidak dapat melakukan boot dari ISO Proxmox, jadi instal PBS di atas Debian. Versi 4.2 merupakan versi terbaru per Agustus 2026 dan dibangun di atas Debian 13 (trixie).

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Bandingkan checksum tersebut dengan nilai yang dipublikasikan pada halaman repositori paket Proxmox. Kepercayaan terhadap repositori apt hanya setinggi kepercayaan terhadap key yang Anda verifikasi. Kemudian tulis /etc/apt/sources.list.d/proxmox.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Berikan datastore filesystem atau volume khusus. Datastore yang penuh akan menghentikan backup, sedangkan datastore yang berbagi root filesystem dapat menyebabkan seluruh server berhenti berfungsi saat filesystem tersebut penuh.

Selanjutnya, buat akun yang akan digunakan oleh sumber, lalu berikan token, bukan password.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

Secret token hanya ditampilkan sekali dan tidak dapat dibaca kembali, jadi simpan saat secret tersebut muncul. Role sama pentingnya dengan token. DatastoreBackup dapat membuat dan memulihkan backup miliknya sendiri, serta tidak memiliki privilege Datastore.Prune. Dengan demikian, token tersebut tidak dapat menghapus snapshot yang telah ditulisnya.

Retensi pada PBS memiliki dua bagian, dan bagian kedua sering dilewati. Prune menghapus snapshot. Garbage collection menghapus chunk yang tidak direferensikan oleh snapshot mana pun yang masih ada. Ruang kosong tersedia setelah garbage collection, bukan setelah prune.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

Jalankan --dry-run setelah daftar snapshot yang akan dihapus terlihat benar. Garbage collection berjalan dalam dua fase: proses ini memperbarui waktu akses setiap chunk yang masih direferensikan, kemudian menghapus chunk yang waktu aksesnya lebih lama daripada batas waktu. Batas tersebut adalah 24 jam dan 5 menit sebelum proses dimulai. Masa tenggang ini mencegah chunk yang sedang ditulis oleh backup yang masih berjalan terhapus di tengah proses. Jadwalkan prune setiap hari dan garbage collection setiap minggu pada datastore, lalu tambahkan verify job agar target membaca ulang chunk miliknya dan melaporkan kerusakan pada disk sebelum proses pemulihan menemukannya.

Jika sumbernya sendiri merupakan instance PBS, server di lokasi luar dapat menarik data, bukan menerima push.

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

Jalankan sync job tersebut pada VPS dengan arah pull default. VPS mengakses datastore di lokasi utama, sehingga server di lokasi utama tidak menyimpan credential yang dapat mengakses salinan di lokasi luar.

Bentuk 2: repositori restic melalui SSH atau S3

Debian dan Ubuntu sama-sama menyediakan paket restic, tetapi keduanya tertinggal dari upstream. Versi 0.19.1 adalah versi terbaru per Agustus 2026. Instal binary resmi pada host sumber.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version menampilkan versi dan compiler Go yang digunakan untuk membangunnya. Pemutakhiran berikutnya dilakukan dengan sudo restic self-update, yang berfungsi pada binary resmi, tetapi tidak pada salinan yang diinstal dari apt.

Pada VPS backup, buat akun yang tidak memiliki kepemilikan atas hal lain, lalu salin public key host sumber ke /home/resticsrv/.ssh/authorized_keys.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

Inisialisasi repositori dari host sumber melalui SFTP.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

Simpan password tersebut di tempat yang bukan server ini maupun target backup. Jika password hilang, repositori tidak dapat dibaca dan tidak ada cara pemulihan sama sekali. Itulah konsekuensi enkripsi sisi klien.

Retensi dijalankan dengan satu perintah, dan bagian keduanya adalah yang membebaskan ruang disk.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget menghapus snapshot. prune menghapus file pack yang hanya dirujuk oleh snapshot tersebut, dan --prune menjalankannya secara otomatis ketika ada sesuatu yang benar-benar dihapus. Tanpa perintah itu, ukuran repositori tidak pernah berkurang. restic check memverifikasi struktur repositori, sedangkan --read-data-subset=10% membaca ulang dan menghitung ulang hash sepersepuluh file pack. Cara ini mendeteksi kerusakan pada target tanpa biaya membaca seluruh repositori. Bentuk lainnya, --read-data-subset=1/10, memeriksa sepersepuluh tetap. Dengan menaikkan angka pertama setiap minggu, seluruh repositori akan tercakup selama sepuluh minggu.

Jika suatu proses dihentikan secara paksa, proses berikutnya berhenti dengan repository is already locked exclusively by PID. Pastikan tidak ada backup yang sedang berjalan, lalu hapus kondisi tersebut dengan restic unlock.

Untuk object storage, string repositorinya menjadi s3:https://s3.example.net/web1, dengan kredensial di AWS_ACCESS_KEY_ID dan AWS_SECRET_ACCESS_KEY. Selebihnya identik. Dengan cara inilah restic berkomunikasi dengan object store MinIO yang di-host sendiri dan berjalan pada VPS yang sama.

Bentuk 3: rsync melalui SSH dengan kunci yang hanya dapat digunakan untuk pull

Properti keamanan bentuk ini adalah arah koneksi. Backup VPS terhubung ke sumber dan membaca data. Sumber tidak menyimpan kunci dan tidak memiliki rute ke host backup, sehingga kompromi pada sumber tidak dapat menjangkau backup sama sekali.

Buat pasangan kunci pada backup VPS, lalu pasang bagian publiknya pada sumber dengan perintah paksa.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync tersedia di dalam paket rsync pada /usr/bin/rrsync di Debian 13 dan Ubuntu 24.04. -ro hanya mengizinkan pembacaan dan menyiratkan -no-del, sehingga kunci ini tidak dapat menulis ke sumber atau menghapus apa pun di sana. restrict menonaktifkan fitur SSH yang tidak diperlukan di sini, termasuk penerusan port dan pty, sehingga kunci ini tidak dapat digunakan untuk login interaktif. Setelah itu, path bersifat relatif terhadap direktori yang Anda tentukan. Jadi, path jarak jauh / berarti /srv pada sumber.

Proses pull mempertahankan riwayat dengan hardlink. File yang tidak berubah di tree baru menjadi hardlink ke tree sebelumnya, sehingga hanya memerlukan satu entri direktori, bukan salinan kedua.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

Penggantian nama di bagian akhir membuat direktori bertanggal dapat dipercaya. Nama tersebut hanya muncul setelah rsync keluar dengan kode 0, sehingga transfer yang terhenti tidak pernah terlihat sebagai snapshot yang selesai. Hapus tree lama dengan satu baris perintah, dan pertahankan tiga puluh tree.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

Pahami biaya bentuk ini. Hardlink hanya menghilangkan duplikasi pada tingkat file secara utuh. Jadi, perubahan satu byte di dalam disk image berukuran 4 GB akan menyalin seluruh 4 GB, sedangkan restic dan PBS hanya menyimpan beberapa chunk yang berubah. Target juga menyimpan file Anda dalam plaintext, sehingga siapa pun yang memiliki akses root pada backup VPS dapat membacanya.

Enkripsi sisi klien, sehingga target tidak pernah melihat plaintext

Perlakukan VPS backup sebagai mesin yang tidak sepenuhnya Anda kendalikan. Mesin tersebut dikelola oleh provider, dan provider itu memiliki staf serta disk yang rusak lalu dibawa keluar dari gedung.

restic mengenkripsi setiap chunk di sumber sebelum mengirimkannya, sehingga repository hanya berisi ciphertext dan metadata tentang ukuran serta waktu. PBS menjadikan enkripsi sebagai opsi: buat sebuah key, lalu teruskan key tersebut pada setiap backup.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Cetak paper key dan simpan di lokasi fisik. Dokumentasi Proxmox menjelaskan risikonya secara tegas: tanpa key tersebut, file yang dicadangkan tidak dapat diakses. Simpan key di luar target backup, karena key yang disimpan di sebelah ciphertext tidak melindungi apa pun.

Mirror rsync tidak memiliki padanan untuk mekanisme ini. File disimpan sebagai file biasa. Jika data bersifat sensitif, terima bahwa target dapat membacanya, atau gunakan salah satu dari dua bentuk lainnya.

Mencegah sumber yang dibobol menghapus backup-nya sendiri

Penyerang yang berhasil menguasai sumber akan mencari backup berikutnya, sementara kredensial yang mengunggah backup tersebut tersimpan di mesin itu. Jika kredensial tersebut juga dapat menghapus, penyerang akan menggunakannya.

PBS mengatasi hal ini dengan role. Token yang hanya memiliki DatastoreBackup dapat menulis snapshot baru dan memulihkan snapshot miliknya sendiri. Token tersebut tidak dapat melakukan prune karena penghapusan snapshot memerlukan privilege Datastore.Prune yang terpisah. Jalankan retensi dari sisi PBS agar sumber tidak pernah menyimpan kredensial yang dapat menghapus apa pun.

restic melalui SFTP tidak memiliki pemisahan seperti itu karena SSH key yang dapat menulis ke repository juga dapat menghapus isinya. Solusinya adalah REST backend. Jalankan rest-server pada backup VPS dengan --append-only. Opsi ini mengizinkan pembuatan backup baru, tetapi mencegah penghapusan dan modifikasi backup yang sudah ada. Arahkan client ke rest:https://backup.example.net:8000/web1 menggunakan RESTIC_REST_USERNAME dan RESTIC_REST_PASSWORD. restic forget --prune dari sumber kemudian akan gagal. Ini adalah hasil yang diharapkan. Jalankan retensi dari mesin kedua dengan kredensialnya sendiri. Manual restic juga merekomendasikan --keep-within, bukan kebijakan berbasis jumlah, pada repository append-only karena penyerang yang membanjiri repository dengan snapshot palsu dapat mendorong snapshot asli Anda keluar dari jendela --keep-last.

rsync menyelesaikan masalah yang sama secara struktural dengan melakukan pull karena sumber tidak menyimpan kredensial untuk target.

Satu aturan berlaku untuk ketiga bentuk tersebut: kredensial yang dapat menghapus backup harus berada di mesin yang bukan mesin yang dicadangkan.

Masukkan latihan pemulihan ke kalender

Backup yang belum pernah Anda pulihkan masih berupa asumsi. Jadwalkan satu jam setiap kuartal dan uji backup tersebut.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r yang tidak menghasilkan output berarti tree hasil pemulihan sama dengan tree aktif. Di PBS, latihan yang sama adalah proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/, ditambah job verifikasi terjadwal yang membaca ulang chunk pada target dan melaporkan kegagalan checksum.

Latihan ini harus membuktikan lebih dari sekadar keutuhan byte.

  • Pulihkan dari mesin ketiga, bukan dari sumber, karena sumber adalah tepat hal yang Anda anggap sudah hilang. Artinya, password repository atau key PBS harus dapat diakses tanpa mesin tersebut.
  • Ukur durasi pemulihan dan catat hasilnya, lalu bandingkan dengan RTO yang Anda nyatakan. Bagan di atas menunjukkan batas minimum transfer. Angka sebenarnya juga mencakup proses dekripsi dan penulisan ke disk, serta waktu untuk menentukan snapshot yang ingin Anda gunakan.
  • Pulihkan sesuatu yang memiliki state, misalnya dump database yang kemudian Anda load ke instance sementara. File tar yang berhasil diekstrak bukan bukti bahwa aplikasi dapat start.

Disk termurah di dunia tidak ada nilainya sampai Anda pernah memulihkan data darinya.

FAQ

Apakah snapshot pada provider VPS saya merupakan backup di lokasi berbeda?

Tidak. Snapshot provider berada dalam akun yang sama, di balik login panel yang sama, dan pada invoice yang sama dengan server yang disalin. Siapa pun yang mendapatkan login tersebut dapat menghapus server dan semua snapshot-nya dalam satu sesi. Snapshot berguna untuk melakukan rollback dengan cepat sebelum upgrade berisiko, tetapi bukan salinan di lokasi kedua. Salinan di lokasi berbeda berada di bawah akun lain, idealnya pada provider lain, dengan kredensial yang tidak dimiliki mesin sumber.

Berapa banyak ruang disk yang saya perlukan untuk backup yang disimpan selama satu bulan?

Tentukan ukurannya berdasarkan usia snapshot tertua, bukan jumlah snapshot. Tool deduplikasi menyimpan setiap chunk unik satu kali, sehingga repository kira-kira berukuran sebesar data sumber ditambah data unik baru per hari dikalikan jumlah hari penyimpanan. Untuk 500 GB data yang berubah sebesar 5 GB per hari, backup harian selama satu minggu berukuran sekitar 535 GB dan riwayat selama satu tahun penuh berukuran 2,325 GB. Sediakan ruang tambahan, karena disk penuh akan menyebabkan backup berikutnya gagal, dan restic memerlukan ruang kosong saat menjalankan prune untuk mengemas ulang file pack sebelum ruang tersebut dapat dikembalikan.

Dapatkah server yang telah dibobol menghapus backup di lokasi berbeda miliknya sendiri?

Ya, kecuali Anda merancang sistem untuk mencegahnya. Pada repository SSH atau SFTP biasa, key yang dapat menulis juga dapat menghapus. Berikan kredensial kepada sumber yang tidak dapat menghapus data: token API PBS yang hanya memiliki role DatastoreBackup, yang tidak memiliki privilege Datastore.Prune, atau gunakan restic terhadap rest-server yang dijalankan dengan --append-only, yang menolak penghapusan dan modifikasi backup yang sudah ada. Desain pull memberikan perlindungan lebih jauh karena sumber tidak menyimpan kredensial untuk host backup sama sekali. Jalankan retensi dari sisi yang bukan sumber.

Sebaiknya saya menjalankan Proxmox Backup Server atau restic pada VPS backup?

Sesuaikan tool dengan unit yang ingin Anda pulihkan. Jika sumbernya adalah Proxmox VE dan Anda ingin memulihkan seluruh virtual machine, gunakan PBS karena tool ini melakukan backup pada level disk image dan memulihkan VM dalam satu langkah. Jika sumbernya adalah host Linux dan Anda ingin memulihkan file serta dump database, gunakan restic. Tool ini hanya memerlukan akun SSH pada target dan mengenkripsi data sebelum mengirimkannya. Menjalankan keduanya merupakan hal yang wajar: PBS untuk hypervisor dan restic untuk server yang tidak berjalan di atasnya.

Berapa lama waktu yang diperlukan untuk memulihkan data dari backup VPS?

Bagi ukuran data dengan kecepatan link untuk mendapatkan waktu minimum, lalu tambahkan waktu untuk dekripsi dan penulisan data. 500 GB melalui link 100 Mbit/s memerlukan 11.1 jam pada kecepatan maksimum link, sedangkan pemulihan yang sama melalui port 1 Gbit/s memerlukan 1.1 jam. Banyak file kecil dapat membuat proses lebih lambat daripada hasil perhitungan tersebut karena overhead setiap file. Ukur waktu satu proses pemulihan nyata dan gunakan hasil pengukuran itu, karena hanya angka tersebut yang dapat dijadikan dasar rencana pemulihan Anda.

#backups#restic#proxmox-backup-server#storage-vps#3-2-1