Speicherplatz optimieren: So schaffen Sie Platz in der Cloud

Cloud-Speicheroptimierung spart typischerweise 30–60 % der Rechnung durch vier Maßnahmen: verwaiste Daten löschen, identische Objekte deduplizieren, textlastige Inhalte komprimieren und kalte Daten in Glacier, Azure Archive oder B2 auslagern. Ein 100-TB-AWS-Bucket zu 2.300 EUR/Monat fällt nach der Optimierung oft auf 800 EUR/Monat — ohne eine einzige benötigte Datei zu verlieren. Die Arbeit ist meistens unspektakulär — inventarisieren, analysieren, Lifecycle-Regeln anwenden — aber die Einsparungen summieren sich monatlich. Beginnen Sie mit Messung, nicht mit Komprimierung.

Prüfen, bevor Sie kürzen

Führen Sie S3 Inventory, Azure Storage Analytics oder GCS-Bucket-Sperr-Berichte aus, um ein Manifest jedes Objekts zu erstellen: Key, Größe, letztes Änderungsdatum, Storage-Klasse und Tags. Laden Sie es in Athena, BigQuery oder DuckDB und fragen Sie ab.

Typische Befunde in einem nicht optimierten Bucket:

• 20–40 % der Objekte wurden über 90 Tage lang nicht zugegriffen (Kandidaten für kalte Ebene)
• 5–15 % sind genaue Duplikate per SHA-256-Hash
• 10–20 % sind verwaist — die Anwendung, die sie erstellt hat, ist weg
• 30–50 % sind Text/Logs/JSON, die sich mit zstd 3:1 komprimieren lassen

Sie können nicht reparieren, was Sie nicht gemessen haben. Planen Sie einen Tag für das erste Audit ein und Sie wissen, wo Sie den nächsten Monat der Optimierung verbringen sollen.

Zuerst den offensichtlichen Abfall löschen

Bevor Sie sich etwas Ausgefeilterem widmen, löschen Sie, was nicht existieren sollte. Häufige Übeltäter:

• Unvollständige mehrteilige Uploads (S3 hält diese bis zum expliziten Abbruch, manchmal jahrelang)
• Leere Objekte (null Bytes, aber berechnete Metadaten)
• Log-Dateien, die älter als die Aufbewahrungsrichtlinie sind
• Temp-Dateien (.tmp, ~$*, *.bak, .DS_Store, Thumbs.db)
• Testdaten aus gestarteten, aber vergessenen Experimenten

Führen Sie aws s3api list-multipart-uploads aus und brechen Sie alles über 7 Tage alt ab — eine Lifecycle-Regel mit AbortIncompleteMultipartUpload automatisiert das dauerhaft. Für S3 eine Regel:

Filter: prefix ""
AbortIncompleteMultipartUpload: DaysAfterInitiation: 7

Verwaiste mehrteilige Uploads auf Petabyte-Buckets haben Unternehmen Tausende monatlich gekostet.

Deduplizierung: Datei-Level vs. Block-Level

Datei-Level-Dedup entfernt identische Objekte — gleicher Hash, gleiche Bytes. Werkzeuge wie rdfind, fdupes und jdupes scannen Verzeichnisse und melden Duplikate. Für Cloud-Buckets verarbeiten Sie die Inventar-CSV, gruppieren nach SHA-256 und behalten eine kanonische Kopie pro Hash. Ersetzen Sie Duplikate durch Zeiger (eine kleine JSON-Datei, die den kanonischen Key referenziert) oder löschen Sie sie einfach, wenn sie nicht referenziert werden.

Block-Level-Dedup ist das, was Speichersysteme wie ZFS, Btrfs und zweckgebaute Backup-Produkte (Veeam, Commvault, Rubrik) tun. Sie teilen Dateien in 4–128-KB-Blöcke auf, hashen jeden Block und speichern jeden eindeutigen Hash einmal. Ein VM-Backup-Set könnte auf Block-Ebene 90 % redundant sein und eine 10:1-Komprimierung ergeben. Das ist wichtig für Backup-Buckets, aber selten für allgemeinen Dateispeicher.

Komprimierungsstrategie nach Dateityp

Nicht jede Datei komprimiert. Ein JPEG, MP4 oder ZIP ist bereits komprimiert; gzip dagegen zu laufen verschwendet CPU und bringt nichts. Aber textlastige Formate schrumpfen drastisch:

• JSON-Logs: 80–90 % Reduktion mit gzip, 85–92 % mit zstd
• CSV-Exporte: 75–85 %
• .docx (bereits ein Zip): 5–10 % (überspringen)
• .xlsx: 10–15 % (überspringen)
• .pdf: 0–5 % (überspringen — PDFs haben interne Komprimierung)
• SQL-Dumps: 85–90 %

Verwenden Sie zstd für moderne Pipelines — es dekomprimiert 2–3-mal schneller als gzip bei ähnlichen Verhältnissen. Für Logs, die nach S3 rotieren, spart eine logrotate-Konfiguration mit compress_program=zstd sowohl Bandbreite als auch Speicher. Komprimieren Sie niemals ein bereits komprimiertes Format; der 0,5-%-Gewinn ist die CPU-Zeit nicht wert.

