Alternative self-hosted a S3 nel 2026 (RustFS, Garage, SeaweedFS, Ceph)

Scelta di un S3 self-hosted dopo MinIO

Indice

Amazon S3 è diventata l’API de facto per l’archiviazione di oggetti. Dopo l’archiviazione del repository open source MinIO avvenuta nell’aprile 2026, restano sette alternative affidabili self-hosted.

Queste opzioni non sono intercambiabili. Alcuni sono motori di archiviazione di oggetti completi che gestiscono il proprio layout dati; altri sono gateway sottili che espongono file che già possiedi. Questa distinzione — store nativo rispetto a gateway basato su filesystem — determina più di qualsiasi elenco di funzionalità in merito a backup, recupero e migrazioni.

Archiviazione S3 self-hosted: object store e gateway di filesystem dietro un’unica API

Questo articolo confronta RustFS, Garage, SeaweedFS, Ceph RGW, VersityGW, S3Proxy e rclone. Ogni sezione copre il modello di archiviazione, la copertura delle funzionalità S3, il posizionamento del progetto e il limite che di solito determina la scelta. Una guida alla decisione per deployment su singolo server e multi-server conclude l’articolo.

Per una visione più ampia — archiviazione di oggetti, database, ricerca e livelli dati nativi AI — vedere la Data Infrastructure for AI Systems.

Confronto di Archiviazione S3 Self-Hosted

La domanda più importante è se serva uno object store distribuito o un’interfaccia S3 davanti a un’archiviazione che già esiste.

Software	Modello di archiviazione	Distribuito	Compatibilità S3	File semplici su disco	Complessità	Uso migliore
RustFS	Object store nativo	Sì	Alta, sottoinsieme testato	No	Basso a medio	Sostituto generale di MinIO
Garage	Object store nativo	Sì	Buona, API più stretta	No	Basso a medio	Piccoli cluster distribuiti
SeaweedFS	Store distribuito di blob e file	Sì	Alta	No	Medio	Enormi volumi di file e archiviazione mista
Ceph RGW	Gateway di oggetti Ceph	Sì	Alta	No	Alta	Infrastruttura di archiviazione di grandi dimensioni
VersityGW	Gateway S3 su POSIX	Dipende dal backend	Buona	Sì	Basso	S3 su file normali
S3Proxy	Livello di traduzione S3	Dipende dal backend	Moderata	Sì con filesystem-nio2	Medio	Gateway e traduzione di protocolli
rclone serve s3	Gateway S3	Dipende dal backend	Base, sperimentale	Sì con backend locale	Molto basso	Deployment semplici e leggeri

RustFS è il sostituto diretto più vicino per un deployment convenzionale di MinIO. Garage si adatta a piccoli cluster distribuiti. SeaweedFS e Ceph risolvono problemi di archiviazione più ampi. VersityGW può esporre un filesystem POSIX esistente tramite S3 mantenendo i payload degli oggetti come file comuni. Per una matrice funzionalità per funzionalità di Garage, MinIO e AWS S3, vedere Garage vs MinIO vs AWS S3.

Due Diversi Tipi di Archiviazione S3

Uno object store nativo possiede il proprio layout di archiviazione:

flowchart TD A[Application] -->|S3 API| B[Object Store] B --> C[Metadata Interno] B --> D[Chunk o Layout Oggetti] C --> E[Dischi] D --> E

RustFS, Garage, Ceph RGW e SeaweedFS appartengono a questa famiglia. I file visibili sui dischi sottostanti sono dettagli di implementazione e le applicazioni non dovrebbero manipolarli direttamente.

Un gateway S3 basato su filesystem ha una relazione diversa con l’archiviazione:

flowchart TD A[Application] -->|S3 API| B[S3 Gateway] B --> C[Filesystem POSIX] C --> D[bucket] D --> E[path] E --> F[ordinary-file.dat]

Con software come VersityGW, il filesystem può rimanere la rappresentazione autoritativa. Un oggetto come:

s3://archive/documents/2026/report.pdf

può corrispondere direttamente a:

/storage/archive/documents/2026/report.pdf

RustFS: Il Sostituto di MinIO Più Vicino

RustFS è un sistema di archiviazione di oggetti distribuito scritto in Rust e rilasciato sotto licenza Apache-2.0. Fornisce un modello operativo orientato a S3 familiare agli utenti di MinIO, il che lo rende il primo progetto da valutare quando si sostituisce MinIO.

La sua attuale implementazione S3 copre le operazioni che la maggior parte delle applicazioni si aspetta: bucket, oggetti, upload multipart, richieste condizionali, metadata degli oggetti, tag, versioning, gestione del ciclo di vita, object lock, URL presigned, policy dei bucket, CORS, notifiche, configurazione della replicazione e crittografia server-side.

RustFS pubblica una matrice di compatibilità S3 che è un sottoinsieme testato, non un’affermazione di copertura completa di Amazon S3. Lo snapshot verificato contro il commit 1e6f5f1e in data 9 agosto 2026 elenca 455 test standard implementati, 5 test di comportamento del ciclo di vita, 17 test standard non implementati e 270 casi esclusi che non bloccano la soglia di compatibilità. Le liste esecutive in scripts/s3-tests sono la fonte di verità quando quei conteggi variano.

Dove si adatta RustFS

RustFS è un candidato quando un’applicazione si aspetta un corretto object store S3.

Gli usi tipici includono archiviazione di oggetti per applicazioni, repository di backup, archiviazione multimediale, artefatti di pipeline AI e dati, infrastruttura S3 interna, workload Kubernetes e sostituzione di endpoint MinIO esistenti.

Funziona con AWS SDK e comuni client S3. Le applicazioni richiedono normalmente un endpoint personalizzato, credenziali, impostazioni della regione dove richiesto e indirizzamento in stile percorso.

Il limite importante

RustFS possiede la rappresentazione dell’archiviazione. I file sotto la sua directory dati sono interni a RustFS.

Questo rende RustFS la risposta sbagliata quando il requisito è che ogni oggetto S3 rimanga un file comune che puoi ispezionare, copiare, rsync o recuperare senza il software di archiviazione di oggetti. Questo requisito seleziona un gateway basato su filesystem.

Garage: S3 Distribuito Senza la Complessità della Scala Ceph

Garage è uno object store distribuito compatibile con S3 per installazioni self-hosted piccole e medie. Deuxfleurs lo sviluppa sotto licenza AGPL v3 e lo ha in produzione fin dalle release iniziali del progetto nel 2020.

Garage è progettato per funzionare su diversi server comuni, inclusi server in diverse posizioni fisiche. La replicazione fa parte del design.

flowchart LR A[Applications] --> B[S3 Endpoint] B --> C[Nodo Garage 1] B --> D[Nodo Garage 2] B --> E[Nodo Garage 3] C <--> D D <--> E E <--> C

Garage è attraente quando hai tre piccoli server piuttosto che un rack di hardware di archiviazione dedicato. Un percorso operativo funzionante, da Docker fino al layout del cluster, alla replicazione e alla TLS tramite un reverse proxy, è nella guida rapida Garage.

Dove si adatta Garage

Garage ha senso per homelab, piattaforme di hosting piccole, server distribuiti geograficamente, backup replicati e cluster in cui Ceph sarebbe eccessivo.

Il suo ambito è più stretto di AWS S3. La tabella di compatibilità di Garage esclude le policy dei bucket, gli ACL e il versioning dei bucket. Scegli Garage rispetto a RustFS quando la replicazione multi-nodo leggera è il requisito principale. Scegli RustFS quando un comportamento S3 più ampio e la compatibilità applicativa simile a MinIO contano di più.

SeaweedFS: Più di Uno Object Store

SeaweedFS ha iniziato archiviando efficientemente enormi numeri di file. Oggi è una piattaforma di archiviazione distribuita che espone S3, un filesystem FUSE, WebDAV, SFTP e HDFS. SeaweedFS 4.48 è stata rilasciata il 28 settembre 2026.

