SharePoint-Archivierung: 7 Engineering-Learnings

Die Kundenanforderung aus Teil 1 klang zunächst überschaubar: abgeschlossene SharePoint-Projekte zusätzlich in eine vom Kunden administrierte Azure-Subscription kopieren und dort direkt zugänglich machen.

Ein Download-und-Upload-Skript hätte dafür eine Demo geliefert. Ein belastbares Archiv entstand erst, als wir die unangenehmen Fragen beantworteten:

• Was bedeutet „vollständig“, wenn eine Bibliothek nicht gelesen werden kann?
• Was passiert, wenn der Browser geschlossen wird oder eine Antwort verloren geht?
• Wie verhindert man doppelte oder überschriebene Archivobjekte bei Retries?
• Wie beweist man, dass im Blob wirklich dieselben Bytes liegen?
• Wer entscheidet über Erfolg, wenn Workflow, Manifeste, Report und Registry unterschiedliche Zustände zeigen?

Die folgenden sieben Erkenntnisse waren für die Entwicklung wichtiger als die Wahl einzelner Azure-Komponenten.

1. Ein Browser-Request ist kein Archivierungsauftrag

Ein früher Ablauf führte den Preflight im Kontext der Webanfrage aus. Das wirkte bequem: Der Administrator klickt auf „Archivieren“, die Anwendung ermittelt den Scope und zeigt das Ergebnis. Bei großen Sites entstand dadurch jedoch die falsche Kopplung. Ein geschlossenes Browserfenster, ein Proxy-Timeout oder ein verlorener Response durfte keinen fachlich gültigen Start beenden.

Wir haben den Start deshalb in zwei Verantwortungen getrennt:

1. Die Webanwendung nimmt den Auftrag an, persistiert eine eindeutige Request-ID und antwortet schnell.
2. Eine Durable Function führt Discovery, Planerstellung, Transfer und Abschluss unabhängig vom Browser aus.

Auch ein verlorener Start-Response darf keinen zweiten Lauf erzeugen. Aus der Correlation-ID entsteht deshalb eine deterministische Start-ID. Ein erneuter Request liefert denselben Vorgang zurück, statt parallel einen weiteren anzulegen.

Learning: Bei lang laufenden Geschäftsprozessen bestätigt die Webanfrage nur die Annahme. Der Prozess selbst braucht eine dauerhafte Identität und einen eigenen Lebenszyklus.

2. „Nicht gefunden“ darf niemals „leer“ bedeuten

Bei großen SharePoint-Sites ist Discovery häufig der erste Engpass. Tiefe Ordnerstrukturen, Paging, Bibliotheksfilter und SharePoint-Throttling machen eine vollständige Enumeration anspruchsvoller als den späteren Blob-Upload.

Eine langsame rekursive Ordnerabfrage wurde deshalb durch einen paginierten Hauptpfad ersetzt; die rekursive Variante bleibt nur als kontrollierter Fallback. Gleichzeitig behandelt die Lösung eine nicht auflösbare Bibliothek ausdrücklich als Fehler. Sie darf weder mit null Dateien noch als erfolgreich abgeschlossen im Plan erscheinen.

Der Preflight schreibt einen unveränderlichen Scope mit Site-, Bibliotheks- und Dateiidentitäten, Pfaden, Größen und Änderungsständen. Erst ein vollständiger Plan darf in die Verarbeitung wechseln.

Learning: Ein Archiv kann nur so vollständig sein wie seine Discovery. Unbekannter Scope ist kein leerer Scope, sondern ein blockierender Befund.

3. Mehr Parallelität ist nicht automatisch mehr Durchsatz

Die naive Optimierung lautet Task.WhenAll: möglichst viele Dateien gleichzeitig von SharePoint lesen und nach Azure schreiben. In einer echten Microsoft-365-Umgebung erhöht das jedoch gleichzeitig den Druck auf SharePoint, Function Runtime, Arbeitsspeicher, Verbindungen und Blob Storage.

Wir begrenzen deshalb parallele Dateioperationen und verarbeiten auch Sites in konfigurierten Batches. Der optimale Wert hängt von Dateigrößen, Tenant-Verhalten und Infrastruktur ab; er ist keine feste Produktwahrheit.

Das gleiche Prinzip gilt für die Finalisierung. SharePoint-Snapshots werden gebündelt geprüft, während die notwendige Blob-Read-back-Verifikation weiterhin pro Datei erfolgt.

Learning: Skalierung braucht Backpressure. Ein System wird nicht dadurch robust, dass es alle verfügbaren Arbeiten sofort startet.

4. Ein Retry darf keinen fachlichen Konflikt verstecken

Temporäre Netzwerk- oder Servicefehler rechtfertigen begrenzte Retries mit Backoff. Ein HTTP-Konflikt oder eine fehlgeschlagene ETag-Bedingung ist dagegen kein flüchtiger Fehler. Er bedeutet: Das Ziel existiert bereits oder der erwartete Zustand hat sich geändert.

Darum schreibt jeder Lauf in einen eigenen Pfad, und jedes Archivobjekt wird create-only angelegt. Ein Retry kann ein geprüftes Objekt nicht still überschreiben. Plan, Operation und Dateimanifeste verwenden ebenfalls bedingte Schreibvorgänge. Statusübergänge folgen Compare-and-Swap; ein veralteter Worker darf keinen neueren Zustand zurücksetzen.

Bei langen Jobs reicht ein Lease allein nicht aus. Verliert ein Worker seinen Lock, stoppt er über Cancellation und seine Fencing-Generation wird ungültig. Selbst wenn er später wieder Rechenzeit erhält, kann er keinen aktuellen Commit mehr ausführen.

Learning: Technische Wiederholung und fachlicher Konflikt sind zwei verschiedene Zustände. Nur der erste darf automatisch wiederholt werden.

