Verschil tussen storage VPS en reguliere VPS uitgelegd

Storage VPS versus reguliere VPS: het korte antwoord

Een storage VPS is een virtual private server die per terabyte wordt verkocht, terwijl een reguliere VPS per core wordt verkocht. Het storage-abonnement biedt u enkele terabytes aan trage schijfruimte met een beperkte CPU-capaciteit. Het standaardabonnement biedt een snelle NVMe-schijf (non-volatile memory express) die vaak twintig keer kleiner is, aangevuld met meer processorcapaciteit en meer geheugen voor hetzelfde bedrag. Alle overige aspecten van beide producten zijn identiek: dezelfde hypervisor, dezelfde root shell, dezelfde Ubuntu-image en dezelfde netwerkstack.

Dat ene verschil bepaalt de geschiktheid. Een storage VPS is geschikt voor back-updoelen, mediabibliotheken, koude archieven en alles wat u eenmalig schrijft en zelden leest. Het is ongeschikt voor een database of voor elke pagina waar een gebruiker op moet wachten, omdat dergelijke workloads kleine willekeurige leesacties vereisen die binnen ongeveer een milliseconde voltooid moeten zijn. Goedkope capaciteit is juist goedkoop omdat deze niet aan die eis kan voldoen.

De plannamen die u tegenkomt op een prijspagina

Vier labels dekken vrijwel elke provider, en slechts twee daarvan hebben een specifieke betekenis.

• Standard VPS. Twee tot acht vCPU, 2 GB tot 32 GB RAM, en 20 GB tot 400 GB NVMe of SATA SSD die zich op de host-node zelf bevindt.
• Storage VPS. 1 TB tot 20 TB of meer, meestal draaiende SATA-schijven of SATA SSD's met hoge capaciteit, met één tot vier gedeelde vCPU's en een bescheiden hoeveelheid RAM. Dit kost per maand vaak hetzelfde als een klein standaardabonnement.
• VDS. Afkorting voor virtual dedicated server. Er is geen gedeelde definitie voor dit woord; de onderstaande sectie beschrijft waar u in plaats daarvan op moet letten.
• Block storage volume. Geen abonnement, maar een via het netwerk gekoppelde schijf die u toevoegt aan een bestaande VPS en waarvoor u per GB per maand betaalt. Dit is de enige van de vier die u kunt vergroten zonder de server te verplaatsen.

Deze bereiken vormen de gangbare standaard in de markt, niet het aanbod van één specifiek bedrijf. Het label op het abonnement is een categorie; het geeft bij benadering aan op welk chassis uw server draait. Het zegt niets over het schijftype, het CPU-toewijzingsbeleid of de bandbreedtetoewijzing, en dat zijn precies de factoren die bepalen of uw workload goed presteert.

Wat verandert er daadwerkelijk tussen de twee abonnementen

Schijftype en -hoeveelheid. Dit is het enige productverschil. Een standaardabonnement maakt gebruik van NVMe-flash die via de PCI Express-bus wordt aangestuurd. Een opslagabonnement maakt gebruik van een grote array van draaiende schijven of SATA SSD's met een hoge capaciteit. Als u niet zeker weet welke van deze termen voor u relevant is, begin dan bij wat een SSD VPS is en hoe deze verschilt van oudere schijfabonnementen en daarna het praktische verschil tussen NVMe en SATA SSD.

CPU-verhouding. Opslagabonnementen hebben minder vCPU's per terabyte, en deze vCPU's worden bijna altijd gedeeld met andere huurders. Dat is geen gebrek. Een back-updoel brengt zijn tijd door met wachten op het netwerk, dus heeft het geen rekenkernen nodig.

RAM. Opslagabonnementen hebben relatief weinig RAM voor hun prijs. Dit is op één specifiek punt merkbaar: bestandssysteem-metadata. Miljoenen kleine bestanden hebben geheugen nodig voor de directory- en inode-cache; zonder dit geheugen moet elke lijstweergave terugvallen op de schijf.

Netwerktoewijzing. Lees deze regel zorgvuldig bij een opslagabonnement. Capaciteit waarvan u niet kunt herstellen, is geen back-up. Controleer de maandelijkse overdrachtslimiet in TB en de poortsnelheid in Gbit/s, want een volledig herstel van 4 TB via een 1 Gbit/s-poort duurt ongeveer negen uur bij maximale lijnsnelheid, en aanzienlijk langer als de poort wordt gedeeld.

