Cara Gunakan VPS Sebagai Sasaran Sandaran Luar Tapak

Apakah sebenarnya sasaran sandaran luar tapak (off-site backup)

Sasaran sandaran luar tapak ialah mesin kedua yang menyimpan salinan data anda dan gagal secara bebas daripada pelayan asal. VPS di penyedia lain merupakan pilihan paling murah yang boleh diperoleh kebanyakan pembaca. Terdapat tiga bentuk yang realistik: Proxmox Backup Server yang dijalankan pada VPS, repositori restic yang dicapai melalui SSH atau S3, atau cermin rsync yang ditarik oleh hos sandaran. Pilihan yang sesuai bergantung pada perkara yang anda pulihkan dan kepantasan pemulihan yang diperlukan. Pihak yang dibenarkan memadam salinan tersebut akan menentukan selebihnya.

Luar tapak bermaksud domain kegagalan yang berbeza. Ini bermakna penyedia yang berbeza, serta akaun yang tidak berkongsi log masuk dengan akaun yang menjalankan pelayan anda. Pelayan kedua di wilayah lain daripada penyedia yang sama mungkin terselamat daripada kebakaran di satu bangunan. Namun, ia tidak akan terselamat daripada log masuk panel kawalan yang terjejas, kerana satu akaun mengawal kedua-dua salinan tersebut.

Snapshot di penyedia anda bukanlah salinan kedua itu. Ia berada di sebalik kata laluan panel yang sama, jadi sesiapa yang mendapat kata laluan tersebut akan memadamkan pelayan dan snapshotnya dalam satu sesi. Perkhidmatan snapshot juga mengenakan bayaran setiap gigabait sebulan pada kadar yang jauh lebih tinggi daripada cakera biasa, yang menjadikan penyimpanan selama sembilan puluh hari sangat mahal. Perbezaan antara snapshot VPS dan sandaran perlu dibaca sebelum anda bergantung pada mana-mana daripadanya.

Antara tiga bentuk ini, yang manakah sesuai untuk anda

• Proxmox Backup Server (PBS): sumbernya ialah Proxmox VE (virtual environment) dan perkara yang anda pulihkan ialah keseluruhan mesin maya. Ia membuat sandaran pada tahap imej cakera, dan kerja pengesahannya membaca semula data yang berada pada sasaran.
• Repositori restic: sumbernya ialah satu atau beberapa hos Linux dan perkara yang anda pulihkan ialah direktori atau dump pangkalan data. Ia menyulitkan data pada klien, serta menyokong SSH dan S3, di samping protokol REST miliknya sendiri.
• rsync melalui SSH, ditarik oleh hos sandaran: anda mahukan fail pada sasaran sebagai fail biasa, yang boleh dibaca dengan ls dan cat, tanpa memerlukan perisian klien untuk mendapatkannya semula.

Jika anda tidak dapat membuat keputusan, jalankan restic. Ia menyulitkan data sebelum sebarang maklumat meninggalkan mesin, dan ia tidak memerlukan apa-apa pada sasaran kecuali akaun SSH dan cakera. Menyediakan sandaran restic pada VPS membincangkan bahagian klien dengan lebih mendalam, dan restic dan BorgBackup secara bersebelahan membincangkan pilihan tersebut jika anda sudah menjalankan Borg.

Menentukan saiz sasaran: kos pengekalan selama sebulan

Deduplikasi adalah sebab mengapa angka-angka tersebut lebih kecil daripada jangkaan ramai. restic dan PBS kedua-duanya memecahkan fail kepada ketulan (chunks) bersaiz berubah-ubah dan melakukan hashing pada setiap ketulan. Setiap ketulan unik disimpan sekali sahaja. Sandaran kedua bagi set data 500 GB tidak menambah 500 GB lagi. Ia hanya menambah ketulan yang berubah.

Oleh itu, saiz repositori mengikut usia snapshot tertua anda, bukan bilangan snapshot. Ambil 500 GB data dan 5 GB data unik baharu setiap hari. Repositori kemudiannya menyimpan asas 500 GB, ditambah kira-kira 5 GB untuk setiap hari sehingga snapshot tertua yang disimpan oleh polisi.

