Storage-VPS: Grenzen bei IOPS und CPU verstehen

Was ein Storage-VPS nicht gut kann

Ein Storage-VPS ist eine große Festplatte mit einem kleinen Computer daran. Er verarbeitet große Dateien bei sequenziellen Zugriffen sehr gut. Bei Aufgaben mit vielen zufälligen Festplattenoperationen pro Sekunde oder mit dauerhaftem CPU-Bedarf ist er dagegen schlecht geeignet. Beide Grenzen ergeben sich direkt aus dem gebuchten Tarif.

Zwei Hardwarefakten bestimmen alles Weitere. Die IOPS (Input/Output-Operationen pro Sekunde) einer Festplatte mit rotierenden Magnetscheiben sind aus mechanischen Gründen auf deutlich unter 100 pro Laufwerk begrenzt, unabhängig von der Kapazität. Ein oder zwei gemeinsam genutzte vCPU (virtuelle Prozessorkerne) reichen aus, um Dateien bereitzustellen, aber für kaum mehr. Jede hier genannte Einschränkung lässt sich auf eine dieser beiden Zahlen zurückführen, meistens auf die erste.

Wenn Sie den Mechanismus verstehen, können Sie die Auswirkungen auf Ihre eigene Arbeitslast vorhersagen. Sie müssen sie dann nicht anhand einer Liste prüfen, die jemand anderes erstellt hat.

Die tatsächlich gekaufte Spezifikation

Im September 2026 sieht die Storage-Ausstattung bei einem deutschen Hoster fast überall ähnlich aus: ein oder zwei gemeinsam genutzte vCPU, einige Gigabyte RAM sowie Terabytes an Festplattenspeicher oder einem über das Netzwerk angebundenen Volume. Contabo verkauft dies als Storage VPS. netcup bindet große HDD-Volumes in seine Root-Server-Produktreihe ein. Hetzners Storage Box führt dieses Konzept weiter und entfernt den Computer vollständig: Sie erhalten SFTP, rsync over SSH, SMB und BorgBackup, jedoch keine Shell und keinen root-Zugriff. Prüfen Sie vor dem Kauf die aktuellen Tarifseiten, da sich die Zusammenstellung ändert.

Aus dieser Ausstattung ergeben sich vier Einschränkungen.

• Die Festplatte verarbeitet pro Spindel weniger als 100 zufällige Operationen pro Sekunde. Die Kapazität ändert daran nichts. Ein 20-TB-Laufwerk sucht genauso schnell wie ein 4-TB-Laufwerk.
• Das Prozessorbudget besteht aus einem oder zwei gemeinsam genutzten Kernen. Gemeinsam genutzt bedeutet, dass andere Mandanten um diese Kerne konkurrieren. Das zeigt sich als Steal Time. Steal Time auf einem ausgelasteten VPS auswerten zeigt Ihnen, wie viel Rechenleistung Ihres Kerns tatsächlich verfügbar ist.
• Der RAM ist begrenzt, daher cached der Kernel nur wenige Metadaten. Verzeichniseinträge und Inodes fallen aus dem Cache, während Sie den Verzeichnisbaum noch durchsuchen. Dadurch greifen dieselben Suchvorgänge erneut auf die Festplatte zu.
• Ein über das Netzwerk angebundenes Volume erhöht die Latenz jeder einzelnen Operation. Lange Warteschlangen können diese Latenz verdecken. Ein Prozess, der auf jeden Schreibvorgang wartet, hat keine Warteschlange.

Warum die Grenze bei Suchvorgängen wichtiger ist als die Terabyte

Eine Festplatte mit 7200 rpm wartet etwa 4.2 ms, bis sich der Platter in Position gedreht hat. Das entspricht einer halben Umdrehung. Für die durchschnittliche Suchbewegung des Schreib-Lese-Kopfs benötigt sie außerdem ungefähr 9 ms. Ein zufälliger Lesevorgang dauert daher etwa 13 ms. Eine einzelne Spindel verarbeitet somit weniger als 100 zufällige Operationen pro Sekunde. Für die folgenden Berechnungen setzen wir 80 an. Dieser Wert ergibt sich aus der Mechanik des Laufwerks. Ein größeres Modell verbessert ihn daher nicht.

