senn-techEigene Microsoft-365-Sicherung mit Wiederherstellung per Klick
Referenzkunde: Logistik- und Handelsgruppe in Tirol · ~100 Mitarbeiter · 4 Standorte
Kundendaten in Texten und Bildern sind neutralisiert.
Ausgangslage
Microsoft hält die Infrastruktur von Microsoft 365 am Laufen, die Inhalte schützt das nicht vor einem Löschfehler. Wer ein Postfach, eine Datei oder einen Teams-Chat versehentlich löscht, hat nach der Aufbewahrungsfrist keine zweite Kopie. Die Gruppe nutzte dafür ein zugekauftes Backup-Produkt.
Wir wollten die Wiederherstellung selbst in der Hand haben: wo die Daten liegen, wer sie zurückholen darf und was das kostet.
Das Schwierige daran
Ein Backup ist erst eines, wenn man daraus wiederherstellen kann. Deshalb stand der Wiederherstellungstest am Anfang: Im September 2026 haben wir eine OneDrive-Datei und eine einzelne Mail aus der Sicherung zurückgeholt.
Microsoft drosselt Abfragen je App. Der erste volle Abzug über Postfächer, Dateien und Chats dauert deshalb Tage, wir haben sieben bis zehn Tage eingeplant. Die Läufe gehen nacheinander, nicht parallel.
Schreibrechte für Postfächer vergeben wir nur über die Exchange-Rollen für Anwendungen, begrenzt auf die Postfächer der Gruppe. Für Dateien und Sites gibt es Schreibrechte bei Microsoft nur für den ganzen Mandanten. Das haben wir akzeptiert und dokumentiert.
Lösung
Wir haben die offene Sicherungs-Engine Atlas (Version 5.2.1) als Fork übernommen und eine eigene Konsole davorgebaut, mit Zeitplan, Suche, Vorschau und Wiederherstellung. Die Daten liegen auf einem ZFS-Speicher auf dem Backup-Server der Gruppe.
Zurückholen geht auf drei Wegen: in den Originalordner, in einen eigenen Ordner namens Restored oder als Download. Eine Mail kommt als .eml, mehrere als .zip, eine Datei als die Datei selbst.
Wie es gebaut ist
Die Konsole läuft in einem Container auf dem Backup-Server und ist nur über den Reverse Proxy erreichbar. Eine Firewall-Regel lässt Verbindungen auf ihren Port nur von dort zu. Die Anmeldung braucht Passwort und TOTP, eine Sitzung endet nach 30 Minuten Ruhe.
Sicherungsdaten und Datenbank liegen auf getrennten ZFS-Datasets. Ein Timer legt stündlich einen Snapshot an und behält 24 stündliche, 30 tägliche und 104 wöchentliche.
Im Betrieb
Jeder Lauf meldet sein Ergebnis per Mail an die Verantwortlichen, mit Dauer und Fehlern. Eine unterbrochene oder übersprungene Sicherung zählt als Fehler und nicht als Hinweis.
Neue Versionen werden erst eingespielt, wenn kein Sicherungslauf aktiv ist. Ein Skript wartet darauf und bricht ab, wenn es zu lange dauert.
Die Sicherheit haben wir im Oktober 2026 in drei Prüfläufen untersucht. Dazu kam ein Wiederherstellungstest, den die Sicherung bestanden hat.
Ergebnis
Im Oktober 2026 liegen rund 750 GB im Sicherungsspeicher. Vier Dienste werden jede Nacht gesichert, der Speicher legt stündlich Snapshots an. Ein Mitarbeiter der IT hat die Wiederherstellung selbst getestet.
Was wir daraus gelernt haben
Der erste Wiederherstellungstest sah wie ein Fehlschlag aus. Die Mail war zurück, lag aber in einem Unterordner namens Restored, und der Ordner an der gewohnten Stelle war leer. Die Wiederherstellung war richtig, die Konsole hatte es nur nicht gesagt. Seitdem nennt sie Zielordner und Anzahl der Objekte, und es gibt die Wiederherstellung in den Originalordner.
Eine Kachel zeigte 145 GB geschützte Daten, tatsächlich waren es rund 650 GB. Sie hatte den neuesten Snapshot gezählt statt der ganzen Kette.
Andere Projekte aus dem Betrieb
SIEM & Security-Monitoring mit Echtzeit-Korrelation
Logs aus der ganzen Firma an einem Ort, und nur die Alarme, die zählen.
Migration von VMware zu Proxmox
Raus aus der Lizenzfalle: 6-Knoten-HA-Cluster über zwei Standorte, migriert im laufenden Betrieb.
Ähnliches Problem?
Erzähl uns, was du vorhast, ein kurzes Gespräch klärt, ob sich das rechnet.