[
  {
    "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
  }
]

Lajur dolar meletakkan harga repositori tersebut pada 10 dolar AS setiap TB sebulan. Ia hanyalah pemegang tempat untuk pengiraan, bukan sebut harga daripada mana-mana penyedia, jadi gantikan dengan harga sebenar setiap TB bagi pelan yang anda pertimbangkan. Sandaran harian selama seminggu menyimpan kira-kira 535 GB. Sejarah penuh selama setahun menyimpan 2,325 GB, iaitu $23.25 sebulan berbanding $5.35 untuk seminggu. Sejarah adalah murah. Salinan asas adalah perkara yang anda bayar.

Deduplikasi tidak memberi kesan kepada data yang tiba dalam keadaan sudah dimampatkan atau disulitkan. Dump pangkalan data yang di-gzip berubah sepenuhnya pada setiap pelaksanaan, jadi setiap dump akan disimpan sebagai ketulan baharu dan repositori akan bertambah sebanyak satu dump penuh setiap malam. Tulis dump tanpa mampatan dan biarkan alat sandaran memampatkannya, memandangkan restic telah menyokong repositori termampat sejak 0.14 dan versi 0.19 menambah mod zstd fastest dan better. Pustaka foto dan video kurang berkesan untuk deduplikasi atas sebab yang sama, jadi tentukan saiznya berdasarkan kadar pertumbuhan sebenar dan bukannya daripada baris di atas.

Anda membeli cakera terbiar (idle disk) dan bukannya CPU di sini, yang merupakan situasi tepat di mana VPS storan lebih baik daripada VPS biasa.

Mengapa lebar jalur dan masa pemulihan menentukan pelan

Cakera adalah bahagian yang murah. Muat naik pertama dan pemulihan akhir adalah bahagian yang mahal. 500 GB adalah 4 trilion bit, jadi membahagikannya dengan kelajuan pautan memberikan had minimum berapa lama pemulihan penuh boleh diambil.

[
  {
    "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
  }
]

Itu adalah angka kadar talian tanpa overhead protokol, jadi anggap ia sebagai senario terbaik. Pada 100 Mbit/s, pemulihan penuh memerlukan 11.1 jam sebelum sesiapa pun boleh menyentuh data tersebut. Daripada muat naik rumah berkelajuan 40 Mbit/s, ia memerlukan 27.8 jam. Pada port 1 Gbit/s, pemulihan yang sama mengambil masa 1.1 jam. Banyak fail kecil berjalan lebih perlahan daripada pengiraan matematik, kerana overhead setiap fail menjadi dominan apabila saiz fail di bawah beberapa ratus kilobait.

Dua perkara perlu diambil perhatian. Jika objektif masa pemulihan (RTO) anda, iaitu tempoh gangguan yang boleh anda toleransi, adalah empat jam, pemulihan 500 GB melalui pautan 100 Mbit/s sudah pun melepasi had tersebut, dan cakera yang lebih murah tidak membantu. Selain itu, kebanyakan pelan VPS mengehadkan pemindahan keluar, jadi satu pemulihan penuh akan menghabiskan 0.5 TB daripada kuota bulanan hos sandaran. Semak kuota tersebut, dan semak tindakan penyedia apabila anda melampauinya, sebelum anda benar-benar memerlukan data tersebut.

Sandaran pertama adalah keseluruhan set data dan ia merupakan proses paling perlahan yang akan anda lakukan. Mulakannya pada hari Jumaat, dan hadkan kadarnya supaya ia tidak menepukan uplink sumber: restic menggunakan --limit-upload dalam KiB sesaat, rsync menggunakan --bwlimit.

Bentuk 1: Proxmox Backup Server sebagai storan data jauh

