Storage

Problema En entornos Proxmox es frecuente cambiar el disco de arranque o añadir un pool ZFS para alojar máquinas virtuales y contenedores. Cuando los backups están almacenados en un Proxmox Backup Server (PBS) y la infraestructura original usaba LVM, la restauración directa a un pool ZFS puede colgar indefinidamente. El proceso se queda en recovering backed‑up configuration from pbs:backup… y nunca aparecen mensajes en dmesg ni en los logs de tareas. El mismo backup se restaura sin problemas si el destino sigue siendo LVM. ...

Problema En entornos de archivos compartidos (SMB) es frecuente que procesos automáticos de ingestión y limpieza de datos dejen rastros de carpetas con ACLs corruptas, atributos de solo lectura, o bloqueos de procesos. Cuando un administrador intenta borrar esos recursos, el sistema devuelve Access denied incluso bajo cuentas con privilegios de Administrador local o incluso bajo el contexto SYSTEM. El síntoma típico es: Access is denied. Este bloqueo impide la rotación de datos, llena volúmenes y rompe pipelines de backup. El problema no es exclusivo de un servidor concreto; cualquier Windows Server que sirva como repositorio de ingestión masiva puede encontrarse con archivos que se resisten a ser eliminados por razones de permisos, herencia rota o manejadores abiertos. ...

Problema En muchos homelabs el objetivo es combinar bajo coste, alta disponibilidad y recuperación rápida ante fallos de hardware o errores humanos. La dificultad surge cuando se intenta cubrir tres capas de protección (fallos físicos, borrados accidentales y pérdida total del nodo) sin crear una complejidad que haga que el propio proceso de respaldo sea el punto débil. Los administradores suelen mezclar snapshots locales, copias de seguridad de máquinas virtuales y replicación a otro host, pero terminan con huecos: la configuración del propio hypervisor queda sin respaldo, la replicación se hace sobre redes domésticas poco fiables o se generan redundancias innecesarias que consumen espacio y tiempo. ...

Problema Los entornos que generan gran volumen de eventos en CloudWatch Logs suelen ver que la factura de ingestión supera con creces el costo de almacenamiento. Cada gigabyte de datos enviados a CloudWatch se factura a alrededor de $0.50, mientras que el mismo dato comprimido y guardado en S3 cuesta menos de $0.04 por mes. Cuando los logs son escritos intensamente y rara vez consultados, la arquitectura tradicional de CloudWatch se vuelve ineficiente: se paga por la ingestión aunque la mayor parte del valor reside en la retención a largo plazo. ...

Problema Muchas pymes operan con servidores físicos aislados, sin respaldo ni estrategia de recuperación. Cuando el número de usuarios supera los 30‑50, la gestión de actualizaciones, fallos de hardware y la expansión de capacidad se vuelve costosa y arriesgada. El reto típico es migrar esas cargas –controlador de dominio, servidores de archivos y aplicaciones críticas como CAD – a una infraestructura virtual que ofrezca: Alta disponibilidad (HA) mínima sin romper el presupuesto. Almacenamiento compartido que permita mover máquinas virtuales (VM) entre nodos. Un plan de respaldo centralizado y sencillo de administrar. En la práctica, los administradores deben decidir entre comprar un SAN tradicional, usar un NAS con iSCSI o aprovechar Storage Spaces Direct (S2D) integrado en Windows Server. Cada opción tiene implicaciones de coste, complejidad y rendimiento que varían según el perfil de la carga (I/O intensivo vs. solo archivos) y el margen de crecimiento esperado. ...

Problema En entornos híbridos o 100 % cloud, muchos equipos intentan montar Azure Files mediante SMB 3.0 con autenticación Kerberos gestionada por Azure AD Domain Services (Azure AD DS). La configuración funciona cuando se asignan permisos a usuarios individuales, pero los grupos creados exclusivamente en Azure AD (cloud‑only groups) no se reflejan en las listas de control de acceso (ACL) del recurso compartido. El resultado es un acceso denegado aunque la pertenencia al grupo sea correcta. ...

Problema Los proveedores de servicios gestionados (MSP) suelen comenzar con hosts Hyper‑V o VMware en modo standalone porque la puesta en marcha es rápida y la licencia de dos máquinas virtuales cubre a la mayoría de clientes. Cuando un cliente exige redundancia real, la arquitectura pasa a tres nodos + almacenamiento compartido. En la práctica, muchos MSP se encuentran evaluando Proxmox como alternativa a VMware, pero la gran incógnita es: ¿qué modelo de storage elegir (Ceph, NFS, iSCSI, SAN) y qué tan estable resulta un cluster de Proxmox en producción? La pregunta se repite en varios foros y la falta de una guía concreta lleva a pruebas improvisadas que terminan en tiempo perdido y caídas inesperadas. ...

Problema En entornos de hiper‑convergencia, es frecuente migrar máquinas virtuales de un hipervisor propietario (por ejemplo, ESXi) a una solución basada en Linux como Proxmox. Cuando el servidor es un HPE DL385 Gen10 equipado con la controladora RAID P408i‑a y una tarjeta HPE 12G SAS Expander, aparecen dos cuellos de botella habituales: El controlador RAID no está optimizado para Ceph – el firmware está pensado para RAID tradicional, no para exponer discos como dispositivos crudos. Desconocimiento del tipo de conector de la Expander – sin saber si los puertos internos son SFF‑8643, SFF‑8088 u otro, es imposible reutilizar el cableado existente al cambiar a una HBA “IT mode”. El resultado típico es una migración que se detiene en la fase de hardware: el nuevo HBA no encaja físicamente o los discos no aparecen en Proxmox. La solución pasa por identificar correctamente los conectores y elegir una HBA que pueda operar en modo “IT” (passthrough) sin necesidad de volver a cablear todo el chasis. ...

Problema Muchos administradores de Proxmox terminan usando soluciones de almacenamiento externas como TrueNAS o FreeNAS para obtener ZFS, snapshots y exportaciones NFS/iSCSI. Ese enfoque introduce una capa adicional de gestión, plugins que rara vez se usan y una UI que no está alineada con la de Proxmox. El resultado es una experiencia fragmentada: los nodos de Proxmox deben conectarse a un host externo, los backups y snapshots se manejan fuera del flujo de trabajo habitual y la alta disponibilidad (HA) del storage depende de la sincronía entre dos sistemas diferentes. En entornos homelab o pequeñas infraestructuras de producción, esa complejidad se traduce en más puntos de falla y mayor carga operativa. ...

Problema En entornos HA con Proxmox es frecuente que, además de máquinas Linux, haya que alojar servidores Windows que dependen de un disco compartido. Ese disco suele estar expuesto mediante Fibre Channel (FC) y es usado por una aplicación que sincroniza datos entre varios nodos Windows. Cuando el cluster Proxmox solo cuenta con Ceph y sin un fabric FC, el reto es reproducir ese modelo de “shared block” sin romper la lógica de bloqueo de la aplicación y sin perder la alta disponibilidad. ...