Bei sequenziellen Zugriffen entfällt dieser Aufwand vollständig. Der Schreib-Lese-Kopf bleibt an seiner Position, während der Platter die Daten zuführt. Deshalb erreicht dasselbe Laufwerk beim sequenziellen Lesen deutlich mehr als 100 MB pro Sekunde. Aus diesem Grund kann ein einzelner Storage-VPS seine Netzwerkanbindung mit einer großen Datei auslasten und anschließend beim Durchlaufen eines Ordners mit kleinen Dateien stark langsamer werden. Der Unterschied liegt vollständig in der Bewegung des Schreib-Lese-Kopfs. Informationen zum Durchsatz desselben Plans finden Sie unter welche Festplattengeschwindigkeit Sie von einem Storage-VPS erwarten können.

Netzwerkbasierte Volumes verbergen die Mechanik, behalten aber dieselbe Grenze bei. Ihre Anfrage wird über ein Netzwerk an einen Storage-Cluster übertragen. Diese Round-Trip-Zeit fällt bei jeder Operation an. Mehrere gleichzeitig ausstehende Anfragen verteilen diesen Aufwand. Ein Single-Thread-Prozess, der nach jedem Schreibvorgang auf die Bestätigung wartet, profitiert davon nicht. Datenbanken arbeiten genau auf diese Weise. Der Unterschied zwischen lokalem NVMe und einem netzwerkbasierten Volume beruht daher hauptsächlich auf dieser Latenz, nicht auf der Bandbreite.

Warum eine Datenbank auf einem Storage-VPS langsam wird

Jede ernstzunehmende Datenbank bestätigt einen Schreibvorgang erst, wenn die Daten auf einem stabilen Speicher liegen. PostgreSQL hängt die Änderung an sein WAL (write-ahead log) an und ruft fdatasync auf, bevor es dem Client mitteilt, dass die Transaktion bestätigt wurde. MySQL mit InnoDB arbeitet genauso. Auf einer Festplatte kann diese Synchronisierung erst zurückkehren, wenn sich der Datenträger weitergedreht hat. Daher liegen dauerhafte Bestätigungen pro Sekunde im zweistelligen oder niedrigen dreistelligen Bereich. Das ist eine Hardwaregrenze. Keine Konfigurationsänderung kann sie anheben.

Auch Lesevorgänge sind betroffen. Eine Indexsuche, die den Cache verfehlt, ist ein zufälliger Lesevorgang. Bei 4 GB RAM passt der Arbeitssatz einer realen Datenbank nicht in den Speicher. Jeder Cache-Fehlzugriff erfordert eine Positionierung. Daher kann ein Abfrageplan, der auf 500 Zeilen zugreift, mehrere Sekunden dauern.

Sie sehen das an drei Stellen. iostat -x 1 aus dem Paket sysstat meldet %util, das nahe bei 100 liegt, während w_await im Bereich von mehreren Dutzend oder mehreren Hundert Millisekunden bleibt und der Wert für MB pro Sekunde sehr niedrig ist. PostgreSQL protokolliert checkpoints are occurring too frequently. Anwendungsseitige Timeouts treten schubweise statt gleichmäßig auf, weil ein Checkpoint geänderte Seiten schreibt und sich jeder Commit hinter diesem Schreibvorgang einreiht.

Messen Sie die Werte, statt darüber zu spekulieren. pg_test_fsync wird mit dem PostgreSQL-Serverpaket installiert und befindet sich unter /usr/lib/postgresql/16/bin/ auf Debian und Ubuntu. Dort ist 16 die Version, die Ubuntu 24.04 installiert. Das Tool meldet die Anzahl der Vorgänge pro Sekunde für jede vom System unterstützte Synchronisierungsmethode. Der beste dieser Werte ist Ihre Commit-Obergrenze.

