VPS als off-site back-updoel instellen

Wat een off-site back-updoel daadwerkelijk is

Een off-site back-updoel is een tweede machine die een kopie van uw gegevens bevat en onafhankelijk van het origineel faalt; een VPS bij een andere provider is voor de meeste lezers de goedkoopste optie. Er zijn drie realistische vormen: Proxmox Backup Server draaiend op de VPS, een restic-repository die via SSH of S3 wordt benaderd, of een rsync-mirror die door de back-uphost wordt opgehaald. Welke optie geschikt is, hangt af van wat u herstelt en hoe snel u het weer nodig heeft. Wie de kopie mag verwijderen, bepaalt de rest.

Off-site betekent een ander storingsdomein. Dat houdt in: een andere provider en een account dat geen inloggegevens deelt met het account waarop uw server draait. Een tweede server in een andere regio van dezelfde provider overleeft een brand in één gebouw. Deze overleeft echter geen gecompromitteerde inloggegevens van het configuratiescherm, omdat één account beide kopieën beheert.

Een snapshot bij uw provider is niet die tweede kopie. Deze bevindt zich achter hetzelfde wachtwoord van het configuratiescherm, dus wie dat wachtwoord bemachtigt, verwijdert de server en de bijbehorende snapshots in één sessie. Snapshot-diensten factureren bovendien per gigabyte per maand tegen tarieven die aanzienlijk hoger liggen dan die voor standaard schijfruimte, wat het bewaren van snapshots gedurende negentig dagen kostbaar maakt. Het verschil tussen VPS-snapshots en back-ups is het lezen waard voordat u op een van beide vertrouwt.

Welke van de drie vormen past bij u

• Proxmox Backup Server (PBS): de bron is Proxmox VE (virtual environment) en wat u herstelt is een volledige virtuele machine. Het maakt back-ups op het niveau van schijfimages en de verificatietaken lezen de data op de doelbestemming opnieuw uit.
• Een restic repository: de bron is een of meerdere Linux-hosts en wat u herstelt is een map of een database-dump. Het versleutelt op de client en ondersteunt SSH en S3, naast het eigen REST-protocol.
• rsync over SSH, opgehaald door de backup-host: u wilt de bestanden op de doelbestemming als gewone bestanden, leesbaar met ls en cat, zonder dat er client-software nodig is om ze terug te halen.

Als u niet kunt kiezen, gebruik dan restic. Het versleutelt alles voordat het de machine verlaat en vereist niets op de doelbestemming behalve een SSH-account en schijfruimte. Het instellen van restic-back-ups op een VPS behandelt de client-kant uitgebreider, en restic en BorgBackup naast elkaar behandelt de keuze als u al met Borg werkt.

De omvang van het doel bepalen: wat kost een maand retentie

Deduplicatie is de reden waarom de getallen lager uitvallen dan men vaak verwacht. Zowel restic als PBS splitsen bestanden in chunks van variabele grootte en voorzien elke chunk van een hash. Elke unieke chunk wordt slechts eenmaal opgeslagen. De tweede back-up van een dataset van 500 GB voegt niet nog eens 500 GB toe. Het voegt alleen de gewijzigde chunks toe.

De grootte van de repository volgt dus de ouderdom van uw oudste snapshot, niet het aantal snapshots. Neem 500 GB aan data en 5 GB aan nieuwe unieke data per dag. De repository bevat dan de basis van 500 GB, plus ongeveer 5 GB voor elke dag terug tot aan de oudste snapshot die het beleid bewaart.

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

De dollar-kolom prijst die repository op 10 Amerikaanse dollar per TB per maand. Dit is een tijdelijke aanduiding voor de berekening, geen offerte van een specifieke aanbieder; vervang dit door de werkelijke prijs per TB van het abonnement dat u overweegt. Een week aan dagelijkse back-ups beslaat ongeveer 535 GB. Een volledig jaar aan historie beslaat 2,325 GB, wat neerkomt op $23.25 per maand tegenover $5.35 voor de week. Historie is goedkoop. U betaalt voor de basiskopie.

Deduplicatie heeft geen effect op data die al gecomprimeerd of versleuteld binnenkomt. Een gzipped database-dump verandert bij elke uitvoering volledig, waardoor elke dump als nieuwe chunks wordt opgeslagen en de repository elke nacht met een volledige dump groeit. Schrijf de dump ongecomprimeerd en laat de back-uptool de compressie uitvoeren, aangezien restic sinds versie 0.14 gecomprimeerde repositories ondersteunt en versie 0.19 de fastest en better zstd-modi heeft toegevoegd. Foto- en videobibliotheken dedupliceren om dezelfde reden slecht; bereken de omvang daarvan op basis van hun werkelijke groei in plaats van de bovenstaande rijen.