Tiering nach Zugriffsmuster

Heiße Daten gehören in schnellen Speicher; kalte Daten in günstigen Speicher. S3 Intelligent-Tiering automatisiert das: nach 30 Tagen ohne Zugriff wechseln Objekte in Infrequent Access (0,0125 USD/GB); nach 90 Tagen Archive Instant; nach 180 Deep Archive. Der Dienst berechnet 0,0025 USD pro 1.000 überwachte Objekte — kleine Dateien unter 128 KB lohnen den Overhead nicht.

Für deterministischere Kontrolle schreiben Sie explizite Lifecycle-Regeln:

• Tag 30: Standard → Standard-IA
• Tag 90: Standard-IA → Glacier Instant Retrieval
• Tag 365: Glacier IR → Glacier Deep Archive
• Tag 2555: Löschen (außer bei legal-hold-Tag)

Regeln gelten automatisch für alle neuen Uploads. Ein Bucket mit 100 TB gleichmäßig über verschiedene Altersgruppen verteilt kann 1.500 EUR/Monat gegenüber dem Belassen in Standard sparen.

Overhead kleiner Dateien handhaben

Jede Cloud berechnet eine Mindestabrechenbare Objektgröße. S3 Standard-IA berechnet für mindestens 128 KB, auch wenn das Objekt 4 KB hat; Glacier Instant Retrieval dasselbe; Glacier Flexible und Deep Archive haben 40 KB Pro-Objekt-Metadaten zu Standard-IA-Preisen.

Ein Bucket mit 10 Millionen 4-KB-Dateien in Standard-IA zahlt für 1,28 TB statt 40 GB. Lösung: kleine Dateien in monatliche TAR- oder ZIP-Archive packen, bevor sie getiered werden. tar czf 2026-12-logs.tar.gz logs/2026-12/ ergibt ein Objekt statt Tausende. Halten Sie einen parallelen Index (CSV mit Dateiname → Offset) für die Abfrage vor.

Bild- und Videooptimierung

Medien dominieren oft den Speicher. Konvertieren Sie veraltete JPEGs nach WebP (30 % kleiner) oder AVIF (50 % kleiner) mit cwebp oder avifenc. Für Video encodieren Sie alte H.264-MP4s nach H.265 (HEVC) oder AV1 — ein 1-GB-1080p-H.264-Video wird 400 MB in H.265 bei keinem sichtbaren Qualitätsverlust.

Für bildintensive CMS-Seiten führen Sie eine einmalige Batch-Konvertierung mit imagemagick oder ffmpeg durch, halten Originale in Deep Archive und liefern die optimierten Versionen. Werkzeuge wie Cloudflare Images und AWS CloudFronts Image Optimizer erzeugen Varianten on the fly, sodass Sie eine kanonische Kopie speichern und je nach Anfrage in der Größe angepasste, neu encodierte Versionen liefern.

Duplikaterkennung über Cloud-Silos hinweg

Unternehmensumgebungen haben oft dieselben Dateien über OneDrive, Google Drive, Dropbox und ein SharePoint verstreut. Echte Optimierung bedeutet, Silo-übergreifende Duplikate zu finden. Werkzeuge wie Varonis, Egnyte und rclone (mit --track-renames und Prüfsummen-Vergleich) können Dateien über Anbieter hinweg hashen und Duplikate markieren.

Für ad-hoc-Konsolidierung — das Zusammenführen der verstreuten Kopien von jahresbericht-2024.pdf in einen kanonischen Ort — spart ein dediziertes Übertragungswerkzeug den Umweg über einen Laptop. HexaTransfer verschiebt Dateien bis 10 GB mit AES-256-GCM-Verschlüsselung direkt zwischen Personen, sodass Sie Duplikate konsolidieren können, ohne sie in ein weiteres Silo hochzuladen.

Die Veränderung messen

Nach der Optimierung erneut messen. Storage Lens (AWS), Cost Management (Azure) oder GCPs Kostenaufschlüsselung sollte die Reduktion zeigen. Wenn die Rechnung nicht gefallen ist, ist irgendetwas in die falsche Richtung gegangen — prüfen Sie auf Lifecycle-Regeln, die Objekte zurück in Standard gewechselt haben (das passiert), oder unbeabsichtigte Replikation, die den Speicher dreifach über Regionen repliziert hat.

Setzen Sie eine monatliche Erinnerung zur Überprüfung des Speicherwachstums. Ein Bucket, der ohne offensichtlichen Geschäftsgrund um 10 % pro Monat wächst, sammelt meist Abfall an. Früh erkennen — das vierteljährliche 2-Stunden-Ritual — schlägt ein panisches Optimierungsprojekt nach einer 50.000-EUR-Monatsüberraschung.

Jetzt kostenlos testen auf hexatransfer.com — kein Konto, max. 10 GB.