sudo apt update && sudo apt install -y postgresql
/usr/lib/postgresql/16/bin/pg_test_fsync

Verbindungs-Pooling lohnt sich auf jedem kleinen Server. PgBouncer vor Postgres auf einem kleinen VPS einzusetzen spart tatsächlich Speicher, erzeugt aber keine IOPS. Wenn die Arbeitslast Schreibvorgänge umfasst, gehört die Datenbank auf eine NVMe-Maschine. Nur ihre Dumps gehören hierher.

Warum das Transcodieren einer Medienbibliothek ins Stocken gerät

Beim Transcodieren wird ein Video decodiert und anschließend erneut encodiert. Das beansprucht den Prozessor, während die Festplatte dabei nahezu ungenutzt bleibt. Mit zwei gemeinsam genutzten Kernen und Software-x264 läuft ein 1080p-Transcoding langsamer als in Echtzeit. ffmpeg gibt in seiner Fortschrittszeile ein Feld speed= aus. Ein Wert unter speed=1x bedeutet, dass der Encoder hinter dem Player zurückbleibt. Jellyfin und Plex zeigen dem Benutzer dann einen Buffering-Vorgang.

Hardware-Encoding ist normalerweise die passende Lösung, fehlt hier aber meist. Intel Quick Sync und VAAPI (Video Acceleration API) benötigen beide ein GPU-Gerät, das an den Gast weitergereicht wird. Ein Shared-Storage-Tarif stellt kein solches Gerät bereit. Führen Sie ls -l /dev/dri aus, bevor Sie Ihre Planung darauf ausrichten. Ein fehlendes oder leeres Verzeichnis bedeutet Software-Encoding. Damit ist die Anzahl der CPU-Kerne die obere Grenze.

Der erste Bibliotheksscan ist die zweite Überraschung. Er liest jede Datei, um Metadaten zu extrahieren, und schreibt für jedes Element ein Vorschaubild. Dadurch fallen gleichzeitig Prozessorarbeit und Schreibvorgänge für kleine Dateien an, und zwar auf dem System, das für beides am wenigsten geeignet ist. Direct Play ist das Gegenteil: Dabei wird eine einzelne große Datei sequenziell gelesen, was diese Hardware gut bewältigt. Welche Aufgaben eines Medienservers auf einem Storage-VPS tatsächlich funktionieren beschreibt diese Abgrenzung ausführlicher.

Warum Builds und Paketinstallationen die falsche Aufgabe sind

Kompilieren ist Prozessorarbeit mit einem stark metadatenlastigen Zugriffsmuster auf dem Datenträger. Ein C++-Build liest Tausende Header-Dateien und schreibt Tausende Objektdateien. npm install entpackt Hunderttausende kleine Dateien nach node_modules. Ein Docker-Build extrahiert Layer und erzeugt damit erneut dasselbe Zugriffsmuster. Jede dieser Dateien verursacht Metadatenoperationen. Auf einem System mit wenig RAM fallen die Verzeichniseinträge aus dem Cache, obwohl der Build sie weiterhin benötigt.

Das Speicherlimit greift häufig zuerst. Bei einem Tarif mit 4 GB RAM und ohne Swap überschreitet eine große Translation Unit das verfügbare Limit. dmesg protokolliert dann das Ergebnis:

Out of memory: Killed process 2231 (cc1plus) total-vm:2138744kB, anon-rss:1904512kB

Der Build wird anschließend mit einer verwirrenden Fehlermeldung des Compiler-Treibers beendet. Der untergeordnete Prozess wurde beendet, und der übergeordnete Prozess weiß nur, dass er verschwunden ist. Swap hält den Build am Laufen. Swap auf einer Festplatte mit rotierenden Magnetscheiben verwandelt Speichermangel in eine Folge von Suchoperationen. Dadurch wird der Build erst Stunden später fertig, statt sofort mit einem Fehler abzubrechen.