U koopt hier inactieve schijfruimte in plaats van CPU-kracht, en dat is precies het scenario waarin een storage VPS beter presteert dan een reguliere VPS.

Waarom bandbreedte en hersteltijd bepalend zijn voor het plan

Schijfruimte is het goedkope onderdeel. De eerste upload en het uiteindelijke herstel zijn de kostbare onderdelen. 500 GB is 4 biljoen bits; delen door de verbindingssnelheid geeft de ondergrens voor hoe lang een volledig herstel kan duren.

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

Dit zijn theoretische snelheden zonder protocol-overhead, dus beschouw ze als het best mogelijke scenario. Bij 100 Mbit/s heeft een volledig herstel 11.1 uur nodig voordat iemand bij de data kan. Vanaf een thuisverbinding met een upload van 40 Mbit/s duurt dit 27.8 uur. Op een 1 Gbit/s-poort duurt hetzelfde herstel 1.1 uur. Veel kleine bestanden worden trager verwerkt dan de rekensom suggereert, omdat de overhead per bestand dominant wordt zodra bestanden kleiner zijn dan enkele honderden kilobytes.

Hieruit volgen twee conclusies. Als uw recovery time objective (RTO), de uitvaltijd die u kunt tolereren, vier uur is, dan heeft een herstel van 500 GB over een 100 Mbit/s-verbinding deze doelstelling al gemist, en goedkopere schijfruimte helpt hier niet bij. Bovendien hanteren de meeste VPS-abonnementen een limiet op uitgaand verkeer, waardoor één volledig herstel 0,5 TB van het maandelijkse quotum van de back-uphost verbruikt. Controleer dat quotum en ga na wat de provider doet wanneer u dit overschrijdt, voordat u de data daadwerkelijk nodig heeft.

De eerste back-up bevat de volledige dataset en is de traagste run die u ooit zult uitvoeren. Start deze op een vrijdag en pas rate-limiting toe zodat de uplink van de bron niet verzadigd raakt: restic gebruikt --limit-upload in KiB per seconde, rsync gebruikt --bwlimit.

Vorm 1: Proxmox Backup Server als externe datastore

PBS is geschikt wanneer de bron een Proxmox VE-omgeving is en het herstelobject een virtuele machine betreft. Een VPS kan de Proxmox ISO niet opstarten, installeer PBS daarom boven op Debian. Versie 4.2 is de huidige versie per augustus 2026 en is gebaseerd op 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

Vergelijk deze checksum met de waarde die is gepubliceerd op de pagina met Proxmox-pakketrepositories. Een apt-repository is slechts zo betrouwbaar als de sleutel die u heeft geverifieerd. Voer vervolgens /etc/apt/sources.list.d/proxmox.sources uit:

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

Geef de datastore een eigen bestandssysteem of een eigen volume. Een volle datastore stopt back-ups, en een datastore die het root-bestandssysteem deelt, legt de gehele server plat wanneer deze volloopt.

Maak vervolgens het account aan dat de bron zal gebruiken en verstrek een token in plaats van een wachtwoord.

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'

Het token-geheim wordt slechts eenmaal getoond en kan niet opnieuw worden uitgelezen, sla het dus op zodra het verschijnt. De rol is net zo belangrijk als het token. DatastoreBackup kan eigen back-ups maken en herstellen, en beschikt niet over de Datastore.Prune-bevoegdheid, waardoor dat token geen snapshots kan verwijderen die het zelf heeft geschreven.

Retentie op PBS bestaat uit twee helften, en de tweede helft wordt vaak overgeslagen. Prune verwijdert snapshots. Garbage collection verwijdert de chunks waarnaar geen enkele overgebleven snapshot meer verwijst. Vrije ruimte verschijnt pas na garbage collection, niet na 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