[
  {
    "plan": "Storage VPS, HDD",
    "usd_per_tb_month": 3
  },
  {
    "plan": "Storage VPS, SATA SSD",
    "usd_per_tb_month": 9
  },
  {
    "plan": "Standard VPS, NVMe",
    "usd_per_tb_month": 40
  },
  {
    "plan": "Block storage add-on",
    "usd_per_tb_month": 90
  }
]

Dit zijn afgeronde cijfers afkomstig van openbare prijspagina's van verschillende aanbieders in augustus 2026; het is geen offerte van één specifiek bedrijf en deze prijzen veranderen. De verhouding is wat constant blijft. Een terabyte op een opslagabonnement met draaiende schijven kost ongeveer 3 Amerikaanse dollar per maand. Dezelfde terabyte aan NVMe op een standaardabonnement kost ongeveer 40, en een netwerkgekoppeld block volume is de duurste van de 4 opties met 90. Voor een breder overzicht van waaruit de maandelijkse factuur is opgebouwd, zie wat een VPS daadwerkelijk per maand kost.

Waarom de prijs per TB en de prijs per core tegengesteld bewegen

Een storage node is een behuizing met twaalf tot zestien grote schijven en één bescheiden processor. Een compute node is het tegenovergestelde: veel cores, veel RAM en twee of vier NVMe-schijven. De provider verkoopt de overcapaciteit van het betreffende chassis. Een abonnement dat goedkoop is per terabyte, is daarom duur per core, en een abonnement dat goedkoop is per core, is duur per terabyte. Er bestaat geen abonnement dat op beide vlakken goedkoop is, omdat er geen chassis bestaat dat zo is ontworpen.

Dit is de reden waarom het eerlijke antwoord op de vraag "welke moet ik kopen" vaak "beide" is. Een kleine NVMe VPS voor de applicatie, plus een storage VPS voor de back-ups, kost minder dan één machine die groot genoeg is om beide taken goed uit te voeren. Wanneer één machine echt beide taken moet uitvoeren, verlaat u het VPS-domein: zie wanneer een dedicated server beter is dan een VPS.

Willekeurige leesacties zijn waar een goedkope schijf niet tegen opgewassen is

[
  {
    "disk": "7200 rpm SATA HDD",
    "random_read_iops": "180",
    "typical_latency_ms": 8.5
  },
  {
    "disk": "SATA SSD",
    "random_read_iops": "75,000",
    "typical_latency_ms": 0.2
  },
  {
    "disk": "NVMe SSD",
    "random_read_iops": "600,000",
    "typical_latency_ms": 0.08
  }
]

Dit zijn cijfers uit datasheets en geen benchmarks van een specifieke provider. Een schijf van 7200 rpm verwerkt ongeveer 180 willekeurige 4k-leesacties per seconde, omdat de leesarm fysiek naar het spoor moet bewegen en vervolgens moet wachten tot de schijfplaat de sector onder de kop brengt. Dit kost telkens ongeveer 8.5 ms. Flash heeft geen bewegende onderdelen, waardoor een SATA SSD ongeveer 75,000 IOPS haalt en een NVMe-apparaat ongeveer 600,000 IOPS bij 0.08 ms. Dat is een verschil van meer dan drieduizend keer, en geen enkele hoeveelheid RAM of CPU kan dat overbruggen.

Sequentieel werk is een compleet ander verhaal, en dat is precies waarom opslagplannen überhaupt nuttig zijn. Een enkele draaiende schijf streamt nog steeds 150 MB/s tot 250 MB/s, en een array van deze schijven streamt nog meer. Dat verzadigt een 1 Gbit/s-poort, waardoor een back-upupload op volledige netwerksnelheid verloopt en de schijf nooit de beperkende factor is. Uw cijfers hangen ook af van hoe de array is opgebouwd, aangezien striping één verzoek spreidt over meerdere schijven: hoe RAID 10 de prestaties van opslagplannen verandert behandelt dit onderwerp.

Wat betekent VDS?

Meestal is dit een marketingterm. Er zijn drie gangbare betekenissen en de provider geeft zelden aan welke van toepassing is. Sommige providers gebruiken VDS voor toegewezen of dedicated CPU-cores, zodat er geen andere huurder is die uw rekenkracht verbruikt. Anderen gebruiken het voor volledige virtualisatie zoals KVM, in tegenstelling tot containervirtualisatie zoals LXC of OpenVZ waarbij u de kernel van de host deelt. Weer anderen gebruiken het enkel als een naam die krachtiger klinkt dan VPS.

U kunt een deel hiervan vaststellen vanuit de server zelf. systemd-detect-virt geeft kvm weer op een volledige virtuele machine en lxc op een container; een container betekent dat u geen kernelmodules kunt laden of uw eigen kernel kunt draaien. De claim over dedicated CPU-cores moet u zelf meten, door gebruik te maken van de controle op steal time verderop in dit document. Beschouw de letters in het abonnement als een aanwijzing en de specificaties als het contract.