Warum rsync bei Millionen kleiner Dateien die ganze Nacht benötigt

rsync vergleicht beide Seiten, bevor Daten übertragen werden. Für jede Datei führt es auf der Quell- und auf der Zielseite einen stat-Aufruf aus. Das ist jeweils ein Metadatenzugriff. Wenn der Arbeitsspeicher die Verzeichnisdaten nicht aufnehmen kann, wird aus jedem stat-Aufruf, der nicht im Cache gefunden wird, ein Suchvorgang. Der Lauf wird dann durch die Dateianzahl begrenzt, nicht durch die Datenmenge.

[
  {
    "label": "100,000 files",
    "duration_h": 0.3
  },
  {
    "label": "500,000 files",
    "duration_h": 1.7
  },
  {
    "label": "1,000,000 files",
    "duration_h": 3.5
  },
  {
    "label": "5,000,000 files",
    "duration_h": 17.4
  }
]

Die Rechnung ist unerbittlich. Bereits 100,000 Dateien kosten 0.3 Stunden, davon ungefähr zwanzig Minuten reine Kopfbewegung. Eine Million Dateien benötigt 3.5 Stunden zum Durchlaufen. Fünf Millionen Dateien, wie sie in einem gewöhnlichen Mail-Speicher oder Fotoarchiv vorkommen, verursachen 17.4 Stunden Suchzeit. Das ist die Mindestdauer des Laufs, unabhängig davon, wie schnell Ihr Netzwerk ist.

Diese Werte sind aus der oben genannten Zahl von 80 IOPS abgeleitete Obergrenzen und keine Messungen eines bestimmten Tarifs. Caching hilft beim zweiten Durchlauf. Ein Netzwerk-Volume verhält sich anders. Entscheidend ist die Größenordnung: Verdoppeln Sie die Dateianzahl, verdoppelt sich die Laufzeit. Eine Verdopplung der Dateigröße kostet dagegen fast nichts.

Ändern Sie daher die Struktur der Daten. Backup-Tools, die ihre Eingabedaten bündeln, schreiben einige wenige große Container statt Millionen kleiner Dateien. BorgBackup und restic speichern Chunks in großen Segmentdateien. Dadurch wird eine Quelle mit einer Million Dateien auf dem Ziel zu einem sequenziellen Schreibdatenstrom. tar über SSH weitergeleitet, erreicht bei einer einmaligen Kopie dasselbe. Wenn Sie plain rsync verwenden müssen, fügen Sie niemals --checksum hinzu: Dadurch werden auf beiden Seiten alle Bytes gelesen und aus einem Metadatenproblem ein vollständiger Lesevorgang für beide Verzeichnisbäume.

Dieselbe Regel gilt für Aufgaben, die Sie nicht als Kopiervorgänge betrachtet haben. du -sh auf einem großen Verzeichnisbaum, der Neuaufbau des Index durch einen Mailserver und ein ZFS-Scrub, das den gesamten Pool liest, durchlaufen alle dieselbe Struktur. Planen Sie dafür ein Zeitfenster ein, in dem keine anderen Aufgaben die Festplatte benötigen. Scrubs auf kleinen Pools planen bedeutet hauptsächlich, den Lauf nicht mit dem Backup zu überschneiden.

Wofür ein Storage-VPS tatsächlich geeignet ist

Dieselbe Hardware eignet sich hervorragend für Aufgaben, die zu ihren Eigenschaften passen.

