S3-Speicher selbst hosten nach dem MinIO-Aus: Garage und RustFS im Vergleich (+ Setup)

Wer S3-kompatiblen Object-Storage selbst betreibt, hat seit Mitte 2025 ein Problem: MinIO, lange die erste Wahl für Self-Hosted-Setups, hat das Web-UI (Object Browser, Policy-Management, Monitoring) aus der Community Edition entfernt und ist seit Dezember 2025 im Maintenance Mode. Neue Features kommen nicht mehr, der vollständige Funktionsumfang kostet im AIStor-Abo ab 96.000 USD pro Jahr. Für KMU und Homelab-Nutzer, die weiterhin S3-Speicher ohne Lizenzkosten betreiben wollen, gibt es drei ernstzunehmende Alternativen: Garage, RustFS und SeaweedFS. Dieser Artikel liefert die Entscheidungshilfe, die seit dem MinIO-Kahlschlag fehlt, und zeigt danach ein lauffähiges Garage-Setup mit restic-Anbindung.

Voraussetzungen

1. Server oder VPS mit mindestens 512 MB RAM (Garage Single-Node benötigt ~50–100 MB im Leerlauf)
2. Docker Engine >= 20.x und Docker Compose installiert (siehe Docker-Installation auf Linux)
3. Mindestens 10 GB freier Festplattenplatz für Daten (je nach Backup-Umfang mehr)
4. Port 3900 (S3 API) vom Backup-Client aus erreichbar
5. restic >= 0.16 auf dem Backup-Client installiert (aktuell: restic 0.18.1)
6. Texteditor für garage.toml und docker-compose.yml
7. Grundkenntnisse Docker Compose und Linux-Kommandozeile

Schritt 1: MinIO-Nachfolger im Vergleich – Garage, RustFS oder SeaweedFS?

Bevor du irgendwas installierst, lohnt sich ein ehrlicher Blick auf die Optionen. Die folgende Tabelle zeigt die wichtigsten Kriterien für KMU-Entscheider:

Fazit zur Entscheidung: Für ein ressourcensparendes Backup-Ziel (z. B. auf einem günstigen VPS oder Raspberry Pi) ist Garage die richtige Wahl. Wer Erasure Coding oder eine Web-UI zwingend braucht, sollte SeaweedFS in Betracht ziehen. RustFS klingt verlockend – gleiche Ports wie MinIO, Apache-Lizenz, Web-UI –, ist aber Stand Juni 2026 ausdrücklich nicht produktionsreif. Nicht für echte Backups einsetzen.

Wichtiger Hinweis für bestehende MinIO-Nutzer: Wenn du bereits eine funktionierende MinIO-Instanz betreibst (beschrieben in unserer MinIO S3-Storage selbst hosten mit Docker und Traefik-Anleitung), ist kein sofortiger Handlungsbedarf. MinIO AGPL läuft weiter und erhält Security Patches. Der Umstieg lohnt sich, wenn du heute neu anfängst oder neue Features benötigst.

Verifizieren: Du hast eine klare Entscheidung getroffen. Wenn du auf einem einzelnen Server mit wenig RAM ein Backup-Ziel aufbauen willst: weiter mit Garage. Wenn du Erasure Coding oder Web-UI brauchst: SeaweedFS evaluieren. Wenn du MinIO bereits betreibst: vorerst bleiben.

Schritt 2: Garage konfigurieren – garage.toml erstellen

Lege zunächst ein Arbeitsverzeichnis an und erstelle die Konfigurationsdatei. Garage braucht einen zufälligen 32-Byte-Hex-String als rpc_secret – generiere ihn mit openssl:

mkdir -p ~/garage && cd ~/garage
openssl rand -hex 32

Kopiere die Ausgabe (z. B. a3f9e2c1...) und trage sie in garage.toml ein. Erstelle die Konfigurationsdatei als ~/garage/garage.toml:

metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
db_engine = "sqlite"
replication_factor = 1

