SharePoint Online Speicher voll — Playbook

Typisches Kundensignal: „Andre/Chef bekommt jeden Tag eine Mail, dass SharePoint-Speicher voll ist — wir haben doch schon gelöscht.” Absender der echten Mail ist no-reply@sharepointonline.com, Betreff „Ihre Organisation hat nicht mehr genügend SharePoint Online-Speicherplatz.”, Message-ID enthält odspnotify. Nicht mit Phishing verwechseln (siehe unten).

Warum SharePoint voll wird (Stand 2026-04)

  • Tenant-Pool-Quota = 1 TB + 10 GB pro lizensiertem User bei M365 Business Basic/Standard/Premium und E1/E3/E5. Bei Vibe Factory (~11 User) ergibt das ≈1114 GB Tenant-Quota.
  • Teams-Dateien landen in SharePoint, nicht separat. Jedes Team hat eine eigene Site Collection. Grosse Event-Agenturen mit Video/Foto-Assets brennen das schnell durch.
  • Versions-Historie frisst mit — Default sind 500 Versions pro Datei, jede Version zählt voll gegen die Quota. Ein 2 GB-Video mit 20 Bearbeitungen = 40 GB.

Diagnose in dieser Reihenfolge

Schritt 1 — Ist die Mail echt oder Phishing?

Echte Microsoft-Mail: Absender exakt no-reply@sharepointonline.com, keine ausgehenden Links ausserhalb *.sharepoint.com / microsoft.com, Message-ID enthält odspnotify und die korrekte Tenant-GUID. Phishing-Varianten zur Vibe-Factory-Zeit Jan 2026: Absender spoofed Hosting-Server wie business150.web-hosting.com, Link zu zufälliger Drittdomain (z.B. federationavocats.net), schreibt „lONOS” mit kleinem L. Bei Phishing → Inbox-Rule in M365, kein Storage-Problem.

Schritt 2 — Wer ist betroffen?

  • Tenant-Gesamtquota voll → tägliche Mail an alle globalen Admins + Site-Collection-Admins. Diagnose via SharePoint Admin Center Site-Collections → nach Speicher sortieren, Top-Kandidaten identifizieren.
  • Einzel-User-OneDrive voll → andere Mail („Dein OneDrive ist fast voll”). Läuft separat.
  • Einzelne Site-Quota (selten, nur wenn manuell gesetzt) → Admin Center zeigt’s.

Schritt 3 — Wo versteckt sich der Speicher?

Reihenfolge nach Häufigkeit:

(a) Second-Stage-Papierkorb („Site Collection Recycle Bin”) — der häufigste Grund warum Löschen scheinbar nichts bringt. Ablauf: User löscht → Stage 1 (User-Papierkorb, 93 Tage). User leert Stage 1 → Stage 2 (nur Site-Admin sichtbar, weitere 93 Tage). Beide Stufen zählen gegen die Quota. Direktlink pro Site: https://<tenant>.sharepoint.com/sites/<site>/_layouts/15/AdminRecycleBin.aspx. Als IT-Admin siehst du Stage 2, normale User nicht.

(b) Versions-Historie — Default 500 Versions, oft voll bei häufig bearbeiteten Grossdateien. Pro Datei: Rechtsklick → „Version history”. Per Site reduzieren via Site Settings → Versioning. MS-Doku: Enable and configure versioning.

(c) Preservation Hold Library — versteckte Library die entsteht wenn eine Retention Policy aktiv ist. Gelöschte Files werden dorthin kopiert und bleiben bis zur Retention-Laufzeit. Erreichbar via https://<site>/PreservationHoldLibrary. Nur relevant wenn Compliance/Retention-Policies gesetzt sind.

(d) Live-Füllstand pro Ordner — über Storage Metrics: https://<site>/_layouts/15/storman.aspx. Zeigt Top-Ordner nach Grösse und ist live, nicht gecached.

Fix — Schritt für Schritt

  1. Im SharePoint Admin Center die fetteste Site identifizieren — meist das Team mit Events/Videos.
  2. In die Site einloggen als Site-Admin (oder Tenant-Admin).
  3. Stage 1 leeren (oben rechts „Recycle Bin” → „Empty recycle bin”). Das schiebt alles in Stage 2.
  4. Stage 2 leeren (unten am Recycle-Bin „Second-stage recycle bin” → alles markieren → „Delete”). Das gibt erst den Speicher frei.
  5. Versions-Historie zurückschneiden falls nötig: Site Settings → Site Collection Features → „Manage Site Collection Features” → Versioning auf z.B. 10 zurück. Bereits vorhandene Versions müssen manuell oder per PowerShell (Remove-PnPFileVersion) entfernt werden — neue Policy wirkt nur für die Zukunft.

Verifikation

  • Live-Check pro Site: storman.aspx zeigt direkt den neuen Wert.
  • Admin-Center-Report aktualisiert nur alle 24-72 Stunden (MS-Doku: SharePoint site usage). Nicht wundern wenn der Wert am nächsten Tag noch alt aussieht — das ist Cache, kein Bug.
  • Härtester Indikator: Die tägliche SharePoint-Warn-Mail hört auf, sobald die Tenant-Quota unter ~90 % fällt. Wenn sie 3 Tage nach dem Aufräumen noch kommt → nicht genug, weiter an Versions-Historie oder andere Sites.

Wenn Aufräumen nicht reicht — Kostenoptionen

OptionKosten (Stand 2026-04)Wofür
Microsoft 365 Extra File Storage0,21 $/GB/Monat (~170 €/TB/Monat) (Preisliste)bleibt aktiv in SharePoint, nahtlos für Teams-Nutzer
Externer Cold-Storage (Beispiel OwnCloud self-hosted)~30 €/Monat für 1 TBArchiv für alte Event-Assets, ~5-6x günstiger pro TB
Nextcloud / Hetzner Storage Box~4 €/TB/Monat (Hetzner Storage Box 1 TB)Reines Cold-Backup, keine Team-Integration
Lizenz-Upgrade+10 GB pro zusätzlichem Usernur sinnvoll wenn eh User dazukommen

Empfehlung für Event-Agenturen: Policy „Events >12 Monate → Archiv”, einmalige Aufräum-Session, danach monatliche Rotation. Technisch zu lösen via Power Automate Flow oder manueller Rhythmus.

Typische Fallstricke

  • „Ich bin doch Admin und sehe nichts mehr” ≠ Speicher frei. Dateien sind aus dem Ordner verschwunden, liegen aber in Stage-2-Recycle-Bin. Immer beide Papierkörbe prüfen.
  • Cache im Admin Center. Anzeige ist 24-72 h alt. Live-Wert nur via storman.aspx.
  • Ein Teams-Channel = eine Site. Beim Aufräumen alle Team-Sites durchgehen, nicht nur die „Hauptsite”.
  • Private Channels haben eigene Sites. Die tauchen im SharePoint Admin Center unter eigenen Site-URLs auf.
  • Sync-Clients hängen nach Cleanup. OneDrive/Teams-Clients können minuten- bis stundenlang falsche Werte anzeigen. Bei Zweifel Browser-Version nutzen.

Zugriff per API (für zukünftige Automatisierung)

Unser mcp-m365 (siehe m365) kann pro Site Drive-Quota abfragen und Recycle-Bin-Inhalt listen — wenn die App entweder Sites.FullControl.All hat oder per Sites.Selected explizit auf die betreffenden Sites gegrantet wurde. Für Kunden-Audits sinnvoll als wiederkehrender Report, für einmalige Cleanup-Aktionen schneller direkt im Browser.