Proxmox + Ceph + PBS: Guía Completa para un Homelab Production-Ready

Por qué Proxmox + Ceph para un homelab

Proxmox VE es la alternativa open source seria a VMware/ESXi. Hypervisor enterprise-grade, sin coste de licencia, con una interfaz web que no da vergüenza. Pero donde realmente brilla es cuando le sumas Ceph.

Ceph integrado en Proxmox te da storage distribuido sin necesidad de un NAS o SAN externo. Tus discos locales se convierten en un pool de almacenamiento unificado que las VMs consumen como si fuera un SAN enterprise. Y lo mejor: puedes separar discos rápidos (SSD) de discos de capacidad (HDD) en pools diferentes, cada uno con sus propias reglas de replicación.

Añade Proxmox Backup Server y tienes el triángulo completo: virtualización, storage tiered, y backups con deduplicación — todo en una plataforma, todo open source.

Este setup funciona igual con 1 nodo que con 3+. La arquitectura escala sin rediseñar nada. Las mismas CRUSH rules, los mismos pools, los mismos jobs de backup. Cuando añades nodos, Ceph distribuye los datos automáticamente.

Hardware y planificación

Lo que necesitas:

CPU con VT-x/VT-d — cualquier procesador moderno de servidor o desktop lo tiene. VT-d es importante si planeas hacer PCI passthrough (GPUs, controladores de red, etc.)
RAM: 32GB mínimo, 64GB recomendado — Proxmox consume poco, pero las VMs y los OSDs de Ceph suman. Cada OSD reserva ~1GB de RAM por defecto. Con 4 OSDs ya son 4GB solo para Ceph.
Discos dedicados para Ceph — esta es la decisión más importante

La planificación de discos:

Disco	Uso	Ejemplo
SSD/NVMe pequeño (128-256GB)	Sistema operativo Proxmox	Disco de boot
SSD/NVMe dedicados	OSDs para pool rápido	VMs, bases de datos
HDDs dedicados	OSDs para pool bulk	Backups, ISOs, templates

Para la red: en single-node, la red estándar de 1GbE es suficiente porque el tráfico de Ceph es local. En multi-nodo, una red dedicada para Ceph es prácticamente obligatoria — idealmente 10GbE, o como mínimo una VLAN separada.

Disco de sistema ≠ OSD

No uses el disco de sistema como OSD de Ceph. Parece tentador para aprovechar espacio, pero cuando Ceph se llena (y lo hará), el sistema operativo se queda sin espacio y pierdes acceso al nodo. El disco de sistema es sagrado — solo para Proxmox OS y configuración.

Instalación de Proxmox VE

Descarga la ISO de Proxmox VE desde la web oficial e instala en el SSD/NVMe de sistema. La instalación es un wizard estándar — selecciona disco, configura red, contraseña de root, y listo.

Post-instalación

Primer paso: ajustar los repositorios. Si no tienes suscripción (y para un homelab no la necesitas), cambia al repo no-subscription:

# Eliminar repo enterprise (requiere suscripción)
rm /etc/apt/sources.list.d/pve-enterprise.list

# Añadir repo no-subscription
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > \
  /etc/apt/sources.list.d/pve-no-subscription.list

# Añadir repo de Ceph no-subscription
echo "deb http://download.proxmox.com/debian/ceph-squid bookworm no-subscription" > \
  /etc/apt/sources.list.d/ceph.list

# Actualizar
apt update && apt full-upgrade -y

Suscripción de Proxmox

Proxmox funciona perfectamente sin suscripción. El repositorio no-subscription es estable y recibe actualizaciones regulares. La suscripción te da acceso al repo enterprise (mismas versiones pero con testing adicional antes de publicar) y soporte técnico. Para un homelab, el repo no-subscription es más que suficiente.

Verifica que el bridge de red vmbr0 esté configurado correctamente. Proxmox lo crea durante la instalación, pero confirma que tiene la IP estática y el gateway correcto:

cat /etc/network/interfaces

Deberías ver algo así:

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.100/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

Instalación y configuración de Ceph

Instalar Ceph

Desde la CLI del nodo Proxmox:

pveceph install

Esto instala la versión de Ceph que Proxmox soporta nativamente (Squid en PVE 8.x). La integración es completa — Proxmox gestiona la configuración, los servicios, y el monitoring de Ceph.

Inicializar el cluster de Ceph

# Inicializar Ceph con la red del cluster
pveceph init --network 192.168.1.0/24

# Crear el monitor (necesario para que Ceph funcione)
pveceph mon create

# Crear el manager (necesario para el dashboard y métricas)
pveceph mgr create

En multi-nodo crearías monitores y managers en múltiples nodos para alta disponibilidad. En single-node, uno de cada es suficiente.

Configuración para single-node

Ceph por defecto espera 3 réplicas de cada objeto, lo cual requiere 3 nodos. En single-node necesitas ajustar esto:

# Configurar Ceph para single-node
ceph config set global osd_pool_default_size 1
ceph config set global osd_pool_default_min_size 1

Sin redundancia en single-node

Con size 1, NO hay redundancia de datos. Si un disco muere, pierdes lo que había en ese OSD. Por eso PBS es crítico en este setup — tus backups son tu redundancia. En multi-nodo con size 2 o 3, Ceph replica los datos entre nodos automáticamente y puedes sobrevivir a la pérdida de un disco o un nodo entero.

Creando los OSDs — SSD y HDD por separado

Un OSD (Object Storage Daemon) es un proceso de Ceph que gestiona un disco físico. Cada disco dedicado a Ceph se convierte en un OSD.

Ceph detecta automáticamente el tipo de disco y le asigna una device class: ssd, hdd, o nvme. Esta clasificación es la base para separar el almacenamiento en pools por rendimiento.

Crear los OSDs

Desde la CLI:

# Crear OSD para cada disco dedicado
pveceph osd create /dev/sdb    # SSD
pveceph osd create /dev/sdc    # SSD
pveceph osd create /dev/sdd    # HDD
pveceph osd create /dev/sde    # HDD

O desde la GUI: Ceph → OSD → Create OSD, selecciona el disco y Proxmox hace el resto.

Verificar las device classes

ceph osd tree

bash

$ ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 3.63689 root default -3 3.63689 host pve-node 0 ssd 0.46500 osd.0 up 1.00000 1.00000 1 ssd 0.46500 osd.1 up 1.00000 1.00000 2 hdd 1.81940 osd.2 up 1.00000 1.00000 3 hdd 0.88249 osd.3 up 1.00000 1.00000

Cada OSD debe mostrar su clase correcta. Si Ceph no detecta bien la clase (raro, pero pasa con algunos controladores RAID o discos detrás de un HBA), puedes forzarla manualmente:

# Forzar device class (primero hay que quitar la actual)
ceph osd crush rm-device-class osd.0
ceph osd crush set-device-class ssd osd.0

ceph osd crush rm-device-class osd.2
ceph osd crush set-device-class hdd osd.2

CRUSH Rules — Separar pools por tipo de disco

Esta es la parte más importante del setup y donde mucha gente se pierde.

CRUSH (Controlled Replication Under Scalable Hashing) es el algoritmo que Ceph usa para decidir dónde almacenar cada objeto. Las CRUSH rules le dicen a Ceph qué discos puede usar para cada pool.

Por defecto, Ceph tiene una sola CRUSH rule (replicated_rule) que distribuye datos por todos los OSDs sin distinguir tipo. Eso significa que tus datos de VM de producción podrían acabar en un HDD lento, y tus backups en un SSD caro. No queremos eso.

Crear CRUSH rules por device class

# Rule para SSDs — solo usa OSDs con class 'ssd'
ceph osd crush rule create-replicated ssd-rule default host ssd