• Backup-Ziele. Borg und restic schreiben große Dateien sequenziell. Das gilt auch für Datenbank-Dumps. Einen VPS als Offsite-Backup-Ziel verwenden ist der Anwendungsfall, für den diese Hardware ausgelegt ist.
• Mediatheken, die von einem anderen Rechner transkodiert werden. Speichern Sie die Dateien hier und lassen Sie eine kleine NVMe-Box die Kodierung über das Netzwerk übernehmen.
• Archive und selten benötigte Daten. Die Daten werden einmal geschrieben, selten gelesen und beim Lesen gestreamt. Die Bewegung der Schreib-/Leseköpfe bleibt nahezu aus.
• Verteilung großer Datenmengen. Das Bereitstellen großer Downloads und das Seeding lasten die Netzwerkverbindung aus, ohne dass viele Suchvorgänge erforderlich sind.
• Eine zweite Kopie innerhalb der EU. Datenresidenz und ihre Kosten sind häufig überhaupt der Grund für den Kauf. Die Optionen deutscher Anbieter sind die günstigste Möglichkeit, diese Kopie zu speichern.

Rechenleistung auf einem kleinen VPS, Daten auf dem großen

Das Muster, das die meisten der oben genannten Probleme behebt, lässt sich in einem Satz zusammenfassen: Die Verarbeitung läuft auf einem kleinen, schnellen VPS, die Daten liegen auf dem Storage-Server. Der Unterschied zwischen einem Storage-VPS und einem regulären VPS entspricht genau dem Unterschied zwischen diesen beiden Hälften. Einen Storage-VPS mit dem Haupt-VPS zu verbinden ist die dafür erforderliche Einrichtung.

Verbinden Sie die Systeme auf eine von zwei Arten. Binden Sie den Storage über ein privates Netzwerk mit NFS (Network File System) oder SSHFS ein. Alternativ verzichten Sie auf den Mount und replizieren die Daten regelmäßig mit Borg oder rsync. Replikation ist die robustere Variante. Bei einem Mount wird nämlich jeder kurze Ausfall des Storage zu einem Anwendungsfehler. Eine geplante Kopie läuft dagegen lediglich verspätet und wird erneut ausgeführt.

Zwei Regeln sorgen dafür, dass diese Aufteilung funktioniert. Legen Sie niemals ein Datenverzeichnis einer Datenbank oder ein Docker-overlay2-Verzeichnis auf dem Remote-Mount ab. Beide verursachen die oben beschriebenen zugriffsintensiven Muster, zusätzlich mit der Latenz des Netzwerks. Halten Sie außerdem Caches und Sitzungsdaten auf der lokalen Festplatte. Sie sind klein, werden ständig neu geschrieben, und ihr Verlust verursacht keine Probleme.

SQLite über NFS erfordert eine eigene Warnung. Die Sperrung basiert auf Dateisperren, die von Netzwerkdateisystemen uneinheitlich implementiert werden. Der Fehler zeigt sich als database is locked oder disk I/O error, manchmal auch als unbemerkte Beschädigung. Alles, was eine eingebettete Datenbank verwendet, sollte diese Datei auf der lokalen Festplatte speichern. Nextcloud auf einem VPS ist direkt davon betroffen, weil die Datenbank und der Dateiscanner die Metadaten verarbeiten, während die Dateien selbst den einfachen Teil darstellen.

Verschlüsselung gehört auf Daten, die Ihren Kontrollbereich verlassen. Sie benötigt jedoch Prozessorzeit auf einem Server, dessen Reserven begrenzt sind. Prüfen Sie zuerst mit grep -m1 -o aes /proc/cpuinfo, ob Hardwareunterstützung für AES verfügbar ist. Die Ausgabe von aes bedeutet, dass die zusätzlichen Kosten gering sind. Ohne Ausgabe fällt die zusätzliche Last auf diese ein oder zwei Kerne. Welche Auswirkungen AES-NI auf einen VPS hat erklärt diesen Unterschied. Daten auf einem Storage-VPS verschlüsseln beschreibt die Einrichtung.

