Categoría: Almacenamiento
Almacenamiento compatible con S3 para copias: alternativas a MinIO
Un destino para las copias de vuestras bases de datos, máquinas y aplicaciones que habla S3, vive en servidores que controláis y está pensado para que un atacante no pueda borrar el historial.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- SeaweedFS, RustFS y Versity: Apache 2.0. Garage: AGPLv3. Ceph: LGPL
En resumen
Un almacenamiento de objetos compatible con S3 guarda archivos en buckets y entiende la misma API que Amazon S3, así que casi cualquier herramienta de copias puede escribir en él. Lo montamos en vuestros servidores con la opción mantenida que mejor encaje, configuramos accesos, bloqueo de objetos cuando el software lo admite, réplica a otro sitio y alertas, y lo mantenemos al día.
¿Qué nos encargamos de mantener?
Casi todas las herramientas de copias modernas escriben en S3: pgBackRest, WAL-G, Velero, restic o Proxmox Backup Server. Tener un destino S3 propio es cómodo, pero es el último recurso cuando todo lo demás falla, así que necesita tanto cuidado como lo que protege:
Servidores y discos
Redundancia de discos, SMART vigilado y capacidad prevista para la retención.
Servicio S3
El software elegido configurado, con HTTPS y versiones al día.
Credenciales
Una por herramienta, con permisos mínimos y rotación documentada.
Bloqueo de objetos
Versionado y Object Lock en los buckets de copias cuando el software lo permite.
Réplica
Segunda copia en otra ubicación, propia o de un proveedor.
Alertas
Espacio, errores de escritura, discos degradados y copias que dejan de llegar.
¿Qué opción recomendamos hoy?
Durante años, MinIO fue la respuesta por defecto. Con su repositorio archivado y sin mantenimiento, ya no lo proponemos para instalaciones nuevas. Estas alternativas son de código abierto y siguen activas:
| Opción | Licencia | Encaja cuando | Límites a tener en cuenta |
|---|---|---|---|
| SeaweedFS | Apache 2.0 | Muchos archivos, crecimiento continuo y necesidad de versionado y bloqueo de objetos | Varios servicios (master, volume, filer y pasarela S3); revisamos las funciones S3 que usa cada herramienta |
| Ceph RGW | LGPL | Volumen grande, varios servidores y, a menudo, un Ceph ya existente | Exige varios nodos, red rápida y experiencia con Ceph; el bloqueo se activa al crear el bucket |
| RustFS | Apache 2.0 | Un sustituto cercano a MinIO, con versionado, bloqueo de objetos y réplica | Versión 1.0 muy reciente; lo probamos antes con vuestras herramientas |
| Garage | AGPLv3 | Pocos servidores, incluso en sitios distintos, y un equipo pequeño | Sin versionado ni Object Lock; parte de la API S3 sin implementar |
| Versity S3 Gateway | Apache 2.0 | Dar acceso S3 a un sistema de archivos que ya tenéis | La redundancia depende del sistema de archivos que hay debajo |
| S3 gestionado de un proveedor | Servicio comercial | No hay obligación de tener los datos en casa | Dependéis del proveedor; lo usamos a menudo como segunda ubicación |
Antes de decidir, comprobamos qué llamadas S3 hacen vuestras herramientas de copia: algunas dan por hecho el versionado o ciertas cabeceras y fallan si el servidor no las admite.
¿Qué problemas encontramos más a menudo?
- MinIO comunitario sin actualizar porque ya no hay versiones nuevas que instalar.
- Una sola credencial de administrador usada por todas las herramientas de copia.
- Destino en la misma máquina o la misma sala que lo que copia.
- Sin bloqueo de objetos ni réplica: quien compromete los servidores borra también las copias.
- Disco lleno sin aviso: las copias fallan y nadie se entera hasta que hace falta una.
- Certificados autofirmados que obligan a desactivar la verificación TLS en los clientes.
¿Cómo comprobamos que sirve de verdad?
Un destino de copias se prueba restaurando desde él. En cada herramienta que escribe ahí, ensayamos periódicamente una restauración real y apuntamos el tiempo. Además, intentamos borrar una copia protegida con las credenciales de la herramienta para confirmar que el bloqueo funciona, comprobamos que la réplica de la segunda ubicación está al día y simulamos la caída de un disco o de un nodo para ver que el servicio sigue respondiendo.
¿Para quién tiene sentido?
- Una empresa que no puede sacar sus copias de sus instalaciones por contrato o por política interna.
- Un equipo con un clúster de Proxmox VE o Kubernetes propio que necesita un destino S3 cercano para restaurar rápido.
- Quien tiene MinIO en producción y necesita salir hacia algo mantenido sin perder el historial de copias.
Las copias de máquinas virtuales suelen llegar desde un Proxmox Backup Server gestionado; las de bases de datos, desde pgBackRest o WAL-G en el PostgreSQL gestionado.
¿Cómo lo actualizamos?
Seguimos las notas de versión de cada proyecto y actualizamos nodo a nodo cuando hay varios, para que el servicio no se interrumpa. Antes de una versión mayor comprobamos que las copias recientes de todo lo que guarda están también en la segunda ubicación. En Ceph seguimos además el orden de actualización que marca su documentación.
- Herramientas de copiapgBackRest, Velero, restic, PBS
- API S3HTTPS y credenciales por herramienta
- AlmacenamientoSeaweedFS, Ceph RGW, RustFS o Garage
- RéplicaSegunda ubicación
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- OVH
- AWS
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidores dedicados con muchos discos como almacenamiento propio, o Object Storage de Hetzner como segunda ubicación. | Si os basta un servicio gestionado, Object Storage de Hetzner ya es compatible con S3 y no hace falta montar nada. |
| OVH | Servidores dedicados de almacenamiento con SeaweedFS, Ceph o RustFS, o Object Storage de OVHcloud como destino gestionado. | |
| AWS | Amazon S3 con Object Lock como segunda ubicación para las copias de un almacenamiento propio. | Montar un almacenamiento propio dentro de AWS rara vez compensa frente a S3. |
| Servidor propio | El almacenamiento elegido en servidores de vuestra oficina o de vuestro centro de datos, con réplica fuera. | Una sola máquina con un único disco no es un destino de copias: como mínimo, discos redundantes y una segunda ubicación. |
Qué incluye
- Elección razonada del software según volumen, número de servidores y funciones S3 que necesitan vuestras herramientas de copia.
- Servicio compatible con S3 en vuestros servidores o en dedicados, con discos y redundancia dimensionados para la retención pactada.
- Un bucket y unas credenciales por herramienta de copia, con los permisos mínimos que necesita cada una.
- Versionado y bloqueo de objetos (Object Lock) en los buckets de copias, si el software elegido los admite.
- HTTPS con certificado válido y acceso solo desde las redes que envían copias.
- Réplica o segunda copia en otra ubicación, a otro almacenamiento propio o a un proveedor S3.
- Métricas de espacio, errores, discos y peticiones, con alertas antes de quedarse sin sitio.
- Actualizaciones planificadas y, si ya usáis MinIO, un plan de salida hacia una alternativa mantenida.
Preguntas frecuentes
¿Qué ha pasado con MinIO?
El repositorio público de MinIO está archivado, en solo lectura, y su propia portada avisa de que ya no se mantiene; la empresa remite a su producto AIStor. Un MinIO comunitario que ya funciona no deja de hacerlo, pero no recibe actualizaciones, así que para instalaciones nuevas os proponemos una alternativa mantenida.
¿Qué alternativa elijo?
SeaweedFS y Ceph RGW son proyectos veteranos que documentan versionado y bloqueo de objetos; Ceph es el más completo y el más exigente de operar. RustFS, también con bloqueo de objetos, publicó su versión 1.0 en septiembre de 2026. Garage es ligero y funciona entre varios sitios, pero hoy no tiene versionado ni bloqueo. Elegimos según vuestro tamaño y lo que necesiten vuestras herramientas.
¿Por qué importa el bloqueo de objetos?
Porque con Object Lock una copia no se puede borrar ni sobrescribir hasta que vence su plazo de retención. Si alguien compromete vuestros servidores, no puede llevarse también el historial de copias. Si el software elegido no lo admite, lo compensamos con una segunda copia en un destino que sí lo tenga.
¿No es más sencillo usar el S3 de un proveedor?
Muchas veces sí. Hetzner, OVHcloud o AWS ofrecen almacenamiento compatible con S3 gestionado, y para muchas empresas es la mejor opción. Un almacenamiento propio tiene sentido cuando los datos no pueden salir de vuestras instalaciones, cuando el volumen hace caro el servicio o como segunda copia independiente del proveedor principal.
¿Cómo salimos de un MinIO que ya tenemos?
Montamos la alternativa en paralelo, copiamos los buckets con una herramienta de sincronización S3 como rclone, comparamos recuentos y tamaños, y cambiamos las herramientas de copia una a una. El MinIO antiguo se queda en solo lectura hasta que las retenciones antiguas caducan o se han copiado.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el