Bildquelle: extern
Entra-Backups lösen noch keine Tenant-Krise, wenn Hybridobjekte und harte Löschungen außen vor bleiben
Identitätsvorfälle wirken auf dem Papier oft einfacher als ein großer Plattformausfall. Ein Benutzerobjekt fehlt, eine Richtlinie wurde falsch geändert, eine Anwendung kommt nicht mehr an ihr Service Principal oder eine Gruppe trägt plötzlich die falschen Mitglieder. In der Praxis hängen an solchen Änderungen aber Freigaben, Admin-Rollen, Synchronisationspfade und oft genug der komplette Zugang zu produktiven Diensten. Genau deshalb ist Microsoft Entra Backup and Recovery interessant. Die Funktion bringt erstmals einen eingebauten Sicherungs- und Wiederherstellungspfad für zentrale Verzeichnisobjekte direkt in den Tenant. Nur sollte niemand daraus vorschnell ableiten, das Identitäts-Recovery sei damit automatisch gelöst.
Die aktuelle Microsoft-Dokumentation beschreibt die Funktion klar als Preview und zugleich als echten operativen Baustein. Administratoren können verfügbare Sicherungen einsehen, Difference Reports erzeugen, Änderungen gegen einen älteren Stand vergleichen und anschließend gezielt Objekte oder alle Änderungen zurücksetzen. Seit März 2026 ist die Vorschau offiziell angekündigt. Das ist ein nützlicher Fortschritt für Identity-Teams. Der eigentliche Betriebswert entsteht aber erst dann, wenn die Grenzen verstanden sind. Genau dort wird das Thema spannend.
Der neue Schutzpfad hilft bei Änderungen, nicht bei jeder Form von Verlust
Microsoft sichert laut Learn-Dokumentation unterstützte Tenant-Objekte einmal pro Tag und hält bis zu fünf Tage Verlauf vor. Das ist für viele reale Vorfälle ausreichend, etwa wenn eine Conditional-Access-Policy falsch angepasst, eine Anwendung unbrauchbar konfiguriert oder eine wichtige Gruppe versehentlich verändert wurde. Difference Reports zeigen dabei nur die Änderungen zwischen Sicherung und aktuellem Zustand. Das hilft, vor einer Wiederherstellung nicht blind zurückzurollen, sondern zuerst zu sehen, was sich seit dem letzten guten Zustand überhaupt verändert hat.
Gerade dieser Difference-Report-Gedanke ist operativ wichtiger als die Backup-Funktion selbst. Viele Identitätsstörungen eskalieren nicht deshalb, weil niemand sichern kann, sondern weil niemand vor dem Restore sauber bewertet, welche Änderung fachlich wirklich falsch ist. Wenn mehrere Teams gleichzeitig an Rollen, Richtlinien oder Anwendungen arbeiten, kann ein pauschaler Rollback mehr kaputtmachen als reparieren. Ein Restore ohne vorgelagerten Vergleich ist im Identitätsbetrieb ungefähr so sinnvoll wie ein Datenbank-Restore ohne Blick auf die Transaktionen danach.
Microsoft nennt außerdem eine oft übersehene Betriebsgrenze: Es kann immer nur ein Job gleichzeitig laufen. Difference Reports und Recovery-Jobs blockieren sich also gegenseitig. Wer im Vorfall schon einen großflächigen Vergleich gestartet hat, kann nicht parallel eine spontane Wiederherstellung anwerfen. Für kleinere Tenants ist das meist unkritisch. In größeren Umgebungen mit vielen Änderungen wird daraus aber schnell eine Führungsfrage. Dann muss klar sein, welcher Job Priorität hat, wer ihn freigibt und wie parallel auftretende Störungen in dieser Zeit abgesichert werden.
Hybridobjekte bleiben der Lackmustest für jedes Entra-Recovery
Der vielleicht wichtigste Satz in der Microsoft-Dokumentation steht nicht bei den Stärken, sondern bei den Grenzen. Änderungen an synchronisierten Objekten aus dem lokalen Active Directory tauchen zwar in Difference Reports auf, lassen sich über Entra Backup and Recovery aber nicht wiederherstellen, weil die Source of Authority weiterhin on-premises liegt. Genau hier endet die verbreitete Vereinfachung, ein Cloud-Tenant lasse sich jetzt vollständig aus sich selbst heraus zurücksetzen.
Für viele Unternehmen ist das der entscheidende Punkt. Benutzer, Gruppen und Berechtigungslogik sind oft hybrid gewachsen. Manche Gruppen werden bereits in der Cloud geführt, andere kommen aus dem lokalen AD, wieder andere wurden im Laufe der Zeit umgestellt. Microsoft beschreibt sogar ausdrücklich, dass für bestimmte Objekttypen wie Gruppen ein Wechsel der Source of Authority in die Cloud möglich ist. Das ist wichtig, weil sich daraus eine strategische Architekturfrage ergibt: Welche Identitätsobjekte sollen im Ernstfall cloudseitig recoverbar sein, und welche bleiben bewusst im lokalen Verantwortungsbereich?
Wer diese Trennung nicht dokumentiert, wird im Störungsfall unnötig Zeit verlieren. Dann sieht ein Team im Difference Report zwar die betroffene Gruppe oder den geänderten Benutzer, merkt aber erst während der Wiederherstellung, dass das Objekt auf diesem Weg gar nicht zurückgeholt werden kann. Aus technischer Sicht ist das kein Produktfehler, sondern ein Führungsfehler im Betriebsmodell. Identity-Recovery braucht deshalb eine sichtbare Objektklassifizierung: cloud-managed, hybrid-synced oder extern abhängig.
Harte Löschungen bleiben ein echter Grenzfall
Microsoft formuliert die nächste Grenze ebenfalls ziemlich klar. Hard-deleted objects can’t be recovered. Die Funktion kann Objekte aktualisieren, soft-deletete Objekte wiederherstellen oder neu hinzugekommene Objekte im Rahmen eines Rollbacks wieder soft-deleten. Sie erzeugt aber keine neuen Objekte und kann hart gelöschte Objekte nicht zurückholen. Genau deshalb verweist Microsoft auf Protected Actions, um ungewollte harte Löschungen präventiv abzusichern.
Das ist für den Alltag wichtiger, als es zunächst klingt. In vielen Teams wird Löschschutz immer noch als nachgelagerte Sicherheitsidee behandelt, während die eigentliche Aufmerksamkeit auf Backup und Restore liegt. Im Identitätsbetrieb ist die Reihenfolge oft umgekehrt sinnvoller. Erstens müssen harte Löschpfade so stark wie möglich erschwert werden. Zweitens sollte klar sein, welche Objekte im Notfall nur über alternative Rekonstruktion, nicht aber über Entra-Backup zurückkommen. Drittens braucht der Service Desk eine saubere Eskalation, damit nicht aus Zeitdruck in produktiven Identitätsvorfällen vorschnell irreversible Schritte ausgelöst werden.
Hinzu kommt eine weitere Abgrenzung: Microsoft Entra Backup and Recovery sichert Verzeichnisobjekte, aber keine Microsoft-365-Ressourcen wie Mailboxen, OneDrive oder SharePoint-Sites und auch keine Azure-Ressourcen. Wer also nach einem Tenant-Vorfall zugleich Identität, Postfachzugriff und Datenwiederherstellung im Blick behalten muss, braucht weiterhin mehrere Wiederanlaufpfade. Das Tool schließt eine wichtige Lücke, ersetzt aber kein vollständiges Tenant- oder Business-Recovery-Konzept.
Was Identity-Teams vor dem ersten Ernstfall festziehen sollten
Der sinnvolle nächste Schritt ist deshalb nicht, die Preview nur zu aktivieren und sich besser zu fühlen. Sinnvoll ist ein kleiner, aber harter Betriebsrahmen. Erstens braucht es klare Rollen: Wer darf nur Backups einsehen, wer Difference Reports anstoßen und wer eine Recovery tatsächlich freigeben? Microsoft trennt dafür bereits zwischen Backup Reader und Backup Administrator. Zweitens muss die Objektlandschaft klassifiziert werden, damit sofort erkennbar ist, welche Gruppen, Benutzer und Policies über den Entra-Pfad recoverbar sind und welche nicht.
Drittens lohnt sich ein fester Probelauf mit Difference Report und gezielter Wiederherstellung in einem unkritischen Szenario. Nicht, um eine Marketingdemo zu sehen, sondern um Wartezeiten, Job-Sperren und die tatsächliche Änderungsmenge im eigenen Tenant kennenzulernen. Microsoft nennt für große Difference Reports und Recovery-Jobs durchaus nennenswerte Laufzeiten. Wer das erst im realen Vorfall entdeckt, verliert Ruhe und Übersicht genau dann, wenn beides am wichtigsten wäre.
Viertens sollten Hybrididentität und Hard-Delete-Schutz nicht als Nebenthemen neben dem neuen Backup-Pfad laufen. Sie sind der Kern der nüchternen Bewertung. Ein Tenant ist nicht deshalb recoverable, weil fünf Sicherungen sichtbar sind. Er ist dann recoverable, wenn Teams wissen, welche Objekte überhaupt von diesem Mechanismus erfasst werden, welche Löschpfade verhindert wurden und welcher Alternativpfad für nicht recoverbare Objekte gilt.
Fazit
Microsoft Entra Backup and Recovery ist ein echter Fortschritt, weil zentrale Identitätsobjekte jetzt mit eingebauten Sicherungen, Difference Reports und Recovery-Jobs geführt werden können. Für viele Tenant-Vorfälle ist das sofort nützlich. Gleichzeitig wäre es ein Fehler, daraus ein vollständiges Entwarnungssignal zu machen. Hybridobjekte bleiben vom lokalen Source-of-Authority-Modell abhängig, harte Löschungen sind nicht recoverbar, und auch Microsoft-365- oder Azure-Ressourcen hängen weiter an anderen Wiederanlaufpfaden.
Der operative Wert liegt deshalb nicht nur in der Funktion selbst, sondern in der Disziplin drum herum: Rollen sauber trennen, Difference Reports vor dem Restore ernst nehmen, Hard Deletes präventiv absichern und Hybridobjekte sichtbar klassifizieren. Dann wird aus der neuen Entra-Funktion ein belastbares Werkzeug. Ohne diese Vorarbeit bleibt sie ein gutes Feature, aber noch kein vollständiger Tenant-Rettungsplan.
Quellen
- Microsoft Learn: Microsoft Entra releases and announcements
- Microsoft Learn: Microsoft Entra Backup and Recovery overview (Preview)
- Microsoft Learn: View available backups in Microsoft Entra Backup and Recovery (Preview)
- Microsoft Learn: Backup, difference report, and recovery model in Microsoft Entra Backup and Recovery (Preview)