Voer --dry-run uit zodra de lijst met snapshots die verwijderd gaan worden correct lijkt. Garbage collection draait in twee fasen: het werkt de toegangstijd bij van elke chunk waarnaar nog wordt verwezen, en verwijdert vervolgens chunks waarvan de toegangstijd ouder is dan de drempelwaarde, die 24 uur en 5 minuten vóór de start van de taak ligt. Deze respijtperiode bestaat zodat een chunk die op dat moment door een actieve back-up wordt geschreven, niet onder de back-up vandaan wordt verwijderd. Plan prune dagelijks en garbage collection wekelijks in op de datastore, en voeg een verify-taak toe zodat de doelserver de eigen chunks opnieuw leest en corruptie op de schijf rapporteert voordat een herstelactie dit doet.

Als de bron zelf een PBS-instantie is, kan de externe server gegevens ophalen (pull) in plaats van dat deze worden gepusht.

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'

Voer die sync-taak uit op de VPS, in de standaard pull-richting. De VPS benadert de thuis-datastore, wat betekent dat de thuis-server geen inloggegevens bezit die de externe kopie kunnen wijzigen.

Vorm 2: een restic-repository via SSH of S3

Debian en Ubuntu bieden beide restic aan in hun pakketbronnen, maar deze lopen achter op de upstream-versies. Versie 0.19.1 is de huidige versie per augustus 2026. Installeer het officiële binaire bestand op de bronhost.

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 toont de versie en de Go-compiler waarmee deze is gebouwd. Latere upgrades verlopen via sudo restic self-update; dit werkt alleen bij officiële binaire bestanden en niet bij een kopie die via apt is geïnstalleerd.

Maak op de backup-VPS een account aan dat nergens anders eigenaar van is en kopieer vervolgens de publieke sleutel van de bronhost naar /home/resticsrv/.ssh/authorized_keys.

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

Initialiseer de repository vanaf de bronhost via 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

Sla dat wachtwoord op een locatie op die noch deze server, noch het backup-doel is. Als u het verliest, is de repository onleesbaar en is er geen enkel herstelpad mogelijk. Dat is de afspraak die u aangaat bij client-side encryptie.

Retentiebeleid is één commando, waarvan het tweede deel de schijfruimte vrijmaakt.

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

forget verwijdert snapshots. prune verwijdert de pack-bestanden waarnaar alleen die snapshots verwezen, en --prune voert dit automatisch uit wanneer er daadwerkelijk iets is verwijderd. Zonder deze optie krimpt de repository nooit. restic check verifieert de structuur van de repository en --read-data-subset=10% leest en hasht een tiende van de pack-bestanden opnieuw; dit detecteert corruptie op de doelserver zonder de kosten van het volledig uitlezen van alle data. De andere vorm, --read-data-subset=1/10, controleert een vast tiende deel, waardoor het wekelijks ophogen van dat eerste getal de gehele repository over tien weken dekt.

Als een proces wordt afgebroken, stopt de volgende run met repository is already locked exclusively by PID. Controleer of er geen backup actief is en wis de lock vervolgens met restic unlock.

Voor object storage wordt de repository-string s3:https://s3.example.net/web1, met inloggegevens in AWS_ACCESS_KEY_ID en AWS_SECRET_ACCESS_KEY. Al het overige is identiek; op deze manier communiceert restic met een zelfgehoste MinIO object store die op dezelfde VPS draait.

Vorm 3: rsync via SSH met een 'pull-only' sleutel

Het beveiligingskenmerk van deze vorm is de richting. De backup-VPS maakt verbinding met de bron en leest de gegevens. De bron beschikt niet over een sleutel en heeft geen route naar de backup-host, waardoor een inbreuk op de bron de backups op geen enkele wijze kan bereiken.

Genereer een sleutelpaar op de backup-VPS en installeer de publieke helft op de bron met een geforceerd commando.

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

rrsync wordt meegeleverd in het rsync-pakket op /usr/bin/rrsync op Debian 13 en Ubuntu 24.04. -ro staat alleen lezen toe en impliceert -no-del, waardoor deze sleutel niet naar de bron kan schrijven of daar iets kan verwijderen. restrict schakelt de SSH-functies uit die hier niet nodig zijn, waaronder port forwarding en de pty, zodat de sleutel niet kan worden gebruikt voor een interactieve login. Paden zijn vervolgens relatief aan de map die u heeft opgegeven, dus het externe pad / betekent /srv op de bron.

De pull-actie behoudt de historie met hardlinks. Ongewijzigde bestanden in de nieuwe boomstructuur zijn hardlinks naar de vorige boomstructuur, waardoor ze slechts een directory-vermelding kosten in plaats van een tweede kopie.

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"