Wenn Ihre Antwort auf all das lautet, dass Sie die Hardware in Ihrem eigenen Gebäude benötigen, ist ein NAS zu Hause im Vergleich zu einem Storage-VPS die realistische Darstellung dieses Kompromisses. Dazu gehört auch die Upload-Geschwindigkeit, auf die Sie begrenzt wären.

Die eine Messung, die Sie vor der Entscheidung durchführen sollten

Führen Sie diesen Test mit einem Trial-Plan oder innerhalb der ersten Stunde nach dem Kauf durch, bevor Sie etwas migrieren. Der Test, der die meisten Ausfälle vorhersagt, ist ein synchroner 4k-Schreibtest. Genau das macht ein Datenbank-Commit. Außerdem kann sich dieses Zugriffsmuster nicht durch Caching verborgen halten.

sudo apt update && sudo apt install -y fio
fio --name=commit --filename=/mnt/storage/fio-test --size=1G \
  --rw=write --bs=4k --ioengine=sync --fdatasync=1 \
  --runtime=60 --time_based --group_reporting
rm -f /mnt/storage/fio-test

Lesen Sie 2 Werte aus der Ausgabe ab. Die Zeile write: IOPS= zeigt, wie viele dauerhafte 4k-Schreibvorgänge pro Sekunde das Volume verarbeitet. Der Block fsync/fdatasync/sync_file_range: darunter enthält die Latenz jedes synchronen Schreibvorgangs einschließlich des 99. Perzentils. Diese Latenz entspricht ungefähr dem, was Ihre langsamsten Transaktionen erleben.

Interpretieren Sie das Ergebnis in der Reihenfolge, in der Sie auf die Werte treffen. Ein Ergebnis im zweistelligen Bereich bedeutet, dass der Plan als Write-Once-Speicher ausgelegt ist. Als Backup-Ziel ist er geeignet, unter einer Datenbank jedoch unbrauchbar. Einige hundert Vorgänge bedeuten meist eine normale Festplatte mit einem vorgeschalteten Schreib-Cache. Mehrere tausend Vorgänge bedeuten, dass das Volume auf SSD-Speicher basiert. Dann ist eher der Prozessor der limitierende Faktor und nicht das Laufwerk.

Führen Sie für die andere Hälfte des Bildes dasselbe Tool mit sequenziellen Zugriffen aus. Prüfen Sie, ob der Plan seine Netzwerkverbindung auslasten kann.

fio --name=seq --filename=/mnt/storage/fio-test --size=4G \
  --rw=write --bs=1M --ioengine=libaio --iodepth=8 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f /mnt/storage/fio-test

Wenn der Test mit fio: looks like your file system does not support direct=1/buffered=0 abbricht, unterstützt das Dateisystem keine ungepufferten I/O-Vorgänge. Das ist bei Netzwerk-Volumes häufig der Fall. Entfernen Sie --direct=1 und fügen Sie stattdessen --end_fsync=1 hinzu. Dann berücksichtigt das Ergebnis den Flush, statt den Page-Cache zu messen.

Es gibt auch einen zehn Sekunden langen Plausibilitätstest. Installieren Sie ioping. Anschließend gibt ioping -c 20 /mnt/storage die Latenz jedes Requests aus, und ioping -R /mnt/storage führt einen Seek-Rate-Test durch. Das Ergebnis wird in Vorgängen pro Sekunde angegeben. Eine Seek-Rate nahe 80 bestätigt, dass Ihnen eine einzelne rotierende Festplatte zur Verfügung steht.

Auf eine Prüfung verlassen sich viele zu sehr: lsblk -d -o name,rota,size kennzeichnet rotierende Geräte in der Spalte ROTA mit 1. Unter virtio wird dieses Flag bei einer rotierenden Festplatte jedoch häufig trotzdem als 0 gemeldet. Betrachten Sie es daher nur als Hinweis und lassen Sie fio entscheiden. Ermitteln Sie zunächst wie viel Speicher Sie tatsächlich benötigen und gehen Sie einmal die Checkliste für den Kauf eines Storage-VPS durch. Zusätzliche Kapazität lässt sich später einfach bereitstellen, die Form der Workload jedoch nicht.

