Selbst gehostete S3-Alternativen im Jahr 2026 (RustFS, Garage, SeaweedFS, Ceph)
Selbst gehostetes S3 nach MinIO wählen
Amazon S3 ist zum De-facto-Standard für die API von Objektspeichersystemen geworden. Nachdem das Open-Source-Repository von MinIO im April 2026 archiviert wurde, gibt es weiterhin sieben zuverlässige, selbst gehostete Alternativen.
Diese Optionen sind nicht austauschbar. Einige sind vollständige Objektspeicher-Engines, die ihr Datenlayout selbst verwalten; andere sind schlanke Gateways, die Dateien, die Sie bereits besitzen, bereitstellen. Diese Unterscheidung – nativer Speicher versus Dateisystem-gestütztes Gateway – entscheidet mehr über Backups, Wiederherstellung und Migrationen als jegliche Funktionsliste.
Dieser Artikel vergleicht RustFS, Garage, SeaweedFS, Ceph RGW, VersityGW, S3Proxy und rclone. Jeder Abschnitt behandelt das Speichermodell, die S3-Funktionsabdeckung, den Anwendungsbereich des Projekts und die Einschränkung, die in der Regel die Entscheidung trifft. Ein Entscheidungsfahrzeug für Single-Server- und Multi-Server-Deployments bildet den Abschluss des Artikels.
Für den größeren Kontext – Objektspeicher, Datenbanken, Suche und AI-native Datenschichten – siehe Dateninfrastruktur für KI-Systeme.
Vergleich selbst gehosteter S3-Speichersysteme
Die wichtigste Frage ist, ob ein verteiltes Objektspeichersystem oder eine S3-Schnittstelle vor dem bereits existierenden Speicher benötigt wird.
| Software | Speichermodell | Verteilt | S3-Kompatibilität | Einfache Dateien auf der Festplatte | Komplexität | Bestverwendung |
|---|---|---|---|---|---|---|
| RustFS | Nativer Objektspeicher | Ja | Hoch, getesteter Teilbereich | Nein | Niedrig bis mittel | Allgemeiner MinIO-Ersatz |
| Garage | Nativer Objektspeicher | Ja | Gut, schmaleres API | Nein | Niedrig bis mittel | Kleine verteilte Cluster |
| SeaweedFS | Verteilter Blob- und Dateispeicher | Ja | Hoch | Nein | Mittel | Riesige Dateianzahlen und gemischter Speicher |
| Ceph RGW | Ceph-Objektgateway | Ja | Hoch | Nein | Hoch | Große Speicherinfrastruktur |
| VersityGW | S3-Gateway über POSIX | Backend-abhängig | Gut | Ja | Niedrig | S3 über normale Dateien |
| S3Proxy | S3-Übersetzungsschicht | Backend-abhängig | Mittelmäßig | Ja mit filesystem-nio2 | Mittel | Gateway und Protokollübersetzung |
| rclone serve s3 | S3-Gateway | Backend-abhängig | Basis, experimentell | Ja mit lokalem Backend | Sehr niedrig | Einfache und leichte Deployments |
RustFS ist der direkteste Ersatz für eine konventionelle MinIO-Installation. Garage eignet sich für kleine verteilte Cluster. SeaweedFS und Ceph lösen breitere Speicherprobleme. VersityGW kann ein bestehendes POSIX-Dateisystem über S3 bereitstellen, während die Objekt-Payloads als gewöhnliche Dateien bleiben. Für eine Funktionsmatrix für Garage, MinIO und AWS S3 siehe Garage im Vergleich zu MinIO und AWS S3.
Zwei verschiedene Arten von S3-Speichern
Ein nativer Objektspeicher verwaltet sein Speicherlayout selbst:
RustFS, Garage, Ceph RGW und SeaweedFS gehören zu dieser Familie. Die Dateien, die auf den zugrunde liegenden Festplatten sichtbar sind, sind Implementierungsdetails, und Anwendungen sollten sie nicht direkt manipulieren.
Ein dateisystemgestütztes S3-Gateway hat ein anderes Verhältnis zum Speicher:
Bei Software wie VersityGW kann das Dateisystem die maßgebliche Darstellung bleiben. Ein Objekt wie:
s3://archive/documents/2026/report.pdf
kann direkt entsprechen:
/storage/archive/documents/2026/report.pdf
RustFS: Der nächstliegende MinIO-Ersatz
RustFS ist ein verteiltes Objektspeichersystem, das in Rust geschrieben und unter der Apache-2.0-Lizenz veröffentlicht wurde. Es bietet ein S3-orientiertes Betriebsmodell, das MinIO-Nutzern vertraut ist, was es zum ersten Projekt macht, das bei einem MinIO-Ersatz zu bewerten ist.
Die aktuelle S3-Implementierung umfasst die Operationen, die die meisten Anwendungen erwarten: Buckets, Objekte, Multipart-Uploads, bedingte Anfragen, Objekt-Metadaten, Tags, Versionierung, Lifecycle-Verwaltung, Object Lock, presignierte URLs, Bucket-Richtlinien, CORS, Benachrichtigungen, Replikationskonfiguration und serverseitige Verschlüsselung.
RustFS veröffentlicht eine S3-Kompatibilitätsmatrix, die ein getesteter Teilbereich und keine Behauptung der vollständigen Amazon S3-Abdeckung ist. Der am 9. August 2026 gegen den Commit 1e6f5f1e verifizierte Snapshot listet 455 implementierte Standardtests, 5 Lifecycle-Verhaltenstests, 17 nicht implementierte Standardtests und 270 ausgeschlossene Fälle, die die Kompatibilitätsprüfung nicht blockieren. Die ausführbaren Listen unter scripts/s3-tests sind die maßgebliche Quelle, wenn sich diese Zahlen ändern.
Wo RustFS zum Einsatz kommt
RustFS ist eine Kandidatin, wenn eine Anwendung einen geeigneten S3-Objektspeicher erwartet.
Typische Anwendungsfälle umfassen Anwendungsspeicherung, Backup-Repositories, Medienspeicher, KI- und Datenpipelinene Artefakte, interne S3-Infrastruktur, Kubernetes-Workloads und den Ersatz bestehender MinIO-Endpoints.
Es funktioniert mit AWS SDKs und gängigen S3-Clients. Anwendungen benötigen in der Regel einen benutzerdefinierten Endpoint, Zugangsdaten, Regionseinstellungen, wo erforderlich, und path-stylische Adressierung.
Die wichtige Einschränkung
RustFS verwaltet die Speicherdarstellung. Die Dateien unterhalb seines Datenverzeichnisses sind RustFS-interne Strukturen.
Das macht RustFS zur falschen Antwort, wenn die Anforderung lautet, dass jedes S3-Objekt eine gewöhnliche Datei bleibt, die Sie inspizieren, kopieren, rsync-synchronisieren oder ohne die Objektspeicher-Software wiederherstellen können. Diese Anforderung wählt ein dateisystemgestütztes Gateway.
Garage: Verteiltes S3 ohne Ceph-Maßstab
Garage ist ein S3-kompatibler, verteilter Objektspeicher für kleine und mittlere, selbst gehostete Installationen. Deuxfleurs entwickelt es unter der AGPL v3-Lizenz und betreibt es seit den ersten Projekt-Releases im Jahr 2020 produktionsreif.
Garage ist so konstruiert, dass es über mehrere gewöhnliche Server läuft, einschließlich Server an verschiedenen physischen Standorten. Replikation ist Teil des Designs.
Garage ist attraktiv, wenn Sie drei kleine Server haben, statt eines Racks mit dedizierter Speichertechnik. Ein funktionierender Einrichtungsleitfaden, von Docker über Cluster-Layout, Replikation und TLS über einen Reverse Proxy, befindet sich im Garage-Quickstart.
Wo Garage zum Einsatz kommt
Garage ergibt Sinn für Homelabs, kleine Hosting-Plattformen, geografisch verteilte Server, replizierte Backups und Cluster, bei denen Ceph übertrieben wäre.
Sein Umfang ist schmaler als der von AWS S3. Die Kompatibilitätstabelle von Garage lässt Bucket-Richtlinien, ACLs und Bucket-Versionierung aus. Wählen Sie Garage gegenüber RustFS, wenn lightweight Multi-Node-Replikation die primäre Anforderung ist. Wählen Sie RustFS, wenn breiteres S3-Verhalten und MinIO-ähnliche Anwendungskompatibilität wichtiger sind.
SeaweedFS: Mehr als ein Objektspeicher
SeaweedFS begann damit, riesige Zahlen an Dateien effizient zu speichern. Es ist heute eine verteilte Speicherplattform, die S3, ein FUSE-Dateisystem, WebDAV, SFTP und HDFS bereitstellt. SeaweedFS 4.48 wurde am 28. September 2026 veröffentlicht.
Volume-Server packen Blobs in Append-only-Volume-Dateien. Masters tracken Volumes statt einzelner Dateien. Ein Filer bereitstellt hierarchische Dateisystem-Semantik. Das Design zielt auf Workloads mit Millionen oder Milliarden relativ kleiner Objekte ab.
S3-Unterstützung
SeaweedFS dokumentiert Versionierung, Object Lock, Lifecycle-Regeln, Tagging, CORS, Checksums, presignierte URLs, Multipart-Uploads, Bucket-Richtlinien, IAM, STS und mehrere serverseitige Verschlüsselungsmodi.
Dasselbe Cluster kann S3-Tabelle-Buckets und eine integrierte Iceberg-REST-Katalog bereitstellen, sodass Spark, Trino, DuckDB und ähnliche Engines Iceberg-Tabellen ohne einen separaten Hive Metastore oder Glue verwenden können. Das Beispielprojekt für die Ein-Kommando-S3-Nutzung lauscht auf Port 8333.
Wo SeaweedFS zum Einsatz kommt
Betrachten Sie SeaweedFS für Web-Crawler und Archive, Bild- und Dokument-Repos, Milliarden kleiner Objekte, Data Lakes, gemischte S3- und Dateisystem-Workloads und Speicher, der durch das Hinzufügen von Volume-Servern wächst.
Es gibt mehr Komponenten zum Verstehen als bei einer geraden RustFS-Installation. SeaweedFS kann Dateisystem-Semantik durch seinen Filer und FUSE-Mount bereitstellen, aber Objekte werden innerhalb seines Volume-Formats gespeichert. Es erfüllt nicht die Anforderung, dass jedes S3-Objekt eine unabhängige gewöhnliche Datei im Host-Dateisystem bleibt.
Ceph RGW: Die Infrastruktur-Maßstab-Option
Ceph ist breiter als S3-Speicher. Ein Cluster kann Blockgeräte über RBD, ein Dateisystem über CephFS und Objektspeicher über RADOS Gateway (RGW) bereitstellen. RGW präsentiert eine S3-kompatible API, die durch RADOS unterstützt wird.
Ceph unterstützt Replikation, Erasure Coding, Fehldomains, mehrere Gateways, Multisite-Deployments, Zugriffsrichtlinien und Cluster-Management-Tools.
Wo Ceph zum Einsatz kommt
Ceph ergibt Sinn, wenn Objektspeicher nur ein Teil einer größeren Speicherplattform ist: Kubernetes-Dauervolumen, virtuelle Maschinenfesteplatten, geteilte Dateisysteme, große S3-Repositories und Cluster, die explizite Fehldomains benötigen.
Für einen einzelnen Server mit mehreren Terabytebytes ist die Installation von Ceph nur, um einen S3-Endpoint zu erhalten, schwer zu rechtfertigen. Wenn Sie bereits Ceph betreiben, ist RGW die offensichtliche S3-Wahl. Wenn nicht, erreichen RustFS oder Garage nützlichen Objektspeicher mit weniger Mechanismus.
VersityGW: S3 über gewöhnliche Dateien
VersityGW ist die Option, die zu bewerten ist, wenn das Dateisystem selbst wichtig ist. Es ist ein Apache-2.0-lizenziertes S3-Gateway, das POSIX-Dateisysteme, ScoutFS, Azure Blob Storage, andere S3-Dienste und benutzerdefinierte Backends bereitstellen kann.
Sein POSIX-Backend mappt S3-Buckets und Objekte auf Verzeichnisse und Dateien. Zum Beispiel:
s3://website-assets/images/logo.png
wird auf einen Pfad wie:
/storage/website-assets/images/logo.png
gemappt.
Die logo.png-Payload bleibt eine normale Datei.
Warum einfache Dateien nützlich sind
Sie können den Speicher mit gewöhnlichen Unix-Tools inspizieren:
find /storage -type f
du -sh /storage/*
Sie können ein Objekt ohne den S3-Server lesen:
cat /storage/archive/2026/source.html
Konventionelle Dateisystem-Backup-Tools gelten direkt: rsync, restic, borg, tar und zfs send. Wenn die Gateway-Software verschwindet, sind die Payloads immer noch Dateien in einem Verzeichnisbaum.
S3-Metadaten auf einem POSIX-Backend
S3-Metadaten passen nicht allein in eine POSIX-Datei. VersityGW speichert sie standardmäßig in erweiterten Attributen (xattrs). Seit März 2026 ist die Objekt-Metadaten ein einzelner user.metadata xattr, der JSON hält, weil ein xattr pro Schlüssel Dateisystem-Schlüssellängenlimits traf. Ein versitygw utils convert-xattr-metadata-Befehl schreibt ältere pro-Schlüssel-Attribute um. Lesevorgänge fallen immer noch auf das alte Layout zurück, wenn user.metadata fehlt.
Dateisysteme ohne xattrs können --sidecar (oder VGW_META_SIDECAR) verwenden, um Metadaten in einem separaten Verzeichnisbaum zu halten. Das Projekt markiert Sidecar und --nometa als weniger getestet als xattrs. --nometa deaktiviert die Metadatenspeicherung und zielt auf schreibgeschütztes Hosting eines vorhandenen Datensatzes ab; Bucket-Richtlinien und ACLs sind Metadaten, daher sind sie in diesem Modus nicht verfügbar.
Objektversionen können in einem separaten Verzeichnis liegen. Das POSIX-Beispiel des Projekts gibt --versioning-dir für ältere Versionen an, während die aktuelle Payload auf ihrem natürlichen Pfad bleibt.
Das Ändern einer Datei hinter dem Gateway kann dazu führen, dass S3-Metadaten, einschließlich ETags, inkonsistent mit den neuen Bytes sind. Ein machbares Betriebsmodell ist:
Anwendungszugriff:
Lesen über S3
Schreiben über S3
Administratorzugriff:
Das Dateisystem direkt lesen
Das Dateisystem direkt inspizieren
Das Dateisystem direkt sichern
Vermeiden, Objekte hinter dem Gateway zu modifizieren
VersityGW 1.8.0, bereits die Version, auf die eine COSI-Treiber-Veröffentlichung im September 2026 abzielte, fügt einen eigenständigen IAM-Dienst (versitygw iam), STS AssumeRoleWithWebIdentity und IAM-Richtlinienbedingungen hinzu.
S3Proxy: Eine allgemeine Übersetzungsschicht
S3Proxy implementiert die S3-API und übersetzt Anfragen auf mehrere Backends: lokale Dateien, Azure Blob Storage, Google Cloud Storage, OpenStack Swift, SFTP und andere S3-Dienste. Es erfordert Java 17 oder neuer.
Der empfohlene On-Disk-Provider ist filesystem-nio2. Der ältere filesystem-Provider ist veraltet. Objektschlüssel werden zu Dateisystempfaden, und Metadaten verwenden benutzerdefinierte erweiterte Attribute, sodass die Payloads gewöhnliche Dateien bleiben.
Das Dateisystem-Backend verweigert Objektversionierung und serverseitige Verschlüsselung. Versionierung bleibt nicht unterstützt (supportsVersioning() ist false, und diese Anfragen bleiben HTTP 501), weil ein Versionslayout, das auf eine echte Festplatte geschrieben wird, zu einem Format würde, das das Projekt hätte beibehalten müssen. Serverseitige Verschlüsselung wird aus derselben Art von Grund verweigert: Die Meldung von AES256 über eine Klartextdatei, die jemand lesen kann, wäre eine falsche Behauptung. Das in-memory transient-nio2-Backend implementiert beides, und die Daten sterben mit dem Prozess. Die Projekt-README listet auch Bucket-Richtlinien, Objekt-Tagging und ACLs außer private und public-read als nicht unterstützt.
S3Proxy ist das Werkzeug, wenn Sie diese Übersetzung über Backends hinweg benötigen. Für ein gerades S3-zu-POSIX-Gateway ist VersityGW die kleinere Oberfläche.
rclone serve s3: Leichtgewichtig, aber experimentell
rclone serve s3 stellt ein rclone-Backend über eine S3-kompatible API bereit. Die Dokumentation kennzeichnet den Befehl immer noch als experimentell.
Für ein lokales Dateisystem:
rclone serve s3 \
--addr :9000 \
--auth-key ACCESS_KEY,SECRET_KEY \
local:/srv/s3
Ohne --addr bindet der Server 127.0.0.1:8080. --auth-key aktiviert Signature Version 4. Multipart-Uploads werden in Teilnummernreihenfolge zu einem temporären Objekt geschrieben und nach Abschluss in Position umbenannt, sodass ein fehlgeschlagener Upload ein vorhandenes Objekt nicht ersetzt.
Objekte, die über ein local-Backend geschrieben werden, werden zu Dateien unter diesem Pfad. Derselbe Befehl kann vor anderen rclone-Remotes stehen. Es ist eine vernünftige Wahl für interne Tools, ein Labor oder eine temporäre Migrationshüpfung. Es ist eine schwache permanente S3-Schicht für viele unzusammenhängende Produktionsanwendungen.
Was ist mit MinIO?
Das MinIO-GitHub-Repository wurde am 13. Februar 2026 archiviert, kurz wieder entarchiviert und am 25. April 2026 erneut archiviert. Es ist schreibgeschützt. Die Repository-Benachrichtigung verweist Betreibende auf AIStor, die kommerzielle Distribution von MinIO, und stellt fest, dass die Community-Edition nur als Quellcode verfügbar ist.
Eine bestehende MinIO-Installation kann weiterlaufen, insbesondere wenn sie isoliert ist und ihr Verhalten bereits verstanden wird. Die vollständige Zeitleiste, das operative Risiko und ein gestaffelter Migrationsplan befinden sich in MinIO CE im Jahr 2026.
Für das S3-Verhalten des Systems, das Sie vielleicht verlassen, dokumentiert MinIO als AWS S3-Alternative, wie MinIO auf S3 abgebildet wird. Der MinIO-Kommandozeilen-Spickzettel ist der Audit-Begleiter für ein Cluster, das noch läuft. Für eine neue Installation ist eine aktiv gewartete Alternative der Standard.
Einfache Dateien vs. nativer Objektspeicher
Verwenden Sie RustFS, Garage, SeaweedFS oder Ceph, wenn der Objektspeicher Dauerhaftigkeit, Metadaten, Verteilung und Layout kontrollieren sollte. Das kauft reichhaltigere S3-Semantik, Replikation oder Erasure Coding, horizontales Skalieren und Versionierung, wo das Projekt es implementiert. Der Preis ist die Abhängigkeit von der On-Disk-Darstellung der Engine.
Verwenden Sie VersityGW, S3Proxy oder rclone, wenn ein bestehendes Dateisystem maßgeblich bleiben soll. Das kauft einfache wiederherstellbare Dateien, konventionelle Backups, direkte Inspektion und Kompatibilität mit ZFS, XFS, ext4 und NFS. Verteilte Dauerhaftigkeit muss dann vom Dateisystem oder dem Speicherarray kommen, nicht vom S3-Prozess. Auf einem einzelnen Server oder einer NAS ist dieser Tausch oft der richtige.
Wahl des richtigen selbst gehosteten S3-Servers
Für einen einzelnen Server, der MinIO ähneln sollte, beginnen Sie mit RustFS.
Für drei oder mehr bescheidene Server, bei denen Replikation die Hauptanforderung ist und die Anwendung ohne Bucket-Richtlinien und Versionierung auskommen kann, wählen Sie Garage.
Für riesige Zahlen kleiner Objekte, gemischten Dateisystemzugriff oder einen Data-Lake-Workload, der zu Iceberg-Tabellen wachsen kann, betrachten Sie SeaweedFS.
Wenn dasselbe Cluster auch Blockgeräte und ein verteiltes Dateisystem bereitstellen muss, wählen Sie Ceph RGW.
Wenn die Anforderung spezifisch eine S3-API über gewöhnliche Dateien ist – eine NAS, ein Archiv, ein Dokument-Repository, ein Crawler oder ein Backup-Ziel – beginnen Sie mit VersityGW.
Wenn die Aufgabe darin besteht, S3 auf Azure, GCS, Swift, SFTP oder einen anderen S3-Dienst zu übersetzen, verwenden Sie S3Proxy.
Wenn das Deployment klein, temporär und in der Lage ist, einen experimentellen Server zu tolerieren, reicht rclone serve s3 möglicherweise.
Empfohlene Architektur für einen einzelnen Speicher-Server
Wenn Anwendungen die Daten nur über S3 erreichen sollen, besitzt RustFS die Objektschicht und das Dateisystem ist ein Implementierungsdetail:
Wenn die Dateien selbst das Gateway überleben müssen, halten Sie die Daten in einem POSIX-Baum:
In dem zweiten Design ist Redundanz ein ZFS-Spiegel, RAID, Snapshots, Dateisystem-Replikation oder ein konventionelles Backup-Tool. Der S3-Dienst kann ersetzt werden, ohne das Datenformat umzuschreiben.
Abschließende Gedanken
Gewartete, selbst gehostete S3-Systeme existieren nach wie vor, nachdem das öffentliche MinIO-Repository schreibgeschützt wurde. Die Wahl, die wichtig ist, ist, ob S3 die Bytes besitzt oder nur Dateien abdeckt, die bereits existieren. Jeder obige Vergleich folgt aus dieser Antwort.