De hernoeming aan het einde maakt een gedateerde map betrouwbaar: de naam verschijnt pas nadat rsync is afgesloten met exitcode 0, waardoor een onderbroken overdracht er nooit uitziet als een voltooide snapshot. Verwijder oude structuren met één regel en behoud er dertig.

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

Wees realistisch over de kosten van deze vorm. Hardlinks ontdubbelen alleen volledige bestanden; het wijzigen van één byte in een disk image van 4 GB kopieert dus alle 4 GB, terwijl restic en PBS slechts enkele gewijzigde chunks zouden opslaan. Het doelbestand bevat uw bestanden bovendien in leesbare tekst (plaintext), dus iedereen met root-toegang op de backup-VPS kan ze inzien.

Client-side encryptie, zodat de doelserver nooit plaintext ziet

Beschouw de backup-VPS als een machine waarover u geen volledige controle heeft. Deze heeft een provider, en die provider heeft personeel en defecte schijven die het pand verlaten.

restic versleutelt elk blok op de bronmachine voordat het wordt verzonden, waardoor de repository uit ciphertext bestaat, aangevuld met metadata over groottes en tijdstippen. Bij PBS is encryptie optioneel: maak een sleutel aan en geef deze bij elke backup op.

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

Print de papieren sleutel uit en bewaar deze op een fysieke locatie. De documentatie van Proxmox is duidelijk over de risico's: zonder de sleutel zijn de geback-upte bestanden ontoegankelijk. Bewaar de sleutel niet op de backup-doelserver, aangezien een sleutel die naast de ciphertext wordt bewaard, geen enkele bescherming biedt.

rsync-mirrors hebben geen equivalent. De bestanden komen aan als gewone bestanden. Als de data gevoelig is, moet u accepteren dat de doelserver deze kan lezen, of gebruikmaken van een van de andere twee methoden.

Voorkom dat een gecompromitteerde bron zijn eigen back-ups wist

Een aanvaller die de bronserver overneemt, zoekt direct naar de back-ups. De inloggegevens voor de upload staan immers op diezelfde machine. Als deze gegevens ook verwijderrechten hebben, zal de aanvaller deze gebruiken.

PBS lost dit op met rollen. Een token met alleen DatastoreBackup kan nieuwe snapshots schrijven en eigen snapshots herstellen, maar kan deze niet opschonen. Het verwijderen van een snapshot vereist namelijk het afzonderlijke Datastore.Prune-privilege. Voer het retentiebeleid uit vanaf de kant van PBS, zodat de bronserver nooit over inloggegevens beschikt waarmee bestanden kunnen worden verwijderd.

restic via SFTP kent een dergelijke scheiding niet, aangezien de SSH-sleutel die naar de repository schrijft, deze ook kan verwijderen. De oplossing is de REST-backend. Draai rest-server op de back-up VPS met --append-only; dit staat het aanmaken van nieuwe back-ups toe, maar blokkeert het verwijderen of wijzigen van bestaande back-ups. Wijs de client naar rest:https://backup.example.net:8000/web1 met behulp van RESTIC_REST_USERNAME en RESTIC_REST_PASSWORD. Een restic forget --prune vanaf de bron zal vervolgens falen, wat het beoogde resultaat is. Voer daarom het retentiebeleid uit vanaf een tweede machine met eigen inloggegevens. De restic-handleiding adviseert bovendien --keep-within in plaats van op aantallen gebaseerd beleid bij append-only repositories. Een aanvaller die de repository overspoelt met nutteloze snapshots zou anders uw echte back-ups uit een --keep-last-venster kunnen drukken.

rsync lost hetzelfde probleem structureel op door middel van een 'pull'-methode, aangezien de bronserver geen inloggegevens voor de doelserver bezit.

Eén regel is van toepassing op alle drie de scenario's: de inloggegevens die back-ups kunnen verwijderen, bevinden zich op een andere machine dan de machine waarvan een back-up wordt gemaakt.

Plan de hersteloefening in de agenda

Een back-up die u nooit heeft hersteld, is slechts een hypothese. Reserveer elk kwartaal een uur en test deze.

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 die niets afdrukt, betekent dat de herstelde boomstructuur overeenkomt met de actieve versie. Op PBS is dezelfde oefening proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/, aangevuld met een geplande verificatietaak die blokken op de doelserver opnieuw leest en checksum-fouten rapporteert.

De oefening moet meer bewijzen dan alleen dat de bytes intact zijn.