PBS sesuai digunakan apabila sumbernya ialah Proxmox VE dan unit pemulihan ialah mesin maya. VPS tidak boleh melakukan boot daripada ISO Proxmox, jadi pasang PBS di atas Debian. Versi 4.2 adalah versi semasa setakat Ogos 2026 dan dibina 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 diterbitkan pada halaman repositori pakej Proxmox. Repositori apt hanya boleh dipercayai setakat kunci yang anda sahkan. Kemudian jalankan /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 storan data sistem failnya sendiri atau volumnya sendiri. Storan data yang penuh akan menghentikan proses sandaran, dan storan data yang berkongsi sistem fail root akan menyebabkan keseluruhan pelayan terhenti apabila ia penuh.

Seterusnya, cipta akaun yang akan digunakan oleh sumber tersebut, dan berikan token kepadanya sebagai ganti kata laluan.

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'

Rahsia token hanya dipaparkan sekali dan tidak boleh dibaca semula, jadi simpan ia apabila ia muncul. Peranan adalah sama penting dengan token. DatastoreBackup boleh mencipta dan memulihkan sandarannya sendiri, dan ia tidak membawa keistimewaan Datastore.Prune, jadi token tersebut tidak boleh memadamkan snapshot yang telah ditulisnya.

Pengekalan pada PBS mempunyai dua bahagian, dan bahagian kedua sering diabaikan oleh pengguna. Prune memadamkan snapshot. Garbage collection memadamkan ketulan (chunks) yang tidak dirujuk oleh mana-mana snapshot yang masih ada. Ruang kosong hanya akan muncul selepas garbage collection, bukan selepas 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 sebaik sahaja senarai snapshot yang akan dipadamkan kelihatan betul. Garbage collection berjalan dalam dua fasa: ia mengemas kini masa akses bagi setiap ketulan yang masih dirujuk, kemudian memadamkan ketulan yang masa aksesnya lebih lama daripada tempoh had, iaitu 24 jam dan 5 minit sebelum proses bermula. Tempoh tangguh ini wujud supaya ketulan yang sedang ditulis oleh sandaran yang sedang berjalan tidak dipadamkan secara tidak sengaja. Jadualkan prune setiap hari dan garbage collection setiap minggu pada storan data, serta tambah tugasan pengesahan (verify job) supaya sasaran membaca semula ketulannya sendiri dan melaporkan kerosakan pada cakera sebelum proses pemulihan dilakukan.

Jika sumbernya sendiri merupakan instans PBS, kotak luar tapak (off-site box) boleh melakukan pull dan bukannya 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 tugasan penyelarasan (sync job) tersebut pada VPS, dalam arah pull lalai. VPS mencapai storan data di rumah, yang bermaksud kotak di rumah tidak memegang sebarang kelayakan yang boleh mengakses salinan di luar tapak.

Bentuk 2: repositori restic melalui SSH atau S3

Debian dan Ubuntu kedua-duanya menyediakan pakej restic, namun versi yang dibekalkan ketinggalan berbanding versi asal. Versi 0.19.1 adalah versi semasa setakat Ogos 2026. Pasang binari rasmi pada hos 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 mencetak versi dan pengkompil Go yang digunakan untuk membinanya. Naik taraf seterusnya menggunakan sudo restic self-update, yang berfungsi pada binari rasmi dan bukan pada salinan yang dipasang melalui apt.

Pada VPS sandaran, buat satu akaun yang tidak memiliki apa-apa fail lain, kemudian salin kunci awam hos sumber ke dalam /home/resticsrv/.ssh/authorized_keys.

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

Mulakan repositori daripada 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 kata laluan tersebut di lokasi yang bukan pelayan ini dan bukan sasaran sandaran. Jika ia hilang, repositori tidak boleh dibaca dan tiada cara pemulihan langsung. Itulah syarat yang ditetapkan oleh penyulitan sisi klien.

Pengekalan data dilakukan dengan satu arahan, dan bahagian keduanya adalah proses yang mengosongkan ruang cakera.

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

forget memadamkan snapshot. prune memadamkan fail pek yang hanya dirujuk oleh snapshot tersebut, dan --prune menjalankannya secara automatik apabila sesuatu telah pun dibuang. Tanpanya, saiz repositori tidak akan berkurang. restic check mengesahkan struktur repositori, dan --read-data-subset=10% membaca semula serta melakukan hashing pada satu persepuluh fail pek, yang mengesan kerosakan pada sasaran tanpa perlu membaca keseluruhan data. Bentuk lain, --read-data-subset=1/10, menyemak satu persepuluh yang tetap, jadi meningkatkan nombor pertama itu setiap minggu akan meliputi keseluruhan repositori dalam tempoh sepuluh minggu.

