Si has tocado infraestructura moderna en los últimos años, te has encontrado con la API de S3 en todas partes. Herramientas de backup que «suben a S3», aplicaciones que guardan sus ficheros «en un bucket S3», pipelines de datos e IA que leen y escriben en S3, activos web servidos desde S3. La API que Amazon creó para su servicio de almacenamiento de objetos se ha convertido en un idioma universal: casi todo el software sabe hablarlo.
Y aquí está el malentendido que conviene deshacer: hablar S3 no significa usar Amazon. La API de S3 es un estándar que muchísimo software implementa, y puedes montar tu propio almacenamiento compatible con S3 en tu cloud privado. Tus aplicaciones y tus herramientas de backup creerán que hablan con S3 —porque la API es la misma— pero los datos estarán en tu infraestructura, bajo tu control, sin factura de salida ni dudas de soberanía. Este artículo explica qué es el almacenamiento de objetos, cuándo encaja, y cómo montarlo con MinIO o Ceph sobre Proxmox.
Para saber cuándo usar objetos hay que entender en qué se diferencian de las otras dos formas de almacenamiento, porque no son intercambiables:
La diferencia clave del objeto: está pensado para datos que se escriben y se leen enteros, no que se modifican por trozos, y para escalar de forma casi ilimitada. Una foto, un backup, un vídeo, un dataset: lo subes entero, lo bajas entero. A cambio de no poder editar «a mitad» como en un disco, ganas una escalabilidad y una simplicidad de acceso enormes.
| Bloque | Ficheros | Objetos (S3) | |
|---|---|---|---|
| Se accede como | Disco crudo | Carpetas por red | API HTTP / buckets |
| Ideal para | Discos de VM, bases de datos | Compartir documentos | Backups, archivos, activos, datos de IA |
| Escala | Limitada por volumen | Media | Enorme, casi ilimitada |
| Edición parcial | Sí | Sí | No (objeto entero) |
El almacenamiento de objetos brilla en casos muy concretos, y varios son especialmente relevantes en un cloud privado:
El hilo común: datos que crecen mucho, se acceden por API y no necesitan editarse por trozos. Si tu caso es ese, el almacenamiento de objetos es la herramienta; si necesitas un disco para una base de datos, no —eso es bloque—.
Para montar S3 en tu cloud privado hay dos caminos principales, según tu punto de partida.
Durante años esto se llamaba MinIO: un servidor de almacenamiento de objetos compatible con S3, ligero y simple de poner en marcha, que corre en una VM o contenedor de Proxmox y en minutos te deja un endpoint S3 funcionando. Sigue siendo el modelo mental correcto, pero ojo con la marca: MinIO retiró la consola de administración de su edición comunitaria en 2025, su repositorio de GitHub está archivado y la licencia que distribuye hoy la compañía solo permite una instancia de evaluación no productiva sin acuerdo comercial. El desarrollo se ha ido a su producto de pago, AIStor.
El hueco lo han ocupado otros proyectos con la misma idea. Silo, el fork que mantiene Pigsty, conserva formato en disco, API y variables MINIO_*, así que una instalación existente sigue funcionando sin tocarla. Y hay servidores nuevos escritos desde cero, como VaultS3, que meten panel, IAM y cifrado en un solo binario.
Cuándo esta vía: quieres un S3 propio rápido y sencillo, para un destino de backups, una aplicación o unos activos, sin necesidad de un clúster de almacenamiento completo. Es el punto de entrada más cómodo.
Si tu cloud privado ya usa Ceph como almacenamiento distribuido —muy habitual en clústeres Proxmox de cierto tamaño—, no necesitas montar nada aparte: Ceph incluye el RADOS Gateway (RGW), que expone el almacenamiento del clúster con API S3 (y Swift). Es la misma infraestructura distribuida, resiliente y escalable que ya sostiene tus discos, ofreciendo además una cara S3.
Cuándo Ceph RGW: ya tienes o vas a montar Ceph para bloque, y quieres aprovechar ese mismo almacenamiento distribuido también para objetos, con su redundancia y escalado integrados. Unifica en vez de añadir una pieza más.
La decisión, resumida: un servidor de objetos aparte si quieres S3 de forma simple y aislada; Ceph RGW si ya vives en Ceph y quieres unificar. Todos hablan la misma API S3, así que tus aplicaciones no notan la diferencia.
Más allá de lo técnico, montar S3 en casa responde a dos presiones muy concretas del cloud público:
No se trata de que el S3 propio gane siempre —el hiperescalar tiene su sitio para picos y alcance global—, sino de que, para muchas cargas de un cloud privado, tener tu propio S3 combina lo mejor: el idioma universal del almacenamiento moderno, con tus datos en tu casa y sin sorpresas en la factura.
¿Necesito Amazon para usar almacenamiento S3? No. S3 es una API estándar que mucho software implementa, no solo Amazon. Puedes montar un almacenamiento de objetos compatible con S3 en tu propio cloud privado (con MinIO o Ceph RGW) y tus aplicaciones lo usarán igual que usarían el de Amazon, porque hablan la misma API, pero con los datos en tu infraestructura.
¿Qué diferencia hay entre almacenamiento de objetos y de bloque? El de bloque son discos crudos para una máquina (lo que usa una VM para su disco), de baja latencia y editables por trozos. El de objetos guarda ficheros enteros con sus metadatos en buckets, accesibles por API HTTP (S3), pensado para escalar muchísimo y para datos que se leen y escriben enteros, no se editan a mitad. No son intercambiables: cada uno para lo suyo.
¿Un servidor S3 ligero o Ceph para montar S3? Un servidor de objetos en una máquina si quieres un S3 propio simple y rápido, sin montar un sistema de almacenamiento distribuido completo. Ahí MinIO ya no es la respuesta automática —su repositorio está archivado y su licencia actual solo cubre una instancia de evaluación—, así que la elección está entre su fork Silo y proyectos nuevos como VaultS3. Ceph RGW si ya usas (o vas a usar) Ceph para almacenamiento distribuido y quieres aprovecharlo también para objetos, unificando. Todos exponen la misma API S3.
¿Para qué usaría un S3 propio? Como destino de backups (incluido Proxmox Backup Server), como almacenamiento de ficheros para aplicaciones que esperan un bucket S3, para activos web estáticos, y para datasets de IA y analítica. En general, para datos que crecen mucho, se acceden por API y no necesitan editarse por trozos.
¿Sale más barato que S3 de un hiperescalar? Depende del uso, pero una ventaja clara es que un S3 propio no cobra factura de salida (egress) por leer tus propios datos, que es la partida que más sorprende en el cloud público. Para cargas con mucho movimiento de datos, y sumando el valor de la soberanía, el S3 propio suele salir muy a cuenta. Para picos puntuales o alcance global, el hiperescalar tiene su sitio.
¿Tus aplicaciones o tus backups piden S3 y no quieres que tus datos acaben en un hiperescalar? Montamos contigo un almacenamiento de objetos compatible con S3 en tu cloud privado —MinIO o Ceph— con tus datos en tu casa. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
Asignar a tus VMs más CPU y RAM de la que el servidor tiene físicamente —overcommit— es lo que permite meter más máquinas en el mismo hardware. Con la CPU suele salir bien; con la memoria, hecho a la ligera, es la receta de un servidor que muere de golpe. Explicamos por qué la CPU se sobreasigna con tranquilidad y la RAM con mucho cuidado, y las herramientas (ballooning, KSM) para hacerlo con cabeza.
Ceder unas horas de una GPU suele significar crear un usuario, repartir claves SSH, revisar permisos y acordarse de retirarlo todo después. RunSnack reduce eso a ejecutar un script y pasar un enlace que abre una terminal en el navegador, dentro de un contenedor Docker con acceso a la GPU del anfitrión. Es una idea buena y pequeña, con una frontera de seguridad que su propio autor documenta sin adornos: repasamos qué resuelve, qué no, y cuándo la respuesta correcta sigue siendo una máquina virtual.
Proxmox VE deja crear snapshots desde cualquier sitio, pero no hay una vista de todos los del clúster. ProxSnap, escrito en Rust por el autor de ProxLB, lista, filtra por fecha y borra snapshots viejos desde la API. Qué hace de verdad, qué cuesta un snapshot olvidado según el almacenamiento, y cómo montar una política sin llevarte por delante algo que hacía falta.