5. „Upload erfolgreich“ beweist noch kein Archiv

Ein erfolgreicher Azure-Response bestätigt, dass ein Schreibvorgang angenommen wurde. Er beweist weder, dass die erwartete SharePoint-Datei gelesen wurde, noch dass das gespeicherte Objekt dieselben Bytes enthält.

Während des SharePoint-Downloads zählt und hasht die Lösung deshalb den Quellstream. Nach dem Upload öffnet sie das gespeicherte Blob-Objekt erneut und berechnet Länge und SHA-256 unabhängig ein zweites Mal. Erst wenn beide Werte und die erwartete Blob-Identität übereinstimmen, wechselt das Dateimanifest von „Ziel erstellt“ zu „Ziel verifiziert“ und schließlich zu „Manifest committed“.

Blob-Metadaten allein genügen dafür nicht. Die Prüfung liest tatsächlich die gespeicherten Bytes zurück.

Learning: Datenhoheit ist wertlos, wenn der Kunde die Vollständigkeit und Integrität seiner zusätzlichen Kopie nicht nachvollziehen kann.

6. SharePoint und Blob Storage bilden keine gemeinsame Transaktion

Besonders deutlich wird diese Grenze bei optionalen Quelländerungen. Zwischen Preflight, Upload und späterer Bereinigung kann ein Benutzer eine SharePoint-Datei verändern. Die archivierte Kopie wäre dann technisch korrekt, aber der alte Plan dürfte die neue Quelle nicht löschen.

Deshalb erfolgt eine destruktive Finalisierung in Phasen:

1. alle geplanten Dateien speichern und verifizieren,
2. alle Manifeste committen,
3. den vollständigen SharePoint-Snapshot erneut prüfen,
4. optionale Ersatzlinks erstellen und verifizieren,
5. Originale nur mit dem geplanten ETag bedingt löschen,
6. die Abwesenheit der betroffenen Quellen kontrollieren.

SharePoint bietet keine Transaktion über eine gesamte Site. Tritt während der bedingten Löschphase ein Fehler auf, können bereits gelöschte Dateien neben einer wegen ETag-Konflikt erhaltenen Datei stehen. Der Lauf wird dann nicht schöngerechnet, sondern als Unknown markiert und muss reconciliert werden.

Learning: Sicherheitsbarrieren reduzieren das Risiko, ersetzen aber keine Transaktion, die die Quellsysteme nicht anbieten.

7. Erfolg muss aus Evidence entstehen

Eine Durable Orchestration kann beendet sein, obwohl ein nachgelagerter Registry-Eintrag, ein Report oder ein Dateimanifest fehlt. Umgekehrt kann ein Blob vorhanden sein, obwohl sein fachlicher Commit nie abgeschlossen wurde.

Darum setzt kein einzelner Worker den endgültigen Erfolg. Reconciliation vergleicht:

• den bestätigten Plan,
• den Durable-Zustand,
• jedes Dateimanifest,
• die erwarteten Blob-Objekte,
• Job und Detailreport,
• Registry und Archivindex.

Vereinfacht gilt:

erwartet = committed + ausdrücklich übersprungen + fehlgeschlagen + ungeklärt

Succeeded ist nur zulässig, wenn keine fehlgeschlagenen oder ungeklärten Einträge bestehen und alle Pflichtnachweise zueinander passen. Widersprüche führen zu einem sichtbaren Nicht-Erfolgsstatus. Auch die Abschlussmail wird erst nach dieser Prüfung versendet.

Learning: In einem verteilten System ist „fertig“ eine Behauptung. Erst konsistente Evidence macht daraus einen nachweisbaren Zustand.

Wo die Architektur diese Entscheidungen trägt

Die Komponenten folgen aus diesen Problemen, nicht umgekehrt:

Administrator
    ↓ Microsoft Entra ID
ASP.NET Core Archive Workspace
    ↓ Managed Identity
Azure Durable Functions
    ├─ PnP.Core + Zertifikatsidentität → SharePoint Online
    ├─ create-only Archivobjekte       → Azure Blob Storage
    ├─ Plan, Manifeste und Reports     → Evidence-Container
    └─ Abschluss-/Fehlermeldung        → Datahub Mail

Die Webanwendung bleibt für Konfiguration, Start und Sichtbarkeit zuständig. Das Backend besitzt den langlebigen Prozess. Administratorzugriff, Web-to-Function-Identität und SharePoint-Zertifikatsidentität sind getrennt und werden fail-closed geprüft.

Ehrliche Produktgrenzen

Der Archive Workspace archiviert den aktuellen Byte-Stand unterstützter Dateien, kein vollständiges SharePoint-Abbild. Versionen, Listenmetadaten, Seiten, leere Ordner, Document Sets, OneNote-Strukturen, ursprüngliche ACLs, Workflows und Tenant-Konfiguration gehören nicht zu diesem Produktvertrag.

Auch die normale Browser- und ZIP-Nutzung ist nicht mit der Integritätsprüfung während der Archivierung gleichzusetzen. Der technische Nachweis entsteht im Archivlauf und im zugehörigen Report.

Fazit

Die anspruchsvolle Arbeit lag nicht im Verschieben von Bytes. Sie lag in den Übergängen: Browser zu Hintergrundprozess, SharePoint zu Blob Storage, Retry zu Konflikt, technisches Ende zu fachlichem Erfolg und verifizierte Kopie zu optionaler Quelländerung.

Genau diese Übergänge entscheiden, ob eine kundenkontrollierte Azure-Kopie nur vorhanden oder tatsächlich als Archiv belastbar ist.

Teil 3 zeigt, wie Administratoren diesen technischen Prozess fachlich freigeben, abnehmen und schrittweise ausrollen.