# Rule para HDDs — solo usa OSDs con class 'hdd'
ceph osd crush rule create-replicated hdd-rule default host hdd

La sintaxis es: ceph osd crush rule create-replicated <nombre> <root> <failure-domain> <device-class>

root: default — el nodo raíz del CRUSH map
failure-domain: host — Ceph distribuye réplicas entre diferentes hosts
device-class: ssd o hdd — solo usa discos de este tipo

Failure domain 'host' en single-node

El parámetro host como failure domain significa que Ceph intenta poner cada réplica en un host diferente. En single-node esto no aplica (solo hay un host), pero la rule funciona igual porque tenemos size 1. Cuando añadas nodos al cluster y subas el size a 2 o 3, la replicación entre hosts se activa automáticamente sin cambiar nada — la rule ya está preparada.

Verifica las rules creadas:

ceph osd crush rule ls

bash

$ ceph osd crush rule ls replicated_rule ssd-rule hdd-rule

Creando los pools — SSD pool y HDD pool

Con las CRUSH rules en su sitio, ahora creamos los pools que realmente usan esas rules.

Pool SSD — almacenamiento rápido

Para discos de VMs, bases de datos, y cualquier workload de I/O intensivo:

# Crear pool SSD con la CRUSH rule de SSDs
ceph osd pool create ssd-pool 64 replicated ssd-rule

# En single-node: sin réplica
ceph osd pool set ssd-pool size 1
ceph osd pool set ssd-pool min_size 1

# Habilitar como RBD (necesario para que Proxmox lo use para discos de VM)
ceph osd pool application enable ssd-pool rbd

Pool HDD — almacenamiento bulk

Para backups (disco de la VM de PBS), ISOs, templates, y almacenamiento general:

# Crear pool HDD con la CRUSH rule de HDDs
ceph osd pool create hdd-pool 64 replicated hdd-rule

# En single-node: sin réplica
ceph osd pool set hdd-pool size 1
ceph osd pool set hdd-pool min_size 1

# Habilitar como RBD
ceph osd pool application enable hdd-pool rbd

Calcular el número de PGs

El número de Placement Groups (PGs) afecta al rendimiento y la distribución de datos. La fórmula general es:

PGs = (OSDs × 100) / tamaño de réplica

Para un setup pequeño (2-4 OSDs por pool, size 1): 64 PGs por pool es suficiente. Para setups más grandes, 128 o 256. Proxmox tiene un autoscaler de PGs que ajusta esto automáticamente, pero un valor inicial razonable evita warnings.

Añadir los pools como storage en Proxmox

Desde la GUI: Datacenter → Storage → Add → RBD

Para el pool SSD:

ID: ceph-ssd
Pool: ssd-pool
Content: VM Disks, Containers

Para el pool HDD:

ID: ceph-hdd
Pool: hdd-pool
Content: VM Disks, Containers, ISO Images, Container Templates

O por CLI editando /etc/pve/storage.cfg:

rbd: ceph-ssd
    pool ssd-pool
    content images,rootdir
    krbd 0

rbd: ceph-hdd
    pool hdd-pool
    content images,rootdir,iso,vztmpl
    krbd 0

Proxmox Backup Server en VM

PBS como VM dentro del propio Proxmox es un compromiso pragmático. No es ideal — el backup está en el mismo hierro que los datos — pero es infinitamente mejor que no tener backups. Y para un homelab, funciona.

Crear la VM de PBS

Descarga la ISO de PBS desde la web de Proxmox y crea una VM con estos specs:

CPU: 2 vCPUs
RAM: 2-4 GB (PBS es muy eficiente)
Disco: 50-100GB en el pool HDD (ceph-hdd) — los backups no necesitan almacenamiento rápido
Red: bridge vmbr0, IP estática

Instala PBS normalmente. Es un wizard similar al de Proxmox — disco, red, contraseña, y listo.