FAQ

Kann ich eine Datenbank auf einem Storage-VPS betreiben?

Nur eine Datenbank mit geringer Schreiblast. Jede festgeschriebene Transaktion endet mit einem fdatasync. Bei einer Festplatte wartet die Synchronisierung auf die Positionierung der Platter. Daher liegen dauerhaft mögliche Commits pro Sekunde im zweistelligen oder niedrigen dreistelligen Bereich. Messen Sie den Wert mit pg_test_fsync oder mit dem oben genannten fio-Befehl, bevor Sie sich entscheiden. Eine kleine, überwiegend lesende Datenbank, deren Working Set in den RAM passt, läuft problemlos. Alles, was kontinuierlich schreibt, gehört auf einen NVMe-VPS. Speichern Sie nur die Dumps auf der großen Festplatte.

Warum puffert mein Medienserver auf einem Storage-VPS?

Weil er Transkodierung durchführt. Das ist Prozessorarbeit und keine Festplattenarbeit. Überwachen Sie die Fortschrittszeile ffmpeg. Ein speed=-Wert unter 1x bedeutet, dass der Encoder mit der Wiedergabe nicht Schritt halten kann. Dadurch leert sich der Puffer des Players. Prüfen Sie ls -l /dev/dri auf einen Hardware-Encoder. Bei einem Shared-Tarif ist dieser wahrscheinlich nicht verfügbar. Speichern Sie die Mediathek hier und führen Sie die Transkodierung auf einem anderen Rechner durch. Alternativ können Sie Formate verwenden, die der Client direkt wiedergibt.

Ist eine Hetzner Storage Box dasselbe wie ein Storage-VPS?

Nein. Eine Storage Box bietet nur Protokollzugriff über SFTP, rsync, SMB und BorgBackup. Es gibt keine Shell und keinen root-Zugriff. Daher können Sie darauf keine eigene Software ausführen. Ein Storage-VPS ist ein echter Linux-Rechner, den Sie administrieren. Wählen Sie die Box, wenn Sie nur ein Ziel für Backups benötigen. Wählen Sie den VPS, wenn neben den Daten etwas ausgeführt werden muss. Der Vergleich zwischen Storage-VPS und verwalteter Storage Box erläutert die Details.

Wie kann ich Millionen kleiner Dateien am schnellsten auf einen Storage-VPS kopieren?

Kopieren Sie sie nicht als einzelne Dateien. BorgBackup und restic packen ihre Eingabedaten in große Segmentdateien. Das Ziel sieht dadurch einen sequenziellen Schreibdatenstrom statt Millionen von Metadatenoperationen. tar über SSH weiterzuleiten, bewirkt bei einer einzelnen Kopie dasselbe. Wenn Sie rsync verwenden müssen, lassen Sie --checksum deaktiviert. Rechnen Sie damit, dass der erste Verzeichnisdurchlauf durch die Dateianzahl und nicht durch die Bandbreite begrenzt wird.

Wie erkenne ich, ob mein Tarif auf HDD oder SSD basiert?

lsblk -d -o name,rota,size zeigt bei rotierenden Geräten in der Spalte ROTA den Wert 1 an. Bei virtio wird für eine rotierende Festplatte jedoch häufig 0 gemeldet. Daher liefert das Flag allein keinen sicheren Nachweis. Messen Sie stattdessen. Ein 4k-Test für synchrone Schreibvorgänge, der zweistellige IOPS-Werte bei einer Synchronisierungslatenz von mehreren Millisekunden liefert, weist auf eine Festplatte hin. Mehrere tausend IOPS bei einer Latenz von weniger als einer Millisekunde weisen auf Flash-Speicher hin. Gegen diese gemessene Zahl sollten Sie planen.