¿Estoy perdido? Cuando un homelab se convierte en una historia de terror con pérdida de datos
El instante en que todo empieza a desmoronarse
Supo que algo iba mal en cuanto el host volvió a estar en línea. No estaba roto del todo, y eso era peor: funcionaba a medias. La VM arrancó y los servicios se pusieron en marcha, pero luego llegaron los errores, leves pero persistentes, como si algo por debajo ya se estuviera hundiendo.
El detonante fue un corte de luz con un UPS muerto, y de pronto empezaron a colarse errores de lectura desde un datastore NVMe que siempre había sido sólido como una roca. Intentó clonar el disco, y falló al 14%. Intentó comprobar el sistema de archivos, y se lo impidió una herramienta que sencillamente no es compatible con su configuración.
Ese es el momento en que te cae encima. No hay un cuelgue ni un fallo limpio, solo la lenta constatación de que puede que estés atascado.
La versión más cruel es la que nunca ves venir: una tarea de copia de seguridad que dejó de ejecutarse hace meses y nunca avisó. Una comprobación de disponibilidad convencional no lo va a detectar, porque el servidor está en marcha. Una comprobación por envío sí; consulta 5 servicios gratuitos de monitoreo de disponibilidad para ver la diferencia entre sondear algo y esperar a que informe.
La herramienta que debía salvarte no funciona
Hay algo especialmente frustrante en tener la herramienta adecuada y aun así no poder usarla.
Hizo lo que haría cualquier administrador cuidadoso: desmontar el datastore, ejecutar VOMA y buscar corrupción. Solo que VOMA se niega a tocar un VMFS sobre NVMe. No hay alternativa ni opción oculta, solo un callejón sin salida.
¿Y el consejo oficial? Volcar los metadatos y enviarlos al soporte.
Eso puede funcionar si eres un cliente empresarial que paga. A los usuarios con licencia gratuita la sugerencia les llega de otra manera, menos como una ayuda y más como un recordatorio de que estás solo.
Algunos le quitan importancia. "Es lo que tienen las versiones gratuitas", podría decir alguien. Otros ven algo peor, un abandono lento de la comunidad de aficionados que ayudó a construir el ecosistema en primer lugar.
"Probablemente es el disco… y ese es el problema"
Empiezan a llegar las respuestas, y son directas. "Es un error de lectura. El SSD no pudo recuperar los datos". Eso es lo que significa el código de estado de NVMe. No hay misterio ni bug de software, solo hardware que no consigue entregar lo que se le pidió.
De repente el relato se aleja de VMware y se centra en decisiones tomadas antes: unidades NVMe de consumo, sin protección ante cortes de energía y quizá demasiados apagados incorrectos.
Una perspectiva es casi clínica: "Haz copia de lo que puedas y pasa página".
Otra es más reflexiva. Las unidades de consumo persiguen los benchmarks a costa de la integridad, y las cifras rápidas quedan genial hasta que se va la luz y los datos que hay debajo no sobreviven al golpe.
No todo el mundo está de acuerdo en que sea tan simple. Hay quien sostiene que incluso las configuraciones empresariales pueden fallar en las condiciones adecuadas, porque el hardware no es perfecto, aunque el margen de error es muy distinto.
El riesgo oculto de "funciona bien"
Lo que resulta casi cruel es que la VM sigue funcionando. Arranca, los servicios corren y nada está roto a simple vista. Esa ilusión de estabilidad es lo que la hace peligrosa, porque por debajo las lecturas fallan, los bloques no son fiables y el siguiente acceso puede ser el que lo rompa todo definitivamente.
Alguien lo resumió a la perfección: "Es una suerte que todavía puedas acceder, así que haz la copia antes que cualquier otra cosa".
Ahí es donde la gente se divide. Unos ven una situación recuperable: sacar los datos, reconstruir y seguir adelante. Otros ven una bomba de relojería, en la que cada minuto de más dedicado a diagnosticar aumenta la probabilidad de perderlo todo.
Y luego hay una tercera reacción, la curiosidad: las ganas de entender qué salió mal, incluso cuando lo más seguro es dejar de escarbar.
La configuración que multiplicó el daño
Entonces llega la constatación dolorosa. Tenía dos SSD en un mismo datastore, unidos para no tener que pensar en dónde colocar cada cosa. En su momento le pareció eficiente, limpio y flexible.
Ahora esa decisión de diseño está amplificando el problema. Un fallo no se queda aislado; se extiende por todo el conjunto de datos, y lo que podría haber sido un problema acotado se vuelve sistémico.
"No uses nunca extents de VMFS", advierte alguien. Los extents no están rotos, dice el argumento, pero amplían el radio de impacto cuando algo acaba fallando, como siempre pasa. Es una de esas lecciones que solo se quedan grabadas después de doler.
Aquí también hay matices. Algunos sostienen que los extents están bien si entiendes los riesgos y planificas en consecuencia, mientras que otros los tratan como una trampa a punto de saltar.
La realidad cotidiana de tener un homelab
En algún momento los detalles técnicos se difuminan y toma el relevo algo más humano.
Él mismo lo admite: hubo señales de aviso. El UPS no era el ideal, los apagados no siempre eran limpios y el hardware no era de nivel empresarial. Pero los homelabs son así: un conjunto de compromisos y experimentos que cambian coste por fiabilidad. La mayor parte del tiempo esos compromisos funcionan, hasta que dejan de hacerlo.
Un disco averiado y una función que falta son solo parte de lo que pasó aquí. El panorama más amplio es el frágil equilibrio entre "suficientemente bueno" y "a un fallo de perderlo todo".
Al final, "¿Estoy perdido?" no tiene una respuesta limpia. Depende de lo que copiaste y de lo que no.