Anforderungsprofil: Backup & Recovery
Herstellerneutrales technisches Anforderungs- und Beschaffungspaket zum Entscheidungspaket „Backup & Recovery“.
Am Ende steht ein gemessener Restore-Nachweis für einen kritischen Verwaltungsservice mit dokumentiertem RPO/RTO, isolierter Kopie, Offsite-Pfad, Runbook und belastbarer Kosten-/Retention-Basis.
Thema: backup · Stand 2026-09-21Welle 3 · Compute, Recovery & Observability
Server, Virtualisierung, Backup/Restore und Monitoring als gemeinsame Betriebsplattform dimensionieren und abnehmen.
Vor jeder Punktebewertung nachweisen
Diese Kriterien sind als technische Mindestnachweise formuliert. Nicht erfüllte Muss-Kriterien sollten nicht durch Komfort- oder Preisvorteile kompensiert werden.
| ID | Kriterium | Geforderter Nachweis |
|---|---|---|
| M01 | Restore-Test mit einem repräsentativen Workload durchführen und den gemessenen RTO dokumentieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M02 | Immutability, getrennte Administrationsrechte, Retention und Löschschutz am konkreten Repository verifizieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M03 | Offsite-Fehlerdomäne, verfügbare Restore-Bandbreite und Wiederanlaufreihenfolge für einen Standortausfall prüfen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M04 | Workload-Abdeckung inklusive Microsoft 365/SaaS, Datenbanken und anwendungskonsistenter Sicherung gegen die Herstellerdokumentation prüfen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M05 | Lizenz-, Storage-, Egress- und Retention-Kosten über die geplante Laufzeit mit einem realen Angebot kalkulieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
Mehrwert nur mit realem Betriebsnutzen bewerten
| ID | Kriterium | Bewertungshinweis |
|---|---|---|
| K01 | Anwendungs- und orchestrierte Recovery-Tests lassen sich automatisiert und regelmäßig ausführen. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K02 | Isolierte Recovery-Umgebungen oder Malware-Scanning unterstützen einen kontrollierten Wiederanlauf. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K03 | Tiering/Object-Storage kann Retention und Offsite-Kosten transparent optimieren. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K04 | APIs und standardisierte Exporte erleichtern Reporting, Automation und späteren Plattformwechsel. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
Fragen für Angebot, Workshop und technische Klärung
Wird ein repräsentativer Service innerhalb des Ziel-RTO mit geprüftem RPO und konsistenten Anwendungen wiederhergestellt?
Sind unveränderliche oder vergleichbar geschützte Kopien gegen Produktions- und Standard-Admin-Fehler getrennt?
Ist ein unabhängiger Fehlerbereich vorhanden und reicht der reale Datenpfad für die geforderte Recovery-Reihenfolge?
Sind VMs, Datenbanken, SaaS/M365 und weitere kritische Datenklassen mit passenden Konsistenzverfahren abgedeckt?
Sind Restore-Tests, Monitoring, Rollen, Eskalation und Kapazitätsmanagement dauerhaft organisiert?
Sind Lizenz-, Storage-, Egress- und Retention-Kosten sowie Export/Migration transparent und praktisch prüfbar?
Gates als objektive Abnahmekriterien verwenden
Für den Pilot-Service sind zulässiger Datenverlust, Ziel-Wiederherstellungszeit und technische Abhängigkeiten eindeutig dokumentiert.
Ein kompromittiertes Produktions- oder Standard-Admin-Konto kann die geschützte Recovery-Kopie nicht ohne zusätzliche Kontrolle löschen.
Der Pilot deckt einen repräsentativen Workload einschließlich anwendungskonsistenter Sicherung und realistischem Offsite-Transfer ab.
Der Service ist innerhalb des Ziel-RTO mit fachlich/technisch geprüfter Datenkonsistenz wieder nutzbar.
Restore-Tests haben Owner und Turnus; Kosten und Exit hängen nicht von ungetesteten Annahmen ab.
Vor Produktivsetzung klären
- Backup-/Replication-Jobs, Repository-Zustand und geschützte Kopien kontinuierlich überwachen.
- Regelmäßige Restore-Tests je Serviceklasse mit gemessenem RPO/RTO durchführen.
- Break-Glass, Admin-Trennung und Lösch-/Retention-Änderungen gesondert kontrollieren.
- Kapazität, Offsite-Transfer, Retention und Recovery-Runbooks mit festen Ownern pflegen.
Vor Vertragsbindung nachweisen
- Backupdaten und erforderliche Restore-Punkte innerhalb definierter Frist in ein nutzbares Folgeformat überführen können.
- Retention-/Immutable-Bindungen, Schlüssel und Offsite-Daten kontrolliert auslaufen oder migrieren.
- Vor Abschaltung der Altplattform einen vollständigen Restore eines repräsentativen Services aus dem Zielsystem nachweisen.
Gewichtete Bewertung erst nach den Muss-Kriterien
Die Gewichte ergeben zusammen 100 %. Die Skala bewertet nachgewiesene Eignung – nicht Herstellergröße oder Markenpräferenz.
| Kategorie | Gewicht | Skala | Dokumentation |
|---|---|---|---|
| Recovery & SLA | 30 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Isolation & Security | 25 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Workload & Integration | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Betrieb & Skalierung | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Commercial & Exit | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
Für Pilot, Entscheidung und Vertrag dokumentieren
- RPO/RTO-Matrix
- Workload-Matrix
- Backup-Architektur
- Admin-/Rollenmodell
- Offsite-Konzept
- Kapazitätsmodell
- Restore-Protokoll
- Recovery-Runbook
- Testkalender
- Kosten-/Exit-Nachweis