Welke specificatieregels u moet controleren in plaats van de naam

• Het woord dat naast de capaciteit staat: NVMe, SSD, SATA of HDD. Als er nergens op de pagina een woord voor de schijf staat, ga dan uit van de goedkoopste hardware die binnen de prijs valt.
• Of de schijf lokaal is aan de node of via het netwerk is gekoppeld. Netwerkopslag voegt latentie toe aan elk verzoek en blijft beschikbaar bij een node-storing. Lokale schijven zijn sneller, maar gaan verloren als de node uitvalt.
• De bewoording voor de CPU: "dedicated" of "pinned" versus "shared", "fair share" of helemaal geen vermelding.
• Elke IOPS- of MB/s-limiet die in het abonnement is opgenomen. Een limiet van 500 IOPS maakt het type schijf vrijwel irrelevant.
• De maandelijkse datalimiet en poortsnelheid, die bepalen hoe lang een volledige restore duurt.
• Of snapshots, back-ups en extra IP-adressen zijn inbegrepen of apart worden gefactureerd.

Hoe u controleert welke schijf u daadwerkelijk heeft ontvangen

Begin bij wat de kernel rapporteert, maar vertrouw er daarna niet meer op.

lsblk -d -o NAME,ROTA,SIZE,MODEL
df -h /
nproc
free -h

ROTA is 1 voor een roterend apparaat en 0 voor flashgeheugen. Vertrouw hier niet op binnen een VPS: een virtio-schijf rapporteert meestal ROTA=0, ongeacht wat erachter zit, omdat de hypervisor een generiek blokapparaat presenteert en de gastmachine de fysieke schijf nooit ziet. MODEL is om dezelfde reden leeg. De vlag beschrijft wat de hypervisor heeft gedeclareerd, niet wat er daadwerkelijk in het rack draait; voer daarom metingen uit.

sudo apt update && sudo apt install -y fio
fio --name=randread --filename=/var/tmp/fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.test

--direct=1 omzeilt de page cache, zodat u de schijf meet in plaats van het RAM-geheugen. De relevante regel om te lezen is read: IOPS=, met de verdeling onder clat percentiles (usec) daaronder. Een standaard NVMe-abonnement rapporteert tienduizenden IOPS met een 99e percentiel onder één milliseconde. Een abonnement met roterende opslag rapporteert enkele honderden IOPS met een 99e percentiel in de dubbele cijfers (milliseconden). Als fio meldt dat de libaio-engine niet kan worden geladen, gebruik dan --ioengine=psync --iodepth=1 en houd rekening met lagere cijfers, omdat die engine verzoeken één voor één verwerkt.

vmstat 1 5
sudo apt install -y sysstat
iostat -x 1 5

In vmstat is de kolom st de steal time: het aandeel van de tijd dat uw vCPU klaar was om te draaien, terwijl de host die cycli aan een andere gastmachine gaf. Een constant cijfer boven 5 betekent dat de node overboekt is; dit is de echte test voor een claim van een "dedicated CPU". Houd in iostat -x de waarden %util, r_await en w_await in de gaten. Een %util nabij 100 met w_await in de tientallen milliseconden betekent dat de schijf de bottleneck is en dat optimalisatie van applicaties niet zal helpen. Voor specifieke controles van flashgeheugen gaat verifiëren of een NVMe-schijf echt NVMe is dieper in op de materie.

Keuze op basis van workload

• Back-updoel voor restic, Borg of rsync. Storage VPS, en dit is het scenario waarvoor deze is ontworpen. Schrijfacties zijn groot en sequentieel, deduplicatie vindt plaats op de bronmachine en er is geen proces dat op het resultaat wacht. Eén kanttekening: restic prune en restic check --read-data lezen het volledige repository in kleine stukjes, dus plan hier uren voor in en voer ze uit volgens een schema. Zie restic back-ups uitvoeren naar een VPS.
• Immich of Jellyfin mediabibliotheek. Storage VPS voor de bestanden, met een waarschuwing wat betreft de CPU. Immich genereert miniaturen en voert machine learning-taken uit bij het importeren, en Jellyfin transcodeert tijdens het afspelen. Twee gedeelde vCPU's zullen erg traag zijn bij de eerste import van 200 GB aan foto's. Houd de database en de thumbnail-cache op de snelste schijf in de server. Immich zelf hosten als vervanging voor Google Photos behandelt de dimensionering.
• PostgreSQL of MySQL. Standaard NVMe-plan. Elke commit eindigt in een fsync die de duurzame opslag moet bereiken voordat de transactie wordt voltooid. De commit-latentie is dus gelijk aan de schijflatentie, en een index-lookup is een willekeurige 8 kB-leesactie van precies het type waar een draaiende schijf het slechtst in presteert.
• Webapplicatie, API of control plane. Standaardplan. Deze hebben rekenkracht en voorspelbare latentie nodig, en hebben zelden meer dan 100 GB nodig.
• CI-cache of artifact store. Dit hangt af van de bestandsgrootte. Grote tarballs streamen vanaf een opslagplan op volledige netwerksnelheid. Een cache van honderdduizenden kleine bestanden, die parallel door meerdere runners worden opgehaald, is in feite willekeurige IO en zal tegenvallen.

