Wissensbasis/Support & Zuverlaessigkeit/Speicherkontingente und Upload-Limits: Evidence braucht einen Zähler
03Support & Zuverlaessigkeit3 Min. Lesezeit

Speicherkontingente und Upload-Limits: Evidence braucht einen Zähler

Wie Tenant-Speicher, Warnhinweise, Upload-Sperren und die Purge nur für Platform Owner verhindern, dass Dokumente und Fotos zur stillen Rechnung werden.

ITAD-Evidence ist dateilastig: Fotos, Zertifikate, signierte Dokumente, Reports, Support-Anhänge, Evidence Packages. Speicher kann nicht ewig unsichtbar bleiben. Irgendwann muss die Plattform wissen, wie viel ein Tenant verbraucht und was am Limit passiert.

Was zählt

Der Speicherverbrauch eines Tenants umfasst operative Dateien in Supabase Storage: Dokumente, Fotos, Unterschriften, Evidence und verwandte Uploads. Avatare liegen separat. Der Verbrauch wird pro Tenant aufsummiert, damit Paketlimits und Admin-Speicheransichten über dieselbe Zahl reden. Das Paket setzt das Kontingent — 0 GB bei Free, 5 GB bei Starter, 25 GB bei Professional, unbegrenzt bei Enterprise — und ein Platform Admin kann es pro Tenant überschreiben, wenn der Vertrag etwas anderes sagt.

Warnungen

Die Plattform prüft den Verbrauch planmäßig gegen das Kontingent und sendet eine Speicherwarnung, wenn ein Tenant 80, 90 und 100 Prozent überschreitet, einmal je Schwelle. Das gibt Admins Zeit, den Verbrauch zu prüfen, das Paket zu erweitern oder echte Versehen aufzuräumen. Evidence sollte nicht scheitern, weil niemand den blinkenden Zähler bemerkt hat.

Upload-Sperre

Überschreitet ein Tenant sein Kontingent, werden neue Uploads auf den geschützten Pfaden mit dem Blocknamen storage_limit_exceeded gesperrt. Die Sperre ist explizit: Der User sieht, dass Speicher das Problem ist, statt eines mysteriösen Upload-Fehlers. Mysteriöse Upload-Fehler sind die Art, wie Support-Queues Zähne bekommen.

Die Admin-Ansicht

/admin/storage gibt Platform Staff das Bild über alle Tenants: Gesamtbytes und Dokumentzahl, Zahl der Tenants, Verbrauch je Tenant mit Kontingentbearbeitung in GB, die größten Dateien, eine Aufschlüsselung nach Dateityp, Bucket-Übersicht sowie eine Wachstums- und Kostenprognose. Die Speichereinstellungen liegen auf derselben Seite — maximale Dateigröße in MB, Ablaufzeit signierter URLs, erlaubte MIME-Typen und die TTLs für Fotos, Dokumente, Evidence und ESG-Dateien. Storage Health listet nicht verknüpfte Dokument-Records, verwaiste Dateien und fehlende Dateien, lädt Zeilen in begrenzten Schritten bis 200, und eine Aufräumaktion entfernt diese drei Kategorien Schutt. Die Billing-Einstellungen des Tenants zeigen den Paketkontext, den der Tenant sieht. Zusammen verbinden sie technischen Speicher mit kommerziellen Grenzen, ohne jedes PDF in eine Finanzdebatte zu verwandeln.

Die Purge

Pro Tenant gibt es die Aktion „Speicher löschen“, und sie ist ein echtes Offboarding-Werkzeug, kein Platzhalter. Nur ein Platform Owner darf sie ausführen; jede andere Plattformrolle bekommt eine serverseitige Ablehnung, und es wird nichts gelöscht. Der Dialog lädt zuerst eine Vorschau dessen, was genau ginge — nicht verknüpfte Dokument-Records, Records mit fehlenden Dateien und verwaiste Objekte, mit Zählungen —, verlangt dann den exakten Namen der Organisation und schaltet den roten Button erst frei, wenn es etwas zu löschen gibt und der Name passt. Dokumente mit lebendem Geschäftsrecord werden nicht gezählt und nicht angefasst; die Purge entfernt Speicherschutt, nicht Evidence. Das Ergebnis wird fail-closed ins Activity Audit geschrieben, mit den Zählungen; kann das Log nicht geschrieben werden, findet die Purge nicht statt. Es gibt kein Rückgängig. Vorschau, Name, Button, Zeile. In dieser Reihenfolge, jedes Mal.