Instalación limpia y sigue fallando: cuando empezar de cero no te salva
La opción radical que debía solucionarlo todo
Llega un momento en la resolución de problemas en el que dejas de hacer ajustes menores y decides hacer borrón y cuenta nueva con una reinstalación completa y un sistema operativo recién instalado, sin restos previos, sin datos corruptos y sin excusas.
The Proxmox Ghost: Why Fresh Server Installs Are Terrifying Admins
Ahí comienza esta historia o, mejor dicho, ahí es donde debería haber terminado.
Tras lidiar con servicios caídos, instalaciones incompletas y ausencia de registros, la decisión era sencilla: empezar completamente de cero. Formatear la unidad, reinstalar Windows Server 2022, aplicar actualizaciones y ejecutar el instalador de nuevo.
Durante un breve instante pareció un éxito. La instalación concluyó sin errores ni advertencias. Luego llegó la realidad.
El servicio que se niega a funcionar
El servicio principal, Veeam.Archiver.Service, simplemente no arranca. No es que tarde, vaya lento o esté mal configurado. Arranca y se detiene de inmediato, una y otra vez, sin registros útiles ni errores claros, solo silencio.
Eso es lo que vuelve tan desconcertante este tipo de incidencias. Falla sin dar la cara en lugar de avisar con un error visible, a un nivel tan bajo que ni el propio sistema parece entender lo que sucede.
Cuando ni los registros aportan nada
En ese punto se recurre al procedimiento habitual: revisar el Visor de eventos, examinar los registros de instalación y comprobar las dependencias del servicio. Salvo que allí no hay nada.
En Server Core no hay registros en absoluto. En Desktop Experience sí existen, pero no explican la causa del fallo.
Una reacción lo resume a la perfección: «Es sorprendente». Cuando un servicio de Windows falla sin dejar rastro, rompe uno de los supuestos básicos del soporte técnico: que los fallos dejan pistas. Aquí no dejan ninguna.
La espiral del «quizá sea esto»
Una vez que pierdes las referencias claras, la resolución de problemas pasa a ser un juego de adivinanzas. Quizá sea la versión del sistema operativo, o requisitos previos ausentes, o el hardware, o la compilación del instalador.
Y empiezan a llegar las sugerencias:
- «Server Core nunca iba a funcionar».
- «¿Por qué sigues usando la v7?».
- «Revisa los requisitos previos».
- «Prueba con Windows Server 2019».
Ninguna es un disparate, pero ninguna es definitiva. Son caminos por explorar más que soluciones demostradas.
El problema de versiones que se prefiere evitar
Hay un aspecto que reaparece con insistencia: la elección de versión. Distintas voces coinciden en lo mismo: la v7 está desfasada. Ha superado el final de su ciclo de soporte, no recibe parches recientes y la ayuda disponible es limitada.
Eso cambia el planteamiento. Quizá el entorno, el proceso de instalación e incluso el hardware sean correctos, y lo que estás combatiendo es algo que simplemente ya no está preparado para funcionar. Asimilar eso cuesta, sobre todo cuando el fallo no parece una simple incompatibilidad de versiones.
La cura de realidad de la infraestructura
Después la conversación se amplía. Alguien pregunta por las especificaciones de hardware y otro cuestiona el diseño del almacenamiento: ejecutar una base de datos JET sobre RAID por software sin una caché adecuada.
De repente, un servicio que no arranca deriva en dudas sobre todo el entorno:
- ¿Es adecuado el hardware?
- ¿Son seguras las decisiones de almacenamiento?
- ¿Están de verdad completos los requisitos previos?
Los sistemas modernos de backup no perdonan. Asumen ciertas condiciones y, cuando no se cumplen, aunque sea en detalles sutiles, las piezas fallan de maneras difíciles de entender.
Tres formas de interpretar el mismo fallo
Resulta llamativo cómo enfoca este problema cada persona.
Un grupo lo ve como un problema de configuración. Requisitos ausentes, entornos no soportados o versiones equivocadas son corregibles, y al resolverlos debería funcionar.
Otro lo considera una limitación del producto, con demasiadas dependencias ocultas y muy poca transparencia ante los fallos.
Y existe una tercera postura, la que sientes cuando estás atrapado en el problema: «Esto no debería pasar en un sistema limpio». Nace de una expectativa frustrada más que de la complicación técnica.
El patrón detrás del caos
Ya hemos visto este patrón antes. Una instalación limpia falla, los registros no aportan datos, el soporte es lento o inconcluso y las sugerencias de la comunidad apuntan en direcciones dispersas.
Al final, la «solución» suele ser un rodeo poco elegante:
- Probar con otra versión del sistema operativo
- Pasar a una versión más reciente del producto
- Modificar la arquitectura por completo
Ninguna de esas salidas garantiza el éxito, pero algo tiene que cambiar.
El servicio es solo el síntoma
Resulta tentador centrarse en el servicio que se niega a arrancar, pero solo es el síntoma. El problema de fondo es un sistema que falla sin explicar por qué. Cuando el software puede romperse en un entorno impecable sin devolver ninguna información útil, diagnosticarlo se convierte en especular.
La conclusión
Aquí no hay un desenlace limpio ni un ajuste único que lo arregle todo, solo una situación cada vez más habitual: ni siquiera empezar de cero es siempre un comienzo limpio.
Los sistemas modernos arrastran dependencias invisibles de versiones, entornos y configuraciones que no desaparecen solo por reinstalar el sistema operativo. Cuando esas dependencias no encajan, el sistema falla sin dejar rastro, y por eso resulta tan difícil confiar en él.