Jika sesuatu proses dimatikan, proses seterusnya akan terhenti dengan repository is already locked exclusively by PID. Pastikan tiada sandaran sedang berjalan, kemudian bersihkan status tersebut dengan restic unlock.

Untuk storan objek, rentetan repositori menjadi s3:https://s3.example.net/web1, dengan kelayakan dalam AWS_ACCESS_KEY_ID dan AWS_SECRET_ACCESS_KEY. Segala perkara lain adalah sama, itulah cara restic berhubung dengan storan objek MinIO yang dihoskan sendiri yang berjalan pada VPS yang sama.

Bentuk 3: rsync melalui SSH dengan kunci 'pull-only'

Ciri keselamatan bagi bentuk ini ialah arah sambungan. VPS sandaran menyambung ke sumber dan membaca data. Sumber tidak menyimpan kunci dan tiada laluan ke hos sandaran, jadi jika sumber dicerobohi, penyerang tidak boleh mencapai sandaran tersebut sama sekali.

Jana pasangan kunci pada VPS sandaran, kemudian pasang bahagian awam pada sumber dengan arahan paksa (forced command).

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

rrsync disertakan di dalam pakej rsync pada /usr/bin/rrsync dalam Debian 13 dan Ubuntu 24.04. -ro membenarkan bacaan sahaja dan membayangkan -no-del, jadi kunci ini tidak boleh menulis ke sumber atau memadam apa-apa di sana. restrict mematikan ciri SSH yang tidak diperlukan di sini, termasuk port forwarding dan pty, supaya kunci tidak boleh digunakan untuk log masuk interaktif. Laluan kemudiannya adalah relatif kepada direktori yang anda namakan, jadi laluan jauh / bermaksud /srv pada sumber.

Proses 'pull' mengekalkan sejarah dengan pautan keras (hardlinks). Fail yang tidak berubah dalam pepohon baharu adalah pautan keras kepada pepohon sebelumnya, jadi ia hanya menggunakan entri direktori dan bukannya 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"

Penamaan semula pada akhir proses adalah perkara yang menjadikan direktori bertarikh boleh dipercayai: nama tersebut hanya muncul selepas rsync keluar dengan kod 0, jadi pemindahan yang terganggu tidak akan kelihatan seperti syot kilas (snapshot) yang lengkap. Luputkan pepohon lama dengan satu baris arahan, dengan mengekalkan tiga puluh salinan.

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

Jujurlah tentang kos bentuk ini. Pautan keras hanya menyahganda (deduplicate) fail keseluruhan, jadi menukar satu bait di dalam imej cakera 4 GB akan menyalin kesemua 4 GB tersebut, sedangkan restic dan PBS akan menyimpan hanya beberapa ketul (chunks) yang berubah. Sasaran juga menyimpan fail anda dalam teks biasa (plaintext), jadi sesiapa yang mempunyai akses root pada VPS sandaran boleh membacanya.

Penyulitan sisi klien, supaya sasaran tidak melihat teks biasa

Anggap VPS sandaran sebagai mesin yang tidak dikawal sepenuhnya oleh anda. Ia mempunyai penyedia, dan penyedia tersebut mempunyai kakitangan serta cakera rosak yang mungkin dibawa keluar dari bangunan.

restic menyulitkan setiap ketulan data pada sumber sebelum menghantarnya, jadi repositori tersebut hanyalah teks siber berserta metadata tentang saiz dan masa. PBS menjadikan penyulitan sebagai pilihan: cipta kunci, kemudian gunakannya pada setiap sandaran.

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 kunci kertas dan simpan di lokasi fizikal. Dokumentasi Proxmox menyatakan dengan jelas tentang risikonya: tanpa kunci tersebut, fail yang disandarkan tidak boleh diakses. Simpan kunci tersebut di luar sasaran sandaran, kerana kunci yang disimpan bersama teks siber tidak melindungi sesiapa.

