MinIO ist archiviert: S3-kompatibler Speicher zum Selbsthosten im Vergleich

Betreiben Sie MinIO als Backup-Ziel oder Anwendungsspeicher? WZ-IT prüft den Bestand, plant den Wechsel etwa zu SeaweedFS oder RustFS und übernimmt auf Wunsch den laufenden Betrieb. Bestand gemeinsam einordnen

MinIO war jahrelang die Standardantwort auf die Frage nach S3-kompatiblem Speicher im eigenen Haus. Diese Antwort gilt nicht mehr: Das öffentliche Repository ist archiviert, der letzte Push datiert vom 24. April 2026.

Das trifft viele Installationen, die still und zuverlässig laufen und deshalb niemandem auffallen. Wir haben MinIO in eigenen Beiträgen zur S3-Migration nach Hetzner selbst empfohlen. Diese Empfehlung gilt so nicht mehr, und dieser Beitrag zieht die Konsequenz.

Er ordnet ein, was genau passiert ist, wie dringend ein Wechsel ist und welche Alternativen tragen. Alle Angaben aus den Repositories, Stand 28. August 2026.

Inhaltsverzeichnis

• Was mit MinIO passiert ist
• Wie dringend ist ein Wechsel
• Die Alternativen im Überblick
• SeaweedFS
• Garage
• RustFS
• Ceph
• Die oft bessere Antwort: gar nicht selbst hosten
• Was beim Umzug tatsächlich Arbeit macht
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Was mit MinIO passiert ist

Der Rückzug lief in drei Schritten über gut ein Jahr:

Der letzte Push auf minio/minio datiert vom 24. April 2026. Zum Vergleich: SeaweedFS, RustFS und Ceph wurden am 24. August 2026 aktualisiert, also am Tag der Recherche für diesen Beitrag.

Das Unternehmen selbst ist aktiv und entwickelt sein kommerzielles Produkt AIStor weiter. Was endet, ist die frei verfügbare Ausgabe.

Wie tragfähig dieser Bruch für andere Projekte war, zeigt eine Entscheidung von außen: Kubeflow Pipelines hat seinen Standard-Objektspeicher nach MinIOs Rückzug auf SeaweedFS umgestellt.

Wie dringend ist ein Wechsel

Eine archivierte Software wird nicht über Nacht unsicher. Sie wird es mit der ersten Schwachstelle, für die niemand mehr eine Lösung veröffentlicht. Die Dringlichkeit hängt deshalb an der Erreichbarkeit, nicht am Datum.

Was in jedem Fall gilt: Der Bestand gehört erfasst. Wer nicht weiß, wo überall MinIO läuft, kann die Frage nicht beantworten. In gewachsenen Umgebungen steht es oft an drei Stellen, von denen zwei niemand mehr auf dem Schirm hat.

Die Alternativen im Überblick

Angaben aus den öffentlichen Repositories, Stand 28. August 2026.

Garage wird nicht auf GitHub entwickelt, sondern auf der eigenen Infrastruktur des Deuxfleurs-Kollektivs; die Sternezahl fehlt deshalb und wäre auch nicht vergleichbar.

SeaweedFS

SeaweedFS ist die naheliegendste Wahl für die meisten MinIO-Installationen. Existiert seit über zehn Jahren, steht unter Apache-2.0, hat viele Mitwirkende und wird aktiv gepflegt.

Ausgelegt ist es auf verteilte Ablage mit besonderer Stärke bei vielen kleinen Dateien, einem Fall, in dem klassische Objektspeicher oft schwächeln. Die S3-Schnittstelle ist ausgereift.

Die Umstellung von Kubeflow Pipelines auf SeaweedFS als Standard ist das belastbarste Signal für Tragfähigkeit, das ein Projekt in dieser Lage bekommen kann: eine Entscheidung von außen, unter Zeitdruck, mit vielen betroffenen Installationen.

Garage

Entwickelt vom Deuxfleurs-Kollektiv, unter AGPL-3.0, bewusst schlank gehalten. Der Zielfall sind mehrere Standorte, zwischen denen Daten redundant liegen sollen, ohne dass dafür ein System von Cephs Komplexität nötig wird.

Stärke: geringer Ressourcenbedarf, einfache Inbetriebnahme, ausgelegt auf geografische Verteilung. Grenze: kleineres Ökosystem, weniger auffindbare Lösungen für Sonderfälle, keine Weboberfläche im Umfang von MinIO.

RustFS

RustFS ist der jüngste Kandidat, in Rust geschrieben, unter Apache-2.0 und mit eingebauter Weboberfläche. Positioniert sich ausdrücklich als das, was MinIO vor der Lizenz- und Funktionsentwicklung war.

Mit 31.347 Sternen hat es schnell Aufmerksamkeit gefunden. Für den Umstieg ist es die vertrauteste Oberfläche. Die Einschränkung ist das Alter: Ein Projekt, das seit kurzem existiert, hat weniger produktive Betriebsjahre hinter sich als SeaweedFS oder Ceph, und genau darauf kommt es bei einem Speichersystem an.

