Live data from Hacker News

Alternatives to MinIO for single-node local S3

rmoff.net

41–50 of 113 posts

Re: Alternatives to MinIO for single-node local S3

#41
post #36

My https://github.com/uroni/hs5 is designed for this use case. One notable thing is that compared to MinIO (and others) it does not store the objects as individual files. I also have DuckDB directly integrated. The readme has a comparison to Garage, seaweedfs, RustFS and Ceph.

Very cool, I like the conceptual simplicity of it. Even I can understand it, at least at a surface level :-)

Is there a safe way to make backups of the index.lmdb and data0 files without stopping the server?

Re: Alternatives to MinIO for single-node local S3

#42
post #39
post #2

Just use the damn file system. Why does everyone have to put HTTP between everything?

Because AFAIK the filesystem is at the same time a huge API and designed for a different use case. I can think of the following examples: - very flat structures: storing hundred of thousands of files in a single directory will fail - designed for local disks and NFS is a leaky abstraction: - running a system using on locks will fail - cache behaviors work fine for the "humans browsing files" usecase but not so much f…

My point is to push the storage abstraction up a level. Then plug S3 or file system into it.

I wouldn’t say this if I hadn’t done this on the PB scale. On a file system! With billions of files!

People are blind to anything other than shitty cloud APIs now. It’s depressing.

Re: Alternatives to MinIO for single-node local S3

#45
I had previously used seaweedfs, which has more moving parts but seems more feature-rich. It was overkill for a homelab, so I went to garage.

Garage is very stable, but the metadata engine / file MUST live on NVMe. Otherwise it gets slow on small files. It also lacks features like per bucket retention settings and stuff. It really is "just" a S3 bucket.

Re: Alternatives to MinIO for single-node local S3

#46
post #27

Incus (spiritual successor to LXD, after the fork-off by Canonical) has a simple S3 server built-in.

Isn’t that just minio? At least in LXD it’s minio.

Replaced because minio is dead: https://github.com/lxc/incus/pull/3258

Re: Alternatives to MinIO for single-node local S3

#47
We ran RustFS in production at a past job.

Was the backend for an archiving service and we found it to work well on baremetal machines and seamlessly integrated with existing services that used the S3 api.

This was on an internal network so YMMV when it comes to running on the open internet especially with the CVE mentioned in the post.

Re: Alternatives to MinIO for single-node local S3

#48
post #41
post #36

My https://github.com/uroni/hs5 is designed for this use case. One notable thing is that compared to MinIO (and others) it does not store the objects as individual files. I also have DuckDB directly integrated. The readme has a comparison to Garage, seaweedfs, RustFS and Ceph.

Very cool, I like the conceptual simplicity of it. Even I can understand it, at least at a surface level :-) Is there a safe way to make backups of the index.lmdb and data0 files without stopping the server?

Not without snapshot currently. I guess I could collect all writes in the (optional) WAL file while a backup is running, then the files would be consistent.

Re: Alternatives to MinIO for single-node local S3

#50

Filestash ( https://github.com/mickael-kerjean/filestash ) has a s3 gateway plugin that I made. It proxy the S3 traffic to any downstream storage: SFTP, FTP, another S3, SMB, NFS, IPFS, ...

Almost went past looking at this option, it has a far bigger ecosystem of both storage and auth plugins and otherwise looks to be more mature than I might have guessed from the passing comment.
Post reply on HN