Post-instalación de PBS

Accede a la interfaz web de PBS (puerto 8007) y configura:

Datastore: el disco virtual de la VM ya está montado. Crea un datastore apuntando a él.
Verificación: habilita la verificación automática de backups — PBS puede verificar la integridad de cada backup después de crearlo.

Integrar PBS con Proxmox

En el nodo Proxmox, añade PBS como storage:

Desde la GUI: Datacenter → Storage → Add → Proxmox Backup Server

ID: pbs
Server: IP de la VM de PBS
Username: root@pam
Password: la que configuraste en PBS
Datastore: el nombre del datastore que creaste
Fingerprint: PBS lo muestra en Dashboard → Show Fingerprint

O genera un API token en PBS para autenticación sin password, que es lo recomendado para automatización.

Configurar jobs de backup

En Proxmox: Datacenter → Backup → Add

Storage: pbs
Schedule: daily para VMs críticas, weekly para el resto
Selection: selecciona las VMs/CTs a incluir
Mode: Snapshot (no requiere apagar la VM)
Retention (pruning): configura cuántos backups mantener

Un esquema de retención razonable:

keep-daily: 7
keep-weekly: 4
keep-monthly: 3

Esto mantiene los últimos 7 backups diarios, 4 semanales, y 3 mensuales. PBS aplica pruning automáticamente después de cada backup.

Deduplicación de PBS

PBS usa deduplicación a nivel de bloque — los backups incrementales son extremadamente eficientes. Después del primer backup completo, los siguientes solo transfieren los bloques que cambiaron. Una VM de 100GB que cambia 2GB al día ocupa ~2GB por backup incremental, no 100GB. El ahorro de espacio es brutal.

Verificación y monitorización

Con todo montado, verifica que el cluster está healthy.

Estado de Ceph

ceph status

bash

$ ceph status cluster: id: a1b2c3d4-e5f6-7890-abcd-ef1234567890 health: HEALTH_OK

services: mon: 1 daemons, quorum pve-node (age 4d) mgr: pve-node(active, since 4d) osd: 4 osds: 4 up (since 4d), 4 in (since 2w)

data: pools: 2 pools, 128 pgs objects: 1.24k objects, 48 GiB usage: 52 GiB used, 3.58 TiB / 3.64 TiB avail pgs: 128 active+clean

Lo importante: HEALTH_OK, todos los OSDs up e in, y todos los PGs active+clean.

Verificar que los pools usen los discos correctos

ceph osd pool ls detail

Cada pool debe mostrar la CRUSH rule correspondiente. Busca crush_rule en la salida — debe coincidir con ssd-rule o hdd-rule.

Uso de espacio por pool

ceph df

bash

$ ceph df --- RAW STORAGE --- CLASS SIZE AVAIL USED RAW USED %RAW USED hdd 2.70 TiB 2.58 TiB 123 GiB 126 GiB 4.56 ssd 930 GiB 882 GiB 47 GiB 49 GiB 5.24 TOTAL 3.64 TiB 3.46 TiB 170 GiB 175 GiB 4.72

--- POOLS --- POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL ssd-pool 1 64 45 GiB 612 45 GiB 4.88 864 GiB hdd-pool 2 64 123 GiB 634 123 GiB 4.58 2.44 TiB

Aquí ves claramente que ssd-pool usa solo los discos SSD y hdd-pool solo los HDD. Si ves que un pool usa discos del tipo incorrecto, la CRUSH rule no está bien configurada.

Monitorización continua

Proxmox integra el monitoring de Ceph en su GUI: Ceph → Status muestra IOPS, throughput, y latencia por OSD en tiempo real.

Configura notificaciones: Datacenter → Notifications — añade un endpoint (email, Gotify, webhook) y activa alertas para:

Ceph health warnings
OSD down
Pool usage > 80%
Backup job failures