Wer wegen der Aufgabe eines Projekts wechselt, sollte beim Nachfolger auf Beständigkeit achten und nicht nur auf Vertrautheit.

Ceph

Kein schlanker Ersatz, sondern ein vollständiges verteiltes Speichersystem für Block-, Datei- und Objektspeicher. Der S3-Zugang läuft über das RADOS Gateway.

Sinnvoll ist Ceph in genau einem Fall: wenn es ohnehin schon läuft. Wer unter Proxmox einen Ceph-Verbund für virtuelle Maschinen betreibt, bekommt Objektspeicher ohne zusätzliches System obendrauf.

Für reinen S3-Bedarf ohne bestehendes Ceph ist der Aufwand unverhältnismäßig. Der Ressourcenbedarf liegt deutlich über dem der schlanken Alternativen, und die Betriebskomplexität ist eine andere Größenordnung.

Die oft bessere Antwort: gar nicht selbst hosten

Ein Teil der MinIO-Installationen existiert nur, weil ein S3-Endpunkt gebraucht wurde und MinIO schnell aufgesetzt war. Für diesen Fall ist der ehrlichste Rat, den Betrieb nicht zu ersetzen, sondern abzugeben.

Objektspeicher bei einem europäischen Anbieter wie Hetzner kostet wenig, verursacht keinen Betriebsaufwand und löst die Frage nach Aktualisierungen dauerhaft. Wie sich das mit Hetzner Object Storage einrichten lässt, haben wir für AWS S3 und Azure Blob Storage beschrieben.

Selbst hosten bleibt richtig, wenn Daten das Haus nicht verlassen dürfen, wenn sehr große Mengen anfallen oder wenn der Speicher innerhalb einer abgeschotteten Umgebung liegen muss.

Was beim Umzug tatsächlich Arbeit macht

Die Daten müssen kopiert werden. Alle Kandidaten sprechen S3, aber keiner liest MinIOs Ablageformat. Der Umzug läuft über rclone oder ein gleichwertiges Werkzeug von Endpunkt zu Endpunkt. Der Platz muss dafür zweimal vorhanden sein oder es wird in Etappen gearbeitet.

Die Randbereiche der S3-Schnittstelle sind nicht überall gleich. Versionierung, Objektsperren, Lebenszyklusregeln und serverseitige Verschlüsselung werden unterschiedlich vollständig unterstützt. Wer eines davon nutzt, prüft es vor der Auswahl, nicht danach.

Zugangsdaten und Richtlinien werden neu angelegt. Benutzer, Schlüssel und Zugriffsregeln übertragen sich nicht. Das ist überschaubar, wenn es wenige sind, und Fleißarbeit, wenn über Jahre viele entstanden sind.

Backups sind ein Sonderfall. Wenn MinIO als Ziel eines Sicherungssystems dient, etwa für den Proxmox Backup Server, gehört zum Umzug ein Wiederherstellungstest aus dem neuen Ziel. Ein Backup, das nach dem Umzug nicht geprüft wurde, ist kein Backup.

Unser Vorgehen bei WZ-IT

Wir haben MinIO in eigenen Beiträgen empfohlen und korrigieren das. Diese Beiträge bekommen einen Hinweis, statt stehenzubleiben, als wäre nichts geschehen.

Bei bestehenden Installationen fragen wir zuerst nach der Erreichbarkeit und dem Zweck, nicht nach dem Nachfolger. Ein internes Backup-Ziel hat eine andere Dringlichkeit als ein Endpunkt am Netzrand.

Bei der Auswahl neigen wir zu SeaweedFS, weil Betriebsjahre bei Speichersystemen mehr wiegen als Vertrautheit der Oberfläche. Wo Ceph bereits läuft, nutzen wir dessen RADOS Gateway statt ein zweites System danebenzustellen. Und in einem guten Teil der Fälle empfehlen wir, den Objektspeicher gar nicht selbst zu betreiben.

Zum Umzug gehört bei uns immer ein Wiederherstellungstest aus dem neuen Ziel, bevor das alte abgeschaltet wird.

Weiterführende Guides

• AWS S3 zu Hetzner Object Storage migrieren - der Weg zu gehostetem Objektspeicher
• Azure Blob Storage zu Hetzner migrieren - dasselbe von Azure aus
• Proxmox Backup Server mit S3-Storage - Objektspeicher als Sicherungsziel
• Ceph unter Proxmox - wenn der Speicherverbund schon steht
• Managed Operations - Betrieb, Überwachung und geprüfte Wiederherstellung

Wissen Sie, wo überall MinIO bei Ihnen läuft? Wir erfassen den Bestand, bewerten die Dringlichkeit und begleiten den Wechsel einschließlich Wiederherstellungstest. Termin vereinbaren

Quellen

• MinIO auf GitHub
• SeaweedFS auf GitHub
• RustFS auf GitHub
• Ceph auf GitHub
• Garage: Projektseite
• rclone: Dokumentation