Hoe het eruitziet als u dit verkeerd aanpakt

Het falen gebeurt nooit direct. Een database op een opslagplan met draaiende schijven voelt prima aan bij één gebruiker, maar stort in onder tien gebruikers. Queries die voorheen in het RAM pasten, moeten nu naar de schijf worden geschreven; elke query kost nu milliseconden in plaats van microseconden. De load average stijgt, terwijl top laat zien dat de CPU grotendeels inactief is met een hoog %wa-cijfer. Dit betekent dat processen geblokkeerd zijn door het wachten op de schijf in plaats van dat ze berekeningen uitvoeren. iostat -x 1 toont %util op bijna 100.

PostgreSQL meldt dit duidelijk in het eigen logbestand, aangezien log_checkpoints vanaf versie 15 standaard is ingeschakeld:

LOG:  checkpoint complete: wrote 8241 buffers (2.5%); ... write=112.402 s, sync=9.318 s, total=121.914 s

Het sync=-cijfer is het cijfer dat ertoe doet. Dit is de tijd die het checkpoint heeft gewacht tot fsync reageerde. Een waarde in seconden betekent dat de schijf schrijfacties niet zo snel kan verwerken als de database ze genereert. Clientverbindingen lopen vast tijdens dat venster, ook al is de query zelf niet zwaar. De oplossing is geen configuratiewijziging. Verplaats de datadirectory naar NVMe en gebruik het opslagplan waarvoor het geschikt is: het bewaren van de back-ups van die database.

FAQ

Is een storage VPS trager dan een reguliere VPS?

Voor willekeurige lees- en schrijfacties wel, en aanzienlijk. Een storage-plan met draaiende schijven verwerkt enkele honderden kleine willekeurige verzoeken per seconde met een latentie van ongeveer 8 ms per stuk, terwijl een NVMe-plan er tienduizenden verwerkt in ruim onder 1 ms. Voor sequentiële overdrachten liggen de twee dichter bij elkaar, omdat een storage-array nog steeds 150 MB/s of meer streamt, wat voldoende is om een 1 Gbit/s-poort te verzadigen. Meet uw eigen prestaties met fio --rw=randread --bs=4k --direct=1 voordat u een besluit neemt.

Kan ik PostgreSQL draaien op een storage VPS?

U kunt het starten en het zal werken totdat de actieve dataset niet meer in het RAM-geheugen past. Daarna wacht elke commit op een fsync op een trage schijf, en Postgres logt dit als een sync=-waarde in seconden binnen checkpoint complete, terwijl iostat -x 1 een %util nabij 100 toont met een hoge w_await. De gebruikelijke opzet is een kleine NVMe VPS voor de database en een storage VPS als doel voor de back-updumps.

Betekent VDS dat ik dedicated hardware krijg?

Niet betrouwbaar. VDS heeft geen standaardbetekenis. Sommige providers gebruiken het voor vastgezette CPU-cores, sommige voor volledige KVM-virtualisatie in plaats van een gedeelde kernel-container, en sommige gebruiken het puur als marketingnaam. Voer systemd-detect-virt uit om te zien of u op kvm of lxc zit, en voer vmstat 1 5 uit en bekijk de st-kolom om te zien of andere huurders uw CPU-cycli in beslag nemen.

Hoe stel ik vast of mijn VPS-schijf echt NVMe is?

Vertrouw niet op lsblk -d -o NAME,ROTA,MODEL, omdat een virtio-schijf normaal gesproken ROTA=0 en een lege modelnaam rapporteert, ongeacht welke hardware eronder ligt. Voer een willekeurige leestest van 30 seconden uit met fio via --direct=1 en lees de IOPS en de 99e percentiel-latentie af. Honderden IOPS met een latentie in de dubbele cijfers in milliseconden duidt op een array met draaiende schijven. Tienduizenden IOPS in minder dan een milliseconde duidt op flash-opslag.