Multi-nodo: escalando el setup

El mismo diseño escala sin cambios. Esto es lo que ganas:

Añadir un nodo al cluster

Desde la GUI del nuevo nodo: Datacenter → Cluster → Join Cluster. Proxmox maneja la configuración de corosync, los certificados, y la replicación de la configuración.

Añadir discos del nuevo nodo

Crea OSDs en los discos del nuevo nodo igual que antes. Ceph los detecta, les asigna la device class, y los integra en el CRUSH map automáticamente.

Habilitar replicación real

Ahora que tienes más de un nodo, sube el size de los pools:

# Replicación entre 2 nodos
ceph osd pool set ssd-pool size 2
ceph osd pool set ssd-pool min_size 1

ceph osd pool set hdd-pool size 2
ceph osd pool set hdd-pool min_size 1

Ceph empieza a rebalancear datos automáticamente — cada objeto se replica en un OSD de otro nodo. Las CRUSH rules que creamos con host como failure domain aseguran que las réplicas estén en nodos diferentes.

Mover PBS a otro nodo

En multi-nodo, puedes migrar la VM de PBS a un nodo diferente del que aloja las VMs de producción. Así, un fallo de hardware en el nodo de producción no afecta los backups.

Tips y gotchas

No llenes Ceph por encima del 80%. El rendimiento se degrada drásticamente cuando el espacio se agota. A 85%, Ceph empieza a emitir warnings. A 95%, bloquea escrituras (nearfull/full flags) y recuperarse de ese estado es doloroso. Monitoriza el uso y añade capacidad antes de llegar ahí.

Scrubs y rendimiento. Ceph hace scrubs periódicos — verificaciones de integridad de los datos. En single-node con HDDs, un deep scrub puede causar latencia notable en las VMs. Programa los scrubs en horarios de baja actividad:

# Scrubs solo entre las 2:00 y las 6:00
ceph config set osd osd_scrub_begin_hour 2
ceph config set osd osd_scrub_end_hour 6

Recovery tras fallo de OSD. Si un HDD muere, el pool HDD queda degradado pero el pool SSD sigue intacto — gracias a las CRUSH rules separadas. Cada pool es independiente. Reemplaza el disco, crea un nuevo OSD, y Ceph reconstruye los datos automáticamente (si tienes replicación > 1).

Snapshots antes de operaciones arriesgadas. Ceph RBD soporta snapshots nativos que son instantáneos y no ocupan espacio hasta que los datos originales cambian. Úsalos antes de actualizar una VM o cambiar configuraciones críticas:

# Snapshot de un disco de VM
rbd snap create ssd-pool/vm-100-disk-0@pre-upgrade

No mezcles workloads. VMs de producción en el pool SSD, todo lo demás en el pool HDD. La tentación de “solo poner esta VM pequeña en el SSD” termina con el pool lleno y todas tus VMs de producción afectadas. Sé disciplinado con la separación.

Conclusión

Con Proxmox + Ceph + PBS tienes una plataforma de virtualización completa: compute, storage tiered por rendimiento, y backups con deduplicación. Todo open source. El coste es solo el hardware.

El setup escala de 1 nodo a un cluster sin rediseñar nada. Las CRUSH rules, los pools, los jobs de backup — todo sigue funcionando cuando añades nodos. Solo cambias el size de los pools para activar la replicación real.

PBS en VM es un compromiso pragmático. Para un homelab es perfecto. Para producción seria, PBS debería estar en hardware separado, o como mínimo los backups replicados a un segundo destino — otro PBS remoto, un bucket S3, o un disco USB externo rotado (sí, en serio — una copia offline vale más que mil réplicas online si te entra un ransomware).

Si quieres montar Kubernetes encima de este Proxmox, echa un vistazo al primer post del blog — cubre el stack completo de K8s en un solo servidor, que es exactamente lo que puedes hacer con una VM en este setup.