• Herstel vanaf een derde machine, niet vanaf de bron, omdat u er juist vanuit gaat dat de bron verloren is gegaan. Dit betekent dat het wachtwoord van de repository of de PBS-sleutel bereikbaar moet zijn zonder de bron.
• Meet de tijd van het herstel en noteer deze, en vergelijk het resultaat vervolgens met de RTO die u heeft vastgesteld. De bovenstaande grafiek toont de ondergrens van de overdrachtssnelheid. Het werkelijke getal omvat ook het ontsleutelen en schrijven naar de schijf, plus de tijd die nodig is om te bepalen welke snapshot u nodig heeft.
• Herstel iets met een status, zoals een database-dump die u vervolgens in een testinstantie laadt. Een tar-bestand dat uitpakt is geen bewijs dat de applicatie ook daadwerkelijk opstart.

De goedkoopste schijf ter wereld is niets waard totdat u er ten minste één keer een herstel vanaf heeft uitgevoerd.

FAQ

Is een snapshot bij mijn VPS-provider een off-site backup?

Nee. Een snapshot van een provider bevindt zich in hetzelfde account, achter dezelfde inloggegevens van het paneel en op dezelfde factuur als de server waarvan deze een kopie is. Iedereen die toegang krijgt tot die inloggegevens, kan de server en elke bijbehorende snapshot in één sessie verwijderen. Snapshots zijn nuttig voor een snelle rollback vóór een risicovolle upgrade, maar ze vormen geen tweede locatie. Een off-site kopie bevindt zich onder een ander account, bij voorkeur bij een andere provider, met inloggegevens waarover de bronmachine niet beschikt.

Hoeveel schijfruimte heb ik nodig voor een maand aan bewaarde backups?

Baseer de grootte op de leeftijd van uw oudste snapshot in plaats van op het aantal snapshots. Een tool met deduplicatie slaat elk uniek blok één keer op, dus de repository is ongeveer even groot als de bron plus de nieuwe unieke data per dag vermenigvuldigd met het aantal dagen dat u de data bewaart. Voor 500 GB aan data die dagelijks met 5 GB wijzigt, is een week aan dagelijkse backups ongeveer 535 GB en een volledig jaar aan historie 2,325 GB. Koop extra ruimte als buffer, want een volle schijf zorgt voor het falen van de volgende backup, en de prune-functie van restic heeft vrije ruimte nodig om pack-bestanden opnieuw in te pakken voordat deze ruimte kan vrijgeven.

Kan een gecompromitteerde server zijn eigen off-site backups verwijderen?

Ja, tenzij u hiertegen maatregelen heeft genomen. Bij een standaard SSH- of SFTP-repository kan de sleutel die schrijft ook verwijderen. Geef de bron inloggegevens die geen data kunnen verwijderen: een PBS API-token met alleen de DatastoreBackup-rol, die niet beschikt over het Datastore.Prune-privilege, of gebruik restic tegen een rest-server die is gestart met --append-only, wat het verwijderen en wijzigen van bestaande backups weigert. Een pull-ontwerp gaat verder, omdat de bron dan helemaal geen inloggegevens voor de backup-host bezit. Voer het retentiebeleid uit vanaf de kant die niet de bron is.

Moet ik Proxmox Backup Server of restic draaien op de backup-VPS?

Stem de tool af op de eenheid die u wilt herstellen. Als de bron Proxmox VE is en u een volledige virtuele machine wilt terugzetten, gebruik dan PBS, omdat dit op het niveau van de schijf-image back-upt en een VM in één stap herstelt. Als de bron een Linux-host is en u bestanden en database-dumps wilt terugzetten, gebruik dan restic, waarvoor alleen een SSH-account op de doelmachine nodig is en dat versleutelt vóór verzending. Beide gebruiken is gebruikelijk: PBS voor de hypervisor, restic voor de servers die daar niet op draaien.

Hoe lang duurt een herstel vanaf een VPS-backup?

Deel de datagrootte door de verbindingssnelheid voor de ondergrens en tel daar de tijd voor ontsleuteling en schrijven bij op. 500 GB over een 100 Mbit/s-verbinding duurt 11.1 uur op lijnsnelheid, en hetzelfde herstel over een 1 Gbit/s-poort duurt 1.1 uur. Veel kleine bestanden werken trager dan deze rekensom vanwege de overhead per bestand. Meet één echt herstel en gebruik dat gemeten getal, want dat is het enige waar uw herstelplan op kan vertrouwen.