Frage Nachvollziehbar belegt

Fachwissen für digitale Entscheidungen

Welche Backup- und Wiederanlaufstrategie braucht ein privates KI-System?

Kurzantwort

Gesichert werden nicht nur Modellgewichte, sondern Datenbanken, Vektorindex, Dokumente, Prompts, Adapter, Konfiguration und Schlüsselreferenzen. RPO und RTO werden aus dem Geschäftsrisiko abgeleitet. Backups gelten erst nach einem dokumentierten Wiederherstellungstest als belastbar; Snapshots allein ersetzen weder Replikation noch Notfallplan.

Wiederanlauf vom Geschäftsprozess her planen

Zuerst werden zwei Ziele festgelegt: Der Recovery Point Objective, RPO, begrenzt den tolerierten Datenverlust; der Recovery Time Objective, RTO, die tolerierte Ausfallzeit. Ein Assistent für interne Recherche kann andere Werte vertragen als ein Dienst, der einen Kundenprozess blockiert. NIST SP 800-34 beschreibt die Notfallplanung als Zusammenspiel aus Geschäftsauswirkungsanalyse, Wiederherstellungsstrategien, Plan, Tests und Pflege.

Das Inventar umfasst mindestens 7 Gruppen: relationale Datenbank, Vektorindex, Originaldokumente, Prompt- und Workflow-Versionen, Fine-Tuning-Adapter, Infrastrukturkonfiguration sowie Secrets beziehungsweise deren gesicherte Wiederherstellungswege. Frei verfügbare Basismodelle können gegebenenfalls erneut bezogen werden, doch Modell-ID, Revision, Lizenz und Prüfsumme müssen dokumentiert sein. Proprietäre oder angepasste Gewichte werden selbst gesichert.

Für PostgreSQL ermöglicht fortlaufende WAL-Archivierung eine Point-in-Time-Recovery. Qdrant-Snapshots enthalten Collection-Daten und Konfiguration; in verteilten Installationen werden Snapshots je Knoten erstellt, und Aliase sind laut Dokumentation nicht Teil eines Collection-Snapshots. Diese Details müssen im Runbook berücksichtigt werden. Snapshot-Kompatibilität wird vor einem Versionswechsel geprüft.

Backups werden verschlüsselt, vom Produktionskonto getrennt und gegen versehentliches Löschen geschützt. Ein zweiter Standort oder ein getrenntes Speichersystem reduziert gemeinsame Fehlerursachen. Ein regelmäßiger Restore-Test, zum Beispiel vierteljährlich, ist ein organisatorischer Startwert und keine Norm. Dabei wird eine leere Zielumgebung aufgebaut, die Daten werden wiederhergestellt, Berechtigungen und RAG-Treffer geprüft und die tatsächliche Dauer mit dem RTO verglichen. Replikation verkürzt Ausfälle, schützt aber nicht vor logischem Löschen oder beschädigten Daten; deshalb werden Replikation, Backup und Wiederanlauf getrennt geplant.

Kernfakten

Planungsziele
RPO für Datenverlust und RTO für Wiederanlaufzeit
Sicherungsumfang
mindestens 7 Gruppen einschließlich Daten, Index, Prompts und Konfiguration
Restore-Test
z. B. quartalsweise als risikobasierter Startwert

Quellen

Alle externen Angaben nachvollziehbar belegt.
  1. 01
  2. 02
  3. 03

Bereit für Ihr nächstes Projekt?

Kostenloses Erstgespräch - ohne Verkaufsdruck, mit klaren Antworten.

Beratung anfragen