rpc_bind_addr = "[::]:3901"
rpc_public_addr = "127.0.0.1:3901"
# Zufaelliger 32-Byte Hex-String (openssl rand -hex 32)
rpc_secret = "HIER_32_BYTE_HEX_EINTRAGEN"

[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"

[s3_web]
bind_addr = "[::]:3902"
root_domain = ".web.garage.localhost"
index = "index.html"

[admin]
api_bind_addr = "[::]:3903"

Wichtig: db_engine = "sqlite" ist für Single-Node ausreichend. Für einen 3-Node-Cluster später auf lmdb wechseln (bessere Schreib-Performance).

Verifizieren: Überprüfe, dass rpc_secret auf deinen generierten 64-stelligen Hex-String gesetzt ist (nicht mehr der Platzhalter) und die Datei vorhanden ist:

ls -la ~/garage/garage.toml
# Erwartet: -rw-r--r-- ... garage.toml

Schritt 3: Docker Compose aufsetzen und Container starten

Erstelle im selben Verzeichnis die docker-compose.yml:

services:
  garage:
    image: dxflrs/garage:v2.3.0
    container_name: garage
    restart: unless-stopped
    ports:
      - "3900:3900"  # S3 API
      - "3901:3901"  # RPC
      - "3902:3902"  # S3 Web
      - "3903:3903"  # Admin
    volumes:
      - ./garage.toml:/etc/garage.toml
      - garage_meta:/var/lib/garage/meta
      - garage_data:/var/lib/garage/data

volumes:
  garage_meta:
  garage_data:

Starte den Container:

docker compose up -d

Verifizieren: Der Container muss laufen und der Garage-Prozess gestartet sein:

docker compose ps
# Erwartet: garage   running   0.0.0.0:3900-3903->3900-3903/tcp

docker logs garage --tail 20
# Erwartet: "Garage xx starting", "RPC server listening on [::]:3901"
# Kein "Error" oder "panic" in den Logs

Schritt 4: Garage-Cluster initialisieren – Node-ID und Layout

Garage ist erst betriebsbereit, wenn ein Layout zugewiesen und aktiviert wurde. Das ist ein häufiger Stolperstein: Ohne diesen Schritt akzeptiert Garage keine Schreibzugriffe.

Ermittle zunächst die Node-ID:

docker exec garage garage status

Die Ausgabe zeigt eine lange Hex-ID, z. B. 563e1a2bdf4c8a01.... Notiere die ersten 6–8 Zeichen. Weise dann das Layout zu und aktiviere es:

# NODE_ID = erste 6-8 Zeichen der ID aus 'garage status'
docker exec garage garage layout assign -z dc1 -c 100G NODE_ID

# Layout aktivieren (--version 1 beim ersten Mal)
docker exec garage garage layout apply --version 1

# Zur Kontrolle
docker exec garage garage layout show

Ersetze 100G durch die tatsächlich verfügbare Kapazität (z. B. 50G oder 500G) und NODE_ID durch deine kurze Node-ID.

Verifizieren: garage layout show muss eine Zeile mit deiner Node-ID, Zone dc1 und der angegebenen Kapazität anzeigen. garage status darf keinen Hinweis mehr auf „layout not yet applied" enthalten:

docker exec garage garage status
# Erwartet: 1 node online, keine Fehlermeldung "No layout"

Schritt 5: Bucket und Access Key erstellen

Erstelle einen Bucket für die restic-Backups und einen dedizierten Access Key mit den nötigen Berechtigungen:

# Bucket anlegen
docker exec garage garage bucket create mein-backup-bucket

# Vorhandene Buckets auflisten
docker exec garage garage bucket list

# Access Key erstellen
docker exec garage garage key create mein-restic-key

# Bucket-Zugriff fuer den Key erlauben (Lesen + Schreiben + Owner)
docker exec garage garage bucket allow \
  --read --write --owner \
  mein-backup-bucket \
  --key mein-restic-key

# Key-Details (ID und Secret) anzeigen
docker exec garage garage key info mein-restic-key

Notiere Key ID und Secret Key aus der letzten Ausgabe sorgfältig. Diese werden nicht erneut angezeigt.

Verifizieren: garage bucket list zeigt mein-backup-bucket. garage key info mein-restic-key zeigt unter „Authorized buckets" den Bucket mit read=true write=true owner=true:

docker exec garage garage key info mein-restic-key
# Erwartet: ...Authorized buckets: mein-backup-bucket (read=true, write=true, owner=true)

Schritt 6: restic mit Garage als S3-Backend verbinden

Garage spricht S3, aber mit einer Eigenheit: restic versucht standardmäßig „virtual-hosted-style" (Bucket-Name im Hostnamen). Garage unterstützt nur „path-style". Ohne den Schalter -o s3.bucket-lookup=path erscheint ein NoSuchBucket-Fehler – mehr dazu im Troubleshooting-Abschnitt.

Lege eine Umgebungsvariablen-Datei an und schütze sie:

sudo mkdir -p /etc/restic
sudo tee /etc/restic/garage.env > /dev/null <<'EOF'
export AWS_ACCESS_KEY_ID="KEY_ID_AUS_GARAGE"
export AWS_SECRET_ACCESS_KEY="SECRET_AUS_GARAGE"
export AWS_DEFAULT_REGION="garage"
export RESTIC_REPOSITORY="s3:http://localhost:3900/mein-backup-bucket"
export RESTIC_PASSWORD="SICHERES_BACKUP-PASSWORT"
EOF
sudo chmod 600 /etc/restic/garage.env

Ersetze KEY_ID_AUS_GARAGE und SECRET_AUS_GARAGE durch die Werte aus Schritt 5. AWS_DEFAULT_REGION muss exakt mit dem s3_region-Wert aus garage.toml übereinstimmen – also garage.

Initialisiere das restic-Repository:

source /etc/restic/garage.env

# Repository initialisieren (path-style erzwingen)
restic init -o s3.bucket-lookup=path

Verifizieren: restic gibt nach dem Init eine Bestätigung aus. Prüfe mit restic snapshots:

source /etc/restic/garage.env
restic snapshots -o s3.bucket-lookup=path
# Erwartet: "repository ... opened successfully"
# "no matching snapshots" (da noch kein Backup laeuft - korrekt)

Schritt 7: Erstes Backup ausführen und prüfen

Jetzt ist das Backup-Ziel bereit. Führe ein erstes Backup durch und verifiziere die Integrität:

source /etc/restic/garage.env

# Backup von /home und /etc (Beispiel - anpassen)
restic backup /home /etc -o s3.bucket-lookup=path

# Snapshots auflisten
restic snapshots -o s3.bucket-lookup=path

# Repository-Integritaet pruefen
restic check -o s3.bucket-lookup=path

Für den Dauerbetrieb empfiehlt sich ein Systemd-Timer oder Cron-Job – dazu findest du alle Details in unserer restic-Backup automatisieren mit Cron-Anleitung.

Verifizieren: restic snapshots zeigt mindestens einen Snapshot mit aktuellem Zeitstempel. restic check endet mit no errors were found:

restic snapshots -o s3.bucket-lookup=path
# Erwartet:
# ID        Time                 Host   Tags  Paths
# --------  -------------------  -----  ----  ------
# abc12345  2026-06-10 10:00:00  host1        /home, /etc

restic check -o s3.bucket-lookup=path
# Erwartet letzte Zeile: "no errors were found"

Ausblick: 3-Node-Cluster für Hochverfügbarkeit

Der Single-Node-Betrieb mit replication_factor = 1 bietet keine Redundanz gegen Festplattenausfall. Für einen 3-Node-Cluster passt du garage.toml auf allen drei Maschinen wie folgt an (nur rpc_public_addr ist pro Node unterschiedlich):

metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
db_engine = "lmdb"
replication_factor = 3

rpc_bind_addr = "[::]:3901"
rpc_public_addr = "NODE_IP:3901"
rpc_secret = "GLEICHER_SECRET_AUF_ALLEN_NODES"

[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"

[admin]
api_bind_addr = "[::]:3903"

Nach dem Start aller drei Nodes das Layout auf einem Node zuweisen:

# NODE1_ID, NODE2_ID, NODE3_ID aus 'garage status' entnehmen
garage layout assign -z site1 -c 1T NODE1_ID
garage layout assign -z site2 -c 1T NODE2_ID
garage layout assign -z site3 -c 1T NODE3_ID
garage layout apply --version 1

Kapazitäts-Hinweis: Bei replication_factor = 3 speichert Garage immer 3 vollständige Kopien auf physisch verschiedenen Nodes. Die nutzbare Gesamtkapazität entspricht der des kleinsten Nodes – nicht der Summe. Drei Nodes à 2 TB ergeben 2 TB nutzbare Kapazität, nicht 6 TB.

Troubleshooting / Typische Fehler

1. „No layout configured" / HTTP 500 bei S3-Operationen: Das Layout wurde nicht aktiviert. Führe garage layout apply --version N aus (N = nächste Version). Kontrolliere mit garage layout show und garage status.
2. „NoSuchBucket" oder „invalid hostname" in restic: restic verwendet standardmäßig virtual-hosted-style. Garage unterstützt nur path-style. Fix: -o s3.bucket-lookup=path an alle restic-Befehle anhängen.
3. „AuthorizationHeaderMalformed" oder „InvalidRegion": AWS_DEFAULT_REGION stimmt nicht mit s3_region in garage.toml überein. Beide müssen exakt denselben Wert haben – bei dieser Anleitung garage.
4. Cluster-Nodes sehen sich nicht: Beim 3-Node-Cluster müssen alle Nodes exakt denselben rpc_secret haben. Abweichungen führen dazu, dass Nodes stillschweigend die Verbindung verweigern. garage status zeigt dann weniger Nodes als erwartet. Lösung: openssl rand -hex 32 neu generieren und identisch auf allen Nodes eintragen.
5. Object Lock / WORM nicht verfügbar: Garage v2.3.0 unterstützt kein Object Lock. Für compliance-relevante Unveränderlichkeit gibt es aktuell keine leichtgewichtige Self-Hosted-Lösung. Alternativ: externe Anbieter mit Object Lock evaluieren (siehe Immutable Backups mit restic und Hetzner).
6. Garage-Container startet nicht / „config file not found": Prüfe, ob ./garage.toml im richtigen Verzeichnis liegt und im Volume-Mount korrekt auf /etc/garage.toml zeigt.

Häufige Fragen

Kann ich mein bestehendes MinIO-Setup einfach durch Garage ersetzen?

Nicht „einfach" – Garage ist kein Drop-in-Ersatz. Access Keys und Buckets müssen neu angelegt werden, Daten müssen per rclone oder restic-Restore + Re-Backup umgezogen werden. Die S3-API-URLs ändern sich (anderer Port, anderes Schema). RustFS wäre technisch ein näherer Drop-in (Port 9000/9001 wie MinIO), ist aber noch nicht produktionsreif. Für bestehende MinIO-Nutzer empfiehlt sich, im AGPL-Betrieb zu bleiben und die Entwicklung von RustFS zu beobachten, bis Version 1.0.0 (stable) erscheint.

Wie sicher ist Garage für echte Backups?

Garage ist seit 2020 production-ready und wird von Deuxfleurs selbst produktiv eingesetzt. Als Single-Node mit replication_factor = 1 gibt es keinen Schutz gegen Festplattenausfall – restic bietet hier aber eine zweite Sicherheitsebene durch seine eigene Integritätsprüfung (restic check). Für kritische Daten: 3-Node-Garage-Cluster oder zusätzliches Offsite-Backup. Lies dazu auch unsere 3-2-1-Backup-Strategie-Anleitung.

Wann ist RustFS produktionsreif?

Stand Juni 2026 ist RustFS bei Version 1.0.0-alpha.99 – das Projekt selbst warnt ausdrücklich vor Produktionseinsatz. Die Entwicklung ist aktiv (über 2.300 Commits, 91 Contributors), aber ohne garantiertes Stabilitätsdatum. Empfehlung: In einer isolierten Testumgebung beobachten, aber keine Produktionsdaten oder Backups ablegen bis Version 1.0.0 (stable) erschienen ist.

Brauche ich für Garage zwingend drei Server?

Nein. Single-Node mit replication_factor = 1 funktioniert auf einem einzigen Server oder VPS. Drei Nodes sind nur für Hochverfügbarkeit und Geo-Redundanz nötig. Für ein Backup-Ziel in einer KMU-Umgebung ist Single-Node ein valider Startpunkt – wichtig ist, dass restic selbst die Datenintegrität sicherstellt.

Darf ich Garage mit AGPL v3 kommerziell einsetzen?

Ja. AGPL v3 erlaubt kommerziellen Einsatz. Die AGPL greift erst, wenn man Garage als Netzwerkdienst an Dritte anbietet und dabei Modifikationen am Quellcode vorgenommen hat – diese Änderungen müssten dann veröffentlicht werden. Für den internen KMU-Einsatz (eigene Backups, eigene Mitarbeiter) ist AGPL kein Problem.

Gibt es eine Verwaltungsoberfläche für Garage?

Garage hat kein eigenes Web-UI. Optionen: (1) garage CLI direkt im Container, (2) Admin REST API auf Port 3903 mit curl, (3) S3-kompatible Client-Tools wie MinIO Client (mc), s3cmd oder rclone für Bucket-Inhalte, (4) Community-Projekt „Administrate" (externe Web-UI für Garage, noch experimentell). Für KMU ohne CLI-Kenntnisse ist SeaweedFS mit integrierter Web-UI ggf. die bessere Wahl.

Fazit

Der MinIO-Kahlschlag trifft Self-Hosted-Nutzer härter als zunächst sichtbar: Nicht nur das Web-UI ist weg, sondern auch die Perspektive auf neue Features. Garage ist der zuverlässigste, ressourcenschonendste Ersatz für KMU-Backup-Ziele heute – kein Feature-Überfluss, dafür stabil, ehrlich dokumentiert und mit minimalem Ressourcenbedarf. RustFS ist technisch spannend, aber noch nicht reif für echte Daten; das sollte sich ändern, wenn Version 1.0.0 erscheint. SeaweedFS ist die richtige Wahl, wenn Erasure Coding oder eine Web-UI nicht verhandelbar sind.

Was Garage nicht kann, muss man klar benennen: kein Object Lock, keine Versionierung, keine Lifecycle Rules, keine Web-UI. Wer unveränderliche Backups für Ransomware-Schutz braucht, hat heute keine leichtgewichtige Self-Hosted-Lösung – das ist eine reale Lücke im Markt. Für das 3-2-1-Backup-Szenario ohne Compliance-Anforderungen ist Garage plus restic jedoch ein solides, bewährtes Gespann, das auf einem günstigen VPS läuft und keine laufenden Lizenzkosten verursacht.

Weiterführende Anleitungen und Quellen

1. MinIO S3-Storage selbst hosten mit Docker und Traefik – Kontext und Setup-Anleitung für bestehende MinIO-Nutzer
2. restic-Backup automatisieren mit Cron und Systemd – Garage als Ziel in den Backup-Zeitplan integrieren
3. 3-2-1-Backup-Strategie praktisch umsetzen – Garage als eine Schicht in der Backup-Architektur
4. Immutable Backups mit restic und Hetzner Object Storage – wenn Object Lock / WORM benötigt wird

Quellen: Garage HQ Quick-Start-Dokumentation (garagehq.deuxfleurs.fr); Blocks and Files: MinIO users complain after admin UI removed (Jun 2025); Elest.io: RustFS vs SeaweedFS vs Garage; restic-Dokumentation S3 Backend; GitHub: rustfs/rustfs; byteiota: MinIO Enters Maintenance Mode.