I server di volume impacchettano blob in file di volume append-only. I master tracciano i volumi piuttosto che i singoli file. Un filer fornisce semantica di filesystem gerarchico. Il design mira a workload con milioni o miliardi di oggetti relativamente piccoli.

Supporto S3

SeaweedFS documenta versioning, object lock, regole del ciclo di vita, tag, CORS, checksum, URL presigned, upload multipart, policy dei bucket, IAM, STS e diverse modalità di crittografia server-side.

Lo stesso cluster può servire bucket di tabelle S3 e un catalogo REST Iceberg integrato, in modo che Spark, Trino, DuckDB e motori simili possano usare tabelle Iceberg senza un Hive Metastore o Glue separato. L’esempio S3 a comando singolo del progetto ascolta sulla porta 8333.

Dove si adatta SeaweedFS

Considera SeaweedFS per crawler web e archivi, repository di immagini e documenti, miliardi di oggetti piccoli, data lake, workload misti S3 e filesystem, e archiviazione che cresce aggiungendo server di volume.

Ci sono più componenti da capire rispetto a un’installazione diretta di RustFS. SeaweedFS può fornire semantica di filesystem attraverso il suo filer e mount FUSE, ma gli oggetti sono archiviati dentro il suo formato di volume. Non soddisfa il requisito che ogni oggetto S3 rimanga un file comune indipendente sul filesystem host.

Ceph RGW: L’Opzione alla Scala Infrastrutturale

Ceph è più ampio dell’archiviazione S3. Un cluster può fornire dispositivi a blocchi attraverso RBD, un filesystem attraverso CephFS e archiviazione di oggetti attraverso RADOS Gateway (RGW). RGW presenta un’API compatibile con S3 supportata da RADOS.

flowchart TD A[Applications] -->|S3| B[Ceph RGW] B --> C[RADOS] C --> D[OSD 1] C --> E[OSD 2] C --> F[OSD 3]

Ceph supporta replicazione, codifica di errore, domini di guasto, gateway multipli, deployment multisite, policy di accesso e tooling di gestione del cluster.

Dove si adatta Ceph

Ceph ha senso quando l’archiviazione di oggetti è una parte di una piattaforma di archiviazione più ampia: volumi persistenti Kubernetes, dischi di macchine virtuali, filesystem condivisi, grandi repository S3 e cluster che necessitano di domini di guasto espliciti.

Per un singolo server con alcuni terabyte, installare Ceph solo per ottenere un endpoint S3 è difficile da giustificare. Se operi già Ceph, RGW è la scelta S3 ovvia. Se non lo fai, RustFS o Garage raggiungono un’archiviazione di oggetti utile con meno complessità.

VersityGW: S3 Su File Comuni

VersityGW è l’opzione da valutare quando il filesystem stesso conta. È un gateway S3 con licenza Apache-2.0 che può esporre filesystem POSIX, ScoutFS, Azure Blob Storage, altri servizi S3 e backend personalizzati.

Il suo backend POSIX mappa bucket e oggetti S3 su directory e file. Ad esempio:

s3://website-assets/images/logo.png

viene mappato su un percorso come:

/storage/website-assets/images/logo.png

Il payload di logo.png rimane un file normale.

Perché i file comuni sono utili

Puoi ispezionare l’archiviazione con comuni tool Unix:

find /storage -type f
du -sh /storage/*

Puoi leggere un oggetto senza il server S3:

cat /storage/archive/2026/source.html

I comuni tool di backup del filesystem si applicano direttamente: rsync, restic, borg, tar e zfs send. Se il software del gateway sparisce, i payload sono comunque file in un albero di directory.

Metadata S3 su un backend POSIX

I metadata S3 non stanno in un file POSIX da soli. VersityGW li archivia negli attributi estesi di default. Da marzo 2026, i metadata degli oggetti sono un singolo xattr user.metadata contenente JSON, perché un xattr per chiave ha raggiunto i limiti di lunghezza della chiave del filesystem. Un comando versitygw utils convert-xattr-metadata riscrive gli attributi per chiave più vecchi. Le letture ricorrono comunque al vecchio layout quando user.metadata è assente.

I filesystem senza xattr possono usare --sidecar (o VGW_META_SIDECAR) per mantenere i metadata in un albero di directory separato. Il progetto marca sidecar e --nometa come meno testati rispetto agli xattr. --nometa disabilita l’archiviazione dei metadata ed è mirato all’hosting read-only di un dataset che già esiste; le policy dei bucket e gli ACL sono metadata, quindi non sono disponibili in quella modalità.

Le versioni degli oggetti possono risiedere in una directory separata. L’esempio POSIX del progetto passa --versioning-dir per le versioni più vecchie mentre il payload corrente resta al suo percorso naturale.

Modificare un file dietro il gateway può lasciare i metadata S3, inclusi gli ETag, incoerenti con i nuovi byte. Un modello operativo fattibile è:

Accesso applicazione:
    Leggere attraverso S3
    Scrivere attraverso S3

Accesso amministratore:
    Leggere direttamente il filesystem
    Ispezionare direttamente il filesystem
    Fare backup direttamente del filesystem
    Evitare di modificare oggetti dietro il gateway

VersityGW 1.8.0, già la versione a cui puntava una release di driver COSI di settembre 2026, aggiunge un servizio IAM standalone (versitygw iam), STS AssumeRoleWithWebIdentity e condizioni delle policy IAM.

S3Proxy: Un Livello di Traduzione Generale

S3Proxy implementa l’API S3 e traduce le richieste su diversi backend: file locali, Azure Blob Storage, Google Cloud Storage, OpenStack Swift, SFTP e altri servizi S3. Richiede Java 17 o superiore.

flowchart TD A[S3 client] --> B[S3Proxy] B --> C[filesystem-nio2] C --> D[Filesystem locale]

Il provider su disco raccomandato è filesystem-nio2. Il provider filesystem più vecchio è deprecato. Le chiavi degli oggetti diventano percorsi del filesystem e i metadata usano attributi estesi utente, in modo che i payload restino file comuni.

Il backend filesystem rifiuta il versioning degli oggetti e la crittografia server-side. Il versioning rimane non supportato (supportsVersioning() è falso, e quelle richieste restano HTTP 501) perché un layout di versioni scritto su un disco reale diventerebbe un formato che il progetto dovrebbe mantenere. La crittografia server-side è rifiutata per la stessa classe di motivi: segnalare AES256 su un file in chiaro che qualcuno può leggere sarebbe un’affermazione falsa. Il backend in-memory transient-nio2 implementa entrambi, e i dati muoiono con il processo. La README del progetto elenca anche le policy dei bucket, il tagging degli oggetti e gli ACL diversi da private e public-read come non supportati.

S3Proxy è lo strumento quando hai bisogno di quella traduzione tra backend. Per un gateway S3-a-POSIX diretto, VersityGW ha una superficie più piccola.

rclone serve s3: Leggero ma Sperimentale

rclone serve s3 espone un backend rclone attraverso un’API compatibile con S3. La documentazione etichetta ancora il comando come sperimentale.

Per un filesystem locale:

rclone serve s3 \
  --addr :9000 \
  --auth-key ACCESS_KEY,SECRET_KEY \
  local:/srv/s3

Senza --addr, il server si lega a 127.0.0.1:8080. --auth-key abilita Signature Version 4. Gli upload multipart sono scritti in ordine di numero di parte su un oggetto temporaneo e rinominati in posizione al completamento, in modo che un upload fallito non sostituisca un oggetto esistente.

Gli oggetti scritti attraverso un backend local diventano file sotto quel percorso. Lo stesso comando può stare davanti ad altri remoti rclone. È una scelta ragionevole per tooling interno, un laboratorio o una tappa temporanea di migrazione. È un livello S3 permanente debole per molte applicazioni di produzione non correlate.

Che Dire di MinIO?

Il repository GitHub di MinIO è stato archiviato il 13 febbraio 2026, brevemente de-archiviato e archiviato di nuovo il 25 aprile 2026. È read-only. La nota del repository indirizza gli operatori ad AIStor, la distribuzione commerciale di MinIO, e afferma che l’edizione community è solo sorgente.

Un deployment MinIO esistente può continuare a funzionare, in particolare quando è isolato e il suo comportamento è già compreso. La timeline completa, il rischio operativo e un piano di migrazione graduale sono in MinIO CE in 2026.

Per il comportamento S3 del sistema che potresti lasciare, MinIO come alternativa ad AWS S3 documenta come MinIO si mappa su S3. La scheda rapida riga di comando MinIO è il compagno di audit per un cluster che è ancora attivo. Per una nuova installazione, un’alternativa attivamente mantenuta è la scelta predefinita.

File Comuni vs Archiviazione Oggetti Nativa

Usa RustFS, Garage, SeaweedFS o Ceph quando lo object store dovrebbe controllare durevolezza, metadata, distribuzione e layout. Questo compra semantica S3 più ricca, replicazione o codifica di errore, scalabilità orizzontale e versioning dove il progetto lo implementa. Il costo è la dipendenza dalla rappresentazione su disco del motore.

Usa VersityGW, S3Proxy o rclone quando un filesystem esistente dovrebbe rimanere autoritativo. Questo compra file recuperabili comuni, backup convenzionali, ispezione diretta e compatibilità con ZFS, XFS, ext4 e NFS. La durevolezza distribuita deve poi venire dal filesystem o dall’array di archiviazione, non dal processo S3. Su un singolo server o un NAS, quel compromesso è spesso quello giusto.

Scegliere il Server S3 Self-Hosted Giusto

Per un singolo server che dovrebbe assomigliare a MinIO, iniziare con RustFS.

Per tre o più server modesti dove la replicazione è il requisito principale, e l’applicazione può vivere senza policy dei bucket e versioning, scegliere Garage.

Per enormi numeri di oggetti piccoli, accesso misto a filesystem, o un workload data-lake che potrebbe crescere in tabelle Iceberg, considerare SeaweedFS.

Quando lo stesso cluster deve anche fornire dispositivi a blocchi e un filesystem distribuito, scegliere Ceph RGW.

Quando il requisito è specificamente un’API S3 su file comuni — un NAS, un archivio, un repository di documenti, un crawler o un target di backup — iniziare con VersityGW.

Quando il compito è tradurre S3 su Azure, GCS, Swift, SFTP o un altro servizio S3, usare S3Proxy.

Quando il deployment è piccolo, temporaneo e può tollerare un server sperimentale, rclone serve s3 potrebbe bastare.

Architettura Raccomandata per un Single Storage Server

Se le applicazioni dovrebbero raggiungere i dati solo attraverso S3, RustFS possiede il livello oggetto e il filesystem è un dettaglio di implementazione:

flowchart TD A[Applications] -->|S3| B[RustFS] B --> C[Archiviazione Locale] C --> D[Filesystem o RAID]

Se i file stessi devono sopravvivere al gateway, mantenere i dati in un albero POSIX:

flowchart TD A[Applications] -->|S3| B[VersityGW] B --> C[Filesystem POSIX] C --> D[ext4, XFS, ZFS, NFS] D --> E[File Comuni]

Nel secondo design, la ridondanza è uno specchio ZFS, RAID, snapshot, replicazione del filesystem o un tool di backup convenzionale. Il servizio S3 può essere sostituito senza riscrivere il formato dati.

Considerazioni Finali

S3 self-hosted mantenuto esiste ancora dopo che il repository pubblico di MinIO è diventato read-only. La scelta che conta è se S3 possiede i byte o se fronteggia solo file che già esistono. Ogni confronto sopra segue da quella risposta.