Backup eines KI-Servers: was einmalig ist, was sich neu aufbauen lässt und wie Sie beweisen, dass die Wiederherstellung funktioniert
- Llama 3.3 70B umfasst in NVIDIAs FP8-Checkpoint 15 Dateien und 72,7 GB auf Hugging Face; ein erneuter Download stellt es nur wieder her, solange diese Revision existiert, und die Autoren eines zugangsbeschränkten Modells wie Metas Original können den Zugang jederzeit ohne vorherige Ankündigung sperren
- Ein LoRA-Adapter mit Rang 16 auf jeder Attention- und MLP-Projektion von Llama 3.3 70B hat 207,1 Millionen Parameter, 828 MB in FP32, nach unserer Rechnung; er existiert nirgendwo sonst, und NVIDIAs veröffentlichter Content-Safety-Adapter lässt sein Feld für die Basisrevision auf
null - Vektorspeicher brauchen ihre eigene konsistente Kopie: pg_dump oder pg_basebackup mit WAL-Archivierung für pgvector, ein Snapshot je Collection und Knoten für Qdrant, Milvus Backup für Milvus, dessen Tabelle Wiederherstellungen nur in Version 2.4 bis Version 2.6 aufführt
- Von einer laufenden VM mit einer GPU im Passthrough lässt sich kein Snapshot erstellen: vSphere 9.0 führt Snapshots mit DirectPath I/O als nicht verfügbar, und Broadcom zufolge gelingen sie nur bei einer ausgeschalteten VM, sodass laufende VMs einen Agenten im Gastsystem und Backups auf Anwendungsebene brauchen
- Ein Wiederherstellungstest für KI umfasst drei Prüfungen: die SHA-256-Werte jeder Gewichtsdatei, ein festes Evaluierungsset mit akzeptierten Antworten und die Top-Treffer fester Abfragen; die Einstellungen von vLLM für Reproduzierbarkeit greifen nur auf derselben Hardware und Version
Was auf einem KI-Server liegt
Auf einem KI-Server liegen drei Arten von Daten: Dateien, die sich erneut herunterladen lassen, Dateien, die nirgendwo sonst existieren, und Datenbanken, die nur auf Anforderung eine konsistente Kopie liefern.
| WAS DORT LIEGT | EINMALIG? | NEUAUFBAU KOSTET | SO SCHÜTZEN SIE ES |
|---|---|---|---|
| Gewichte des Basismodells | nein, solange die Revision veröffentlicht ist | einen Download, sofern Zugang und Lizenz noch bestehen | Commit pinnen; eigene Kopie mit Prüfsummen |
| LoRA-Adapter | ja | einen neuen Trainingslauf | mit Konfiguration, Daten und Basisrevision sichern |
| Gewichte, volles Fine-Tuning | ja | den vollständigen Trainingslauf | jeden Checkpoint sichern, den Sie im Serving nutzen |
| Trainings-/Evaluierungsdaten | ja | oft unmöglich | versionierte Kopien, zuerst das Evaluierungsset |
| Vektorindex | nein, solange Quellen und Modell erhalten bleiben | alles neu parsen und neu einbetten | das eigene konsistente Backup des Vektorspeichers |
| Quelldokumente und Rechte | nein, sie liegen in den Quellsystemen | erneutes Einlesen und einen neuen Abgleich der Rechte | den Stand des Einlesens sichern |
| Serving- und Pipeline-Konfig | ja | Rekonstruktion aus dem Gedächtnis | git, mit gepinnten Revisionen |
| Container-Images | ja, wenn selbst gebaut | ein Neubau kann neuere Layer ziehen | per Digest ausrollen; spiegeln |
| Infrastrukturcode | ja | Neuaufbau von Hand | git, mit gesichertem git-Server |
| Secrets und Token | ja | neu ausstellen, wo möglich | ein Secrets-Manager mit eigenem Backup |
| Anfrage- und Antwortlogs | ja | nicht möglich | unter denselben Aufbewahrungsregeln sichern |
| Monitoringdaten | nur die Historie | neue Daten ab dem nächsten Scrape | sichern, wenn Sie die Historie brauchen |
Unsere Einordnung; die Quellen stehen in den folgenden Abschnitten.
Basisgewichte: ein Download nur, solange die Revision existiert
Llama 3.3 70B umfasst in NVIDIAs FP8-Checkpoint 15 safetensors-Dateien, 72.656.585.760 Byte auf Hugging Face: 72,7 GB, die 68 GiB, mit denen diese Website durchgehend rechnet. Ein erneuter Download stellt es nur wieder her, solange drei Bedingungen erfüllt sind.
Die Revision existiert. Hugging Face wählt eine Version über den Parameter revision, einen Branch, ein Tag oder einen Commit-Hash; nur ein Commit-Hash pinnt die Version, und er „muss der Hash in voller Länge sein“; die Einstellung revision von vLLM akzeptiert dieselben Werte. Eigentümer können die Historie aber umschreiben: Hugging Face nennt seinen Super-Squash „einen destruktiven Vorgang, der sich nicht rückgängig machen lässt“, nach dem „die Commit-Historie dauerhaft verloren sein wird“.
Ihr Zugang besteht. Metas Repository für Llama 3.3 70B Instruct ist zugangsbeschränkt, mit manueller Freigabe, und Hugging Face stellt fest, dass Modellautoren „jederzeit entscheiden können, Ihren Zugang zum Modell ohne vorherige Ankündigung zu sperren“. Zugang erhalten einzelne Nutzer, nicht Organisationen; das Token, mit dem ein zugangsbeschränktes Modell heruntergeladen wird, gehört also einer Person, und der Wiederherstellungsweg kann mit ihr das Unternehmen verlassen.
Die Dateien stimmen überein. Hugging Face führt für jede Gewichtsdatei einen SHA-256-Wert auf, und hf cache verify prüft ein lokales Verzeichnis gegen „ihre Prüfsummen auf dem Hub“. Beides hängt vom Hub ab; halten Sie deshalb eine eigene Kopie der Dateien vor, die Sie im Serving nutzen, mit einem SHA-256-Manifest, das getrennt vom Server gespeichert ist.
Adapter und feinabgestimmte Gewichte: einmalig und an eine Basis gebunden
PEFT speichert einen LoRA-Adapter als adapter_ und adapter_, und der gespeicherte Zustand „enthält nur die Parameter des Adaptermoduls, nicht das Basismodell“. Die Konfiguration nennt das Basismodell und hat dafür ein Feld revision; in NVIDIAs Content-Safety-Adapter NemoGuard für Llama 3.1 8B steht dieses Feld auf null, dem Wert, den PEFT setzt, wenn keiner angegeben ist, und die Basis, Metas Llama 3.1 8B Instruct, ist zugangsbeschränkt. Halten Sie den Basis-Commit selbst fest.
Die Größe folgt aus Rang, Zielschichten und Präzision. Nach unserer Rechnung hat ein Adapter mit Rang 16 auf jeder Attention- und MLP-Projektion von Llama 3.3 70B insgesamt 207,1 Millionen Parameter: 828 MB in FP32 oder 414 MB in BF16. NVIDIAs Adapter, ebenfalls mit Rang 16, ist eine einzige Datei mit 1,23 GB; seine Konfiguration nennt auch lm_head als Ziel, den PEFT zu den Embedding-Schichten zählt, die es „zusätzlich zu den Adaptergewichten“ speichern kann. Ein vollständig feinabgestimmtes Modell ist ein ganz neuer Checkpoint: 141,1 GB für das 70B-Modell in BF16.
Ihre eigenen Adapter und feinabgestimmten Modelle lassen sich nicht erneut herunterladen, und ein erneutes Training ist kein verlässlicher Weg, sie neu zu erzeugen: PyTorch verspricht keine vollständig reproduzierbaren Ergebnisse „über PyTorch-Releases, einzelne Commits oder verschiedene Plattformen hinweg“. Sichern Sie jeden Adapter oder Checkpoint mit seinen Trainingsdaten, seinem Evaluierungsset, seiner Konfiguration und seiner Basisrevision als eine Wiederherstellungseinheit.
Vektorspeicher: Lassen Sie die Datenbank die Kopie erstellen
Wer das Datenverzeichnis einer laufenden Datenbank kopiert, erhält Dateien, nicht unbedingt einen konsistenten Zustand. Jeder Vektorspeicher dokumentiert seinen eigenen Weg.
| VEKTORSPEICHER | KONSISTENTE KOPIE | WIEDERHERSTELLUNG IN | ZU BEACHTEN |
|---|---|---|---|
| PostgreSQL mit pgvector | pg_dump je Datenbank plus pg_ für die Rollen, oder pg_ mit WAL-Archivierung für den ganzen Cluster | ein Dump: auch neuere Versionen; ein Base Backup: nur dieselbe Hauptversion und Hardwarearchitektur | pgvector muss auf dem Ziel installiert sein; ein Dump baut die Indizes neu auf |
| Qdrant | ein Snapshot je Collection und je Knoten | dieselbe Nebenversion oder die nächste | eine neue Collection braucht die Priorität snapshot; die Voreinstellung lässt sie leer |
| Milvus | Milvus Backup, per CLI oder API, in einen Backup-Root-Pfad | dieselbe oder eine neuere 2.x-Version, Version 2.4 bis Version 2.6; Version 3.0 steht nicht in seiner Tabelle | Bucket und Root-Pfad von Milvus selbst in seiner Konfiguration setzen |
Dokumentation zu PostgreSQL 18; pgvector-README, v0.8.6; Qdrant-Dokumentation zu Snapshots; Dokumentation und README von Milvus Backup, v0.5.16; Release Notes von Milvus (3.0.0 vom 29. Juli 2026); alle im September 2026 gelesen.
pgvector speichert Vektoren als gewöhnliche PostgreSQL-Daten, 4 Byte je Dimension plus 8 je Vektor, und „nutzt das Write-Ahead-Log (WAL), das Replikation und Point-in-Time-Recovery ermöglicht“. pg_dump „erstellt konsistente Exporte, auch wenn die Datenbank gleichzeitig genutzt wird“; Backups auf Dateiebene und kontinuierliche Archivierung sind dagegen „äußerst spezifisch für die Serverversion“. Ein Dump enthält nur einen Befehl CREATE EXTENSION; das Ziel braucht also die „Control-, Skript- und anderen Dateien“ von pgvector, und der Dump baut bei der Wiederherstellung jeden HNSW-Index neu auf, schneller, „wenn der Graph in maintenance_ passt“. Ein Base Backup stellt die Indexdateien so wieder her, wie sie waren, und erlaubt Point-in-Time-Recovery, aber nur für „den gesamten Datenbankcluster“.
Qdrant-Snapshots sind „tar-Archivdateien, die Daten und Konfiguration einer bestimmten Collection auf einem bestimmten Knoten enthalten“, ein Cluster braucht also einen je Knoten, erstellt mit einem POST an /collections/{collection_; vollständige Storage-Snapshots eignen sich nur für Deployments mit einem einzigen Knoten. Die Wiederherstellung nutzt standardmäßig die Priorität replica, die „vorhandene Daten dem Snapshot vorzieht“: Eine so wiederhergestellte neue Collection kommt leer zurück, also „müssen Sie die Priorität auf snapshot setzen“. Milvus Backup, zum Beispiel milvus-backup create -n my_, kopiert Metadaten und Daten in einen Backup-Root-Pfad, während die Instanz „voll funktionsfähig“ bleibt.
Den Index neu aufzubauen funktioniert, solange die Quelldokumente und exakt dasselbe Embedding-Modell erhalten bleiben; ein Modellwechsel bedeutet neue Vektoren, und Qdrant rät, „Punkte neu einzubetten“. Kopieren ist im Vergleich dazu günstig: 10 Millionen Chunks mit 1.024 Dimensionen sind 41 GB Vektordaten vor Indizes und Zeilen-Overhead, nach unserer Rechnung. Die mit jedem Chunk gespeicherten Zugriffsrechte sind nur so aktuell wie der letzte Abgleich: Gleichen Sie sie aus den Quellsystemen neu ab, bevor Nutzer einen wiederhergestellten Index abfragen.
Virtuelle Maschinen, Passthrough-GPUs und Kubernetes
Das VM-Backup auf Image-Ebene beruht auf Snapshots: „Wenn Sie eine VM sichern, fordert Veeam Backup & Replication VMware vSphere auf, einen VM-Snapshot zu erstellen.“ Mit einer GPU im Passthrough ist dieser Weg versperrt, solange die VM läuft: Broadcoms Dokumentation zu vSphere 9.0 führt Snapshots unter den Funktionen auf, die „für virtuelle Maschinen, die mit DirectPath konfiguriert sind, nicht verfügbar“ sind, und ein Artikel aus Broadcoms Wissensdatenbank zu ESXi 8.0 ergänzt, dass „Snapshots bei ausgeschalteten VMs auch mit vorhandenen Passthrough-Geräten gelingen“. Eine laufende Passthrough-VM wird wie ein Bare-Metal-GPU-Server von innen geschützt: mit einem Agenten im Gastsystem wie Veeam Agent for Linux, gebaut für „physische Endpunkte und virtuelle Maschinen mit Linux-basierten Betriebssystemen“, sowie mit den oben beschriebenen Kopien auf Anwendungsebene. Für vGPU-VMs haben wir in der aktuellen Dokumentation von NVIDIA oder Broadcom keine Einschränkung für Snapshots gefunden; belegen Sie den Weg mit einem Testlauf aus Backup und Wiederherstellung.
Auf Kubernetes erfasst Veeam Kasten (Release 9.0.6 im September 2026) die namespace-gebundenen Ressourcen einer Anwendung wie ConfigMaps und Secrets, ihre Workloads, die Release-Informationen von Helm v3 und „alle persistenten Speicherressourcen“, die mit den Workloads verbunden sind; ein Modell-Cache auf dem Node statt in einem Persistent Volume fällt nicht unter diese Liste. Kasten warnt außerdem, dass „ein katastrophaler Ausfall des Speichersystems Ihre Snapshots zusammen mit Ihren Primärdaten zerstören wird“; exportieren Sie sie deshalb an einen externen Ort. Pinnen Sie jedes Image per Digest, <image-name>@<digest>: In den Worten von Kubernetes „identifiziert ein Image-Digest eindeutig eine bestimmte Version des Images“.
Wohin die Kopien gehen und wie lange sie dauern
Schützen Sie die NVMe-Ebenen unterschiedlich: Der Modellspeicher ist groß und wird überwiegend gelesen, kopieren Sie ihn also einmal je neuer Revision, nicht jede Nacht. Adapter, Evaluierungssets, Konfiguration und Logs sind klein und einmalig: Jedes Backup nimmt sie mit, und Trainingsdaten bekommen einen eigenen Zeitplan. Eine Kopie sollte außer Reichweite jedes Administratorkontos liegen: Veeams 3-2-1-1-0-Regel ergänzt drei Kopien auf zwei Medien, davon eine außer Haus, um eine unveränderliche oder per Air Gap getrennte Kopie und null Fehler nach der Prüfung der Wiederherstellung. Unser Artikel zu unveränderlichen Backups behandelt die Mechanik.
Bei voller Leitungsrate, vor Protokoll-Overhead, Laufwerksgeschwindigkeit und dem eigenen Aufwand der Backup-Software, setzt das Netzwerk diese Untergrenze:
| DATEN | GRÖSSE | BEI 1 GBIT/S | BEI 25 GBIT/S | BEI 100 GBIT/S |
|---|---|---|---|---|
| Llama 3.3 70B, FP8 | 72,7 GB | 9 min 41 s | 23 s | 6 s |
| Llama 3.3 70B, BF16 | 141,1 GB | 18 min 49 s | 45 s | 11 s |
| Modellspeicher, z. B. 4 TB | 4 TB | 8 h 53 min | 21 min 20 s | 5 min 20 s |
Unsere Rechnung: Byte × 8 ÷ Leitungsrate. Größen aus den Dateilisten auf Hugging Face für NVIDIAs FP8-Checkpoint (15 Dateien) und Metas BF16-Checkpoint (30 Dateien), September 2026. Untergrenzen allein für die Kopie.
Eine Kopierzeit ist ein Summand einer Wiederherstellung, keine Schätzung dafür: Unsere Artikel zu Backup und Disaster Recovery und zu RPO und RTO behandeln den Rest der Wiederherstellungszeit und wie Sie die Ziele festlegen. Wir empfehlen einen zweiten 25-GbE-Port, damit Backup-Verkehr und Modell-Downloads nicht über das Netz laufen, das die Nutzer bedient.
Wiederherstellungstests, die etwas beweisen
Ein grüner Wiederherstellungsjob beweist, dass Bytes angekommen sind. Drei Tests zeigen, dass der KI-Dienst zurück ist, jeder gegen eine Baseline, aufgezeichnet, solange alles funktioniert.
Dateien. Prüfen Sie jede wiederhergestellte Gewichts-, Adapter- und Tokenizer-Datei gegen das SHA-256-Manifest, zum Beispiel mit dem Befehl sha256sum --check, der bei einer Abweichung mit einem Status ungleich null endet. Für Modelle vom Hub vergleicht hf cache verify mit --revision, --local-dir und der Option --fail-on-missing-files, ohne die der Befehl bei einer fehlenden Datei nur warnt, ein wiederhergestelltes Verzeichnis mit den Werten des Hubs.
Antworten. Lassen Sie das feste Evaluierungsset, mit dem das Modell abgenommen wurde, auf dem wiederhergestellten Stack laufen, gegen eine vorab festgelegte Bestehensgrenze. Erwarten Sie keinen identischen Text: vLLM verspricht standardmäßig keine reproduzierbaren Ergebnisse, „zugunsten der Performance“, und selbst mit seinen Einstellungen für Reproduzierbarkeit bietet es „Reproduzierbarkeit nur, wenn es auf derselben Hardware und derselben vLLM-Version läuft“. Bewerten Sie Antworten, nicht Zeichenketten.
Retrieval. Führen Sie feste Abfragen gegen den wiederhergestellten Index aus und vergleichen Sie die Top-Treffer mit der Baseline. Die README von pgvector merkt an, dass Sie, anders als bei typischen Indizes, „nach dem Hinzufügen eines approximativen Index andere Ergebnisse für Abfragen sehen werden“; legen Sie die Bestehensgrenze deshalb vorab fest: dieselben IDs bei wiederhergestellten Indexdateien, eine vereinbarte Überschneidung bei einem Index, der durch die Wiederherstellung eines Dumps neu aufgebaut wurde, oder bei neu eingebetteten Chunks. Ergänzen Sie eine Abfrage je Berechtigungsstufe, um zu bestätigen, dass die Berechtigungen mit zurückgekommen sind.
Regelmäßige Testwiederherstellungen zur Prüfung der Backup-Integrität gehören zum Cyber-Resilienz-Service, den unser Engineering-Partner Vixen.UNO erbringt; schreiben Sie auf einem KI-Server diese drei Prüfungen in den Testplan.
Was wir liefern
Eurokommerz liefert auf Bestellung gebaute KI-Server mit NVMe-Ebenen für Scratch, Modellspeicher und Indizes sowie Netzwerkkarten von 25 bis 400G, mit Herstellergarantie, EU-Vertrag und EU-Rechnungsstellung. Das Engineering der Backup-Seite übernimmt das Team von Vixen.UNO, unserem Engineering-Partner, unter demselben Vertrag: Sein Cyber-Resilienz-Service umfasst Backup auf Veeam-Basis mit einem Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen, regelmäßige Testwiederherstellungen und einen Incident-Response-Plan mit Rollen, Maßnahmen und Fristen; Kapazität, Supportbedingungen und Wiederherstellungsziele sind im SLA fixiert. Die Replikation virtueller Maschinen an einen Ausweichstandort, an dem Systeme aus Replikaten hochfahren und laufen, während Ihr Primärstandort ausgefallen ist, bildet den Disaster-Recovery-Service.
FAQ
Muss ich Modellgewichte sichern, die ich erneut herunterladen kann?
Wie groß ist ein LoRA-Adapter?
Wie sichere ich eine Vektordatenbank konsistent?
Kann Veeam eine VM mit einer GPU im Passthrough sichern?
Wie prüfe ich, ob wiederhergestellte Modelldateien intakt sind?
Gibt ein wiederhergestelltes Modell genau dieselben Antworten?
Schicken Sie uns, was auf dem Server läuft: die Modelle und ihre Revisionen, die Adapter, den Vektorspeicher mit seiner Größe und wohin die Backups heute gehen. Wir liefern Ihnen, was zu schützen ist, wie Sie die Wiederherstellung testen und welchen Storage und welches Netzwerk der Server braucht, oder vereinbaren ein erstes Gespräch mit unserem Engineering-Partner. Wir antworten innerhalb eines Werktages.
Mit einem Experten sprechenWir antworten innerhalb eines Werktages