Cermin rsync tidak mempunyai padanan. Fail akan disimpan sebagai fail biasa. Jika data tersebut sensitif, sama ada terima hakikat bahawa sasaran boleh membacanya, atau gunakan salah satu daripada dua bentuk yang lain.

Menghalang sumber yang terjejas daripada memadam sandarannya sendiri

Penyerang yang menguasai pelayan sumber akan mencari sandaran seterusnya, dan kelayakan yang memuat naik sandaran tersebut berada di mesin yang sama. Jika kelayakan itu mempunyai kebenaran untuk memadam, penyerang akan menggunakannya.

PBS menangani perkara ini dengan peranan (roles). Token yang hanya memegang DatastoreBackup boleh menulis snapshot baharu dan memulihkan snapshot miliknya sendiri, tetapi ia tidak boleh melakukan pembersihan (prune), kerana memadam snapshot memerlukan keistimewaan Datastore.Prune yang berasingan. Jalankan pengekalan (retention) daripada pihak PBS supaya sumber tidak pernah memegang kelayakan yang boleh memadam apa-apa.

restic melalui SFTP tidak mempunyai pembahagian sedemikian, kerana kunci SSH yang menulis ke repositori juga boleh memadam daripadanya. Penyelesaiannya ialah REST backend. Jalankan rest-server pada VPS sandaran dengan --append-only, yang membenarkan penciptaan sandaran baharu tetapi menghalang pemadaman dan pengubahsuaian sandaran sedia ada, dan halakan klien ke rest:https://backup.example.net:8000/web1 menggunakan RESTIC_REST_USERNAME dan RESTIC_REST_PASSWORD. Perintah restic forget --prune daripada sumber kemudiannya akan gagal, yang merupakan hasil yang diingini, jadi pengekalan dijalankan daripada mesin kedua dengan kelayakannya sendiri. Manual restic juga mengesyorkan --keep-within berbanding polisi berasaskan kiraan pada repositori jenis append-only, kerana penyerang yang membanjiri repositori dengan snapshot sampah akan menolak snapshot sebenar anda keluar daripada tetingkap --keep-last.

rsync menyelesaikan masalah yang sama secara struktur dengan cara menarik (pull), kerana sumber tidak memegang sebarang kelayakan untuk sasaran.

Satu peraturan merangkumi ketiga-tiga bentuk ini: kelayakan yang boleh memadam sandaran mestilah berada pada mesin yang bukan mesin yang sedang disandarkan.

Jadualkan latihan pemulihan

Sandaran yang tidak pernah dipulihkan hanyalah satu hipotesis. Peruntukkan satu jam setiap suku tahun untuk mengujinya.

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 mengeluarkan sebarang output bermakna struktur fail yang dipulihkan sepadan dengan data asal. Pada PBS, latihan yang sama adalah proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/, ditambah dengan tugasan pengesahan berjadual yang membaca semula ketulan data pada sasaran dan melaporkan kegagalan checksum.

Latihan ini perlu membuktikan lebih daripada sekadar bait data yang utuh.

• Lakukan pemulihan daripada mesin ketiga, bukan daripada sumber asal, kerana sumber asal adalah apa yang anda andaikan telah hilang. Ini bermakna kata laluan repositori atau kunci PBS mesti boleh dicapai tanpa mesin tersebut.
• Rekod masa pemulihan dan bandingkan dengan RTO yang telah ditetapkan. Carta di atas memberikan had minimum pemindahan. Angka sebenar juga merangkumi penyahsulitan dan penulisan ke cakera, serta masa yang diambil untuk menentukan snapshot yang diperlukan.
• Pulihkan sesuatu yang mempunyai status, seperti dump pangkalan data yang kemudiannya dimuatkan ke dalam instans sementara. Fail tar yang berjaya diekstrak bukanlah bukti bahawa aplikasi tersebut boleh bermula.

Cakera paling murah di dunia tidak bernilai sehingga anda berjaya melakukan pemulihan daripadanya sekurang-kurangnya sekali.

FAQ

Adakah snapshot di penyedia VPS saya merupakan sandaran luar tapak (off-site backup)?

Bukan. Snapshot penyedia berada dalam akaun yang sama, di sebalik log masuk panel yang sama, dan pada invois yang sama dengan pelayan yang disalin. Sesiapa yang memperoleh log masuk tersebut boleh memadamkan pelayan dan setiap snapshotnya dalam satu sesi. Snapshot berguna untuk pemulihan pantas sebelum naik taraf yang berisiko, namun ia bukan lokasi kedua. Salinan luar tapak berada di bawah akaun yang berbeza, sebaik-baiknya di penyedia yang berbeza, dengan kelayakan yang tidak dimiliki oleh mesin sumber.

Berapakah ruang cakera yang saya perlukan untuk menyimpan sandaran selama sebulan?

Tentukan saiz berdasarkan usia snapshot tertua anda dan bukannya bilangan snapshot. Alat penyahduplikasi (deduplicating tool) menyimpan setiap ketulan unik sekali sahaja, jadi saiz repositori adalah lebih kurang saiz sumber ditambah dengan data unik baharu setiap hari didarab dengan bilangan hari anda menyimpannya. Bagi 500 GB data yang berubah sebanyak 5 GB sehari, sandaran harian selama seminggu adalah kira-kira 535 GB dan sejarah setahun penuh adalah 2,325 GB. Sediakan ruang tambahan, kerana cakera yang penuh akan menyebabkan sandaran seterusnya gagal, dan fungsi prune pada restic memerlukan ruang kosong untuk menyusun semula fail pek sebelum ia boleh mengembalikan ruang tersebut.

Bolehkah pelayan yang telah diceroboh memadamkan sandaran luar tapaknya sendiri?

Boleh, melainkan anda telah merancang untuk menghalangnya. Dengan repositori SSH atau SFTP biasa, kunci yang digunakan untuk menulis juga boleh memadam. Berikan sumber kelayakan yang tidak boleh memadam data: token API PBS yang hanya memegang peranan DatastoreBackup, yang tidak mempunyai keistimewaan Datastore.Prune, atau gunakan restic terhadap rest-server yang dimulakan dengan --append-only, yang menolak pemadaman dan pengubahsuaian sandaran sedia ada. Reka bentuk tarik (pull design) adalah lebih selamat, kerana sumber tidak memegang sebarang kelayakan untuk hos sandaran. Jalankan pengekalan (retention) daripada pihak yang bukan sumber.

Patutkah saya menjalankan Proxmox Backup Server atau restic pada VPS sandaran?

Padankan alat tersebut dengan unit yang ingin anda pulihkan. Jika sumbernya adalah Proxmox VE dan anda mahu memulihkan keseluruhan mesin maya, jalankan PBS, kerana ia membuat sandaran pada tahap imej cakera dan memulihkan VM dalam satu langkah. Jika sumbernya adalah hos Linux dan anda mahu memulihkan fail serta dump pangkalan data, jalankan restic, yang hanya memerlukan akaun SSH pada sasaran dan menyulitkan data sebelum menghantarnya. Menjalankan kedua-duanya adalah perkara biasa: PBS untuk hipervisor, restic untuk pelayan yang tidak berada di atasnya.

Berapa lamakah masa yang diambil untuk pemulihan daripada sandaran VPS?

Bahagikan saiz data dengan kelajuan pautan untuk mendapatkan anggaran minimum, kemudian tambah masa untuk penyahsulitan dan penulisan. 500 GB melalui pautan 100 Mbit/s mengambil masa 11.1 jam pada kadar talian, dan pemulihan yang sama melalui port 1 Gbit/s mengambil masa 1.1 jam. Banyak fail kecil akan berjalan lebih perlahan daripada pengiraan tersebut disebabkan oleh overhead setiap fail. Lakukan satu pemulihan sebenar dan gunakan nombor yang diukur itu, kerana itulah satu-satunya nombor yang boleh dipercayai oleh pelan pemulihan anda.