# API Versioning – Backward Compatibility

Kurzfassung: Tiering senkt Kosten und hält wichtige Restore-Punkte schnell erreichbar. Ziel: schnelle Performance-Tier für aktuelle Backups, günstige Capacity/Archive-Tiers für ältere Punkte, gesteuert durch Offload-Regeln.

# 1. Zweck & Zielbild

• Aktuelle Restore Points auf schnellem Storage, ältere auf günstigem/kaltem Tier.
• Transparente Kostenkontrolle bei erhaltenem RTO/RPO.
• Automatisierte Offload-Regeln, Immutability wo möglich.

# 2. Voraussetzungen

• SOBR oder gleichwertige Tiering-Funktion (Performance + Capacity/Archive).
• Geeignete Ziele: ReFS/XFS für Performance, S3/Blob/Object für Capacity/Archive.
• Netzwerk/BWLimit für Offload, IAM/Locks für Cloud (Artikel 806/807).

# 3. Risiken / Backout

• Zu frühes Offload → Restore dauert länger.
• Zu spätes Offload → hohe Kosten/Platzmangel auf Performance-Tier.
• Falsche Storage-Klasse → hohe Egress/Access-Kosten.
• Backout: Offload-Regeln anpassen, Punkte rehydratisieren, Tier verschieben.

# 4. Umsetzung (Schritte)

1. Tier-Design: Performance-Tier lokal/schnell, Capacity/Archive in Cloud/zweitem Standort; Immutability auf Capacity/Archive.
2. Offload-Regeln: Nach Alter/Status (z. B. >14 Tage ins Capacity, >90 Tage ins Archive).
3. Scheduling/BW: Offload nach Backup-Fenster, BWLimit; Dedupe/Compression vorher nutzen.
4. GFS & Retention: GFS auf Capacity/Archive abbilden; sicherstellen, dass wichtige Punkte nicht zu früh offgeladen werden.
5. Tests: Restore aus Capacity/Archive (VM/File), Dauer messen, Kosten prüfen (Egress).
6. Dokumentation: Regeln, Ziele, Kostenannahmen, Owner.

# 5. Verify / Tests

• Offload-Logs ok, Punkte landen im richtigen Tier.
• Restore aus allen Tiers erfolgreich, RTO akzeptabel.
• Kosten/Egress im Plan.

# 6. Runbooks

• Offload zu langsam: BWLimit lockern, Zeitfenster erweitern, mehr Concurrency.
• Restore dauert zu lang: Wichtigere Punkte länger auf Performance lassen, Rehydratisieren vorgeplant.
• Kosten hoch: Storage-Klasse/Lifecycle anpassen, unnötige Rehydratierungen vermeiden.

# 7. Monitoring / Alerts

• Offload-Status, Kapazität je Tier, Egress/Requests, Fehlversuche.
• Alerts bei Offload-Fails, Kapazität >80 %, ungewöhnlichen Egress-Kosten.

# 8. Governance

• Tiering-Policy versionieren, regelmäßiger Kosten-/Performance-Review.
• Immutability/Locks kontrollieren, IAM/Keys prüfen.
• Reports an Finance/Ops zu Offload-Mengen und Kosten.

# 9. Links & Quellen

• Artikel 784/806/807 (Repos/Cloud/Offsite), 795 (Synthetic Full), 805 (Copy), Veeam SOBR/Tiering Docs.