Hay una parte del homelab que no se arregla con apt update, un dashboard bonito ni una automatización más. El hardware envejece. Los discos acumulan horas. Las baterías del SAI pierden capacidad. Los ventiladores cogen polvo. Los mini PCs que parecían eternos empiezan a tener adaptadores de corriente raros, BIOS abandonadas o puertos que ya no dan confianza.
Lo incómodo es que casi nada avisa con educación. Un disco no espera a que tengas una tarde libre. Una batería de SAI puede pasar de “aguanta diez minutos” a “se cae en treinta segundos” con bastante poca poesía. Un switch barato puede funcionar años y luego empezar a hacer cortes tan breves que parecen culpa de todo menos del switch.
Por eso me gusta pensar en ciclo de vida, no solo en mantenimiento. Mantener es limpiar, actualizar, revisar y probar. Ciclo de vida es decidir cuándo una pieza sigue siendo válida, cuándo baja de categoría y cuándo sale del sistema.
Este artículo encaja en la ruta de operación y monitorización y toca también datos y copias de seguridad. Ya he hablado de el coste real de tener un homelab encendido 24/7 y de qué proteger con un SAI en casa. Aquí la pregunta es más seca: qué piezas físicas conviene retirar antes de que se conviertan en un problema.
La regla que uso ahora#
Mi regla actual es simple: no todo el hardware viejo es malo, pero el hardware viejo no debe sostener lo que no puedes perder.
Un mini PC antiguo puede ser perfecto para laboratorio, pruebas, CI casero o una VM que da igual reconstruir. Un disco con muchas horas puede servir para datos temporales, descargas o una copia adicional no crítica. Un switch viejo puede vivir en una mesa de pruebas. Lo que no haría es dejar fotos familiares, documentos, DNS de casa o el único camino de acceso remoto dependiendo de una pieza que ya tengo medio sentenciada.
En casa separaría el hardware en tres niveles:
- Núcleo: red base, almacenamiento principal, backups, DNS, Home Assistant, contraseñas y acceso remoto.
- Servicios útiles: media, automatizaciones, herramientas de trabajo, repositorios, dashboards.
- Laboratorio: pruebas, cargas temporales, cacharreo, cosas que puedo romper sin explicar nada a nadie.
El núcleo merece hardware aburrido y con margen. El laboratorio puede aprovechar restos. Mezclarlos es cómodo al principio y caro cuando algo falla.
Discos duros: horas, temperatura y restauración#
Los discos son la pieza donde más fácil es autoengañarse. Mientras el NAS enseña todo en verde, uno tiende a pensar que está bien. Pero “verde” no significa “eterno”. Significa que, ahora mismo, no hay una alarma clara.
Backblaze publica estadísticas de fiabilidad con volúmenes enormes. En sus datos de Q1 2026 hablaban de cientos de miles de discos monitorizados y una tasa anualizada de fallo alrededor del 1,24% para ese trimestre. Sus datos históricos descargables sirven para una idea importante: incluso en flotas bien medidas, los discos fallan. No todos, no siempre, no de forma predecible para tu unidad concreta.
En un homelab no puedo sacar conclusiones estadísticas finas de tres o seis discos. Lo que sí puedo hacer es no tratarlos como si fueran inmortales.
Miraría estas señales:
- Horas de encendido.
- Errores reasignados o pendientes.
- Temperatura habitual.
- Ruido nuevo.
- Vibraciones.
- Fallos de SMART.
- Edad de compra.
- Si ese modelo ya me ha dado guerra.
Synology documenta la programación de pruebas S.M.A.R.T. desde Storage Manager y recomienda separar pruebas por disco y lanzarlas cuando el sistema esté menos ocupado. Su guía sobre S.M.A.R.T. en DSM y la página de HDD/SSD en Storage Manager no hacen magia, pero recuerdan algo útil: hay que mirar la salud de los discos de forma programada, no solo cuando duele.
Mi política doméstica sería:
- Prueba SMART corta semanal.
- Prueba extendida mensual o bimensual, según tamaño y carga.
- Scrub o verificación del sistema de archivos si la plataforma lo permite.
- Alerta real si aparece un sector pendiente, un fallo SMART o temperatura sostenida fuera de rango.
- Registro de fecha de compra y garantía.
Y la parte menos vistosa: restauración probada. Un disco sano sin backup sigue siendo un riesgo. Un disco viejo con backup probado puede ser menos angustioso. Por eso enlazaría esta rutina con la prueba real de restauración de backups y con las comprobaciones post-backup. El disco no es la estrategia. Es una pieza de la estrategia.
SSD y NVMe: menos ruido, otros sustos#
Los SSD parecen menos dramáticos porque no hacen ruido y no tienen platos girando. Eso es una ventaja y una trampa. Cuando un HDD empieza a sonar raro, al menos te mira mal desde la bahía. Un SSD puede pasar de normal a solo lectura o muerto sin tanto teatro.
No me obsesionaría con el desgaste si son SSD decentes y la carga es normal. Para VMs, contenedores y bases de datos pequeñas, muchos SSD modernos aguantan años sin despeinarse. Pero sí vigilaría tres cosas:
- TBW o porcentaje de vida útil.
- Temperatura en NVMe.
- Espacio libre real.
El espacio libre importa más de lo que parece. Un SSD lleno, caliente y escribiendo logs o bases de datos todo el día envejece peor que uno con margen. En mini PCs compactos, los NVMe pueden calentarse bastante. Si el equipo vive en un armario cerrado o encima de otro aparato caliente, ya no es un detalle.
Para el núcleo del homelab, evitaría usar SSD de procedencia dudosa como almacenamiento principal. Barato está bien para laboratorio. Para bases de datos, documentos, Paperless, fotos o VMs importantes, prefiero marcas decentes, backups y una ruta clara de sustitución.
Baterías del SAI: calendario antes que fe#
Las baterías del SAI son candidatas perfectas a la negligencia. Compras el SAI, lo enchufas, deja de dar guerra y tres años después asumes que sigue igual. No sigue igual.
APC indica en su FAQ oficial que la mayoría de baterías VRLA de sus UPS deberían durar entre tres y cinco años, dependiendo de temperatura, descargas y entorno. Eaton, en su página de baterías UPS, también trata las baterías como consumibles con cobertura y reemplazo, no como piezas eternas.
Mi lectura práctica: a partir del tercer año, una batería de SAI entra en zona de vigilancia. A partir del quinto, si protege algo importante, no quiero depender de la esperanza.
La rutina que usaría:
- Apuntar fecha de compra del SAI.
- Apuntar fecha de cambio de batería.
- Probar evento de batería al menos una vez al año.
- Revisar runtime estimado frente a carga real.
- Cambiar batería antes si hay hinchazón, olor raro, calor excesivo, error de self-test o caída rápida.
- No exprimir la batería hasta el 0% en pruebas domésticas.
Esto conecta directamente con la guía de SAI para homelab y apagado ordenado. Un SAI no es una compra única. Es una pieza con mantenimiento. Si protege NAS, router, switch o el nodo que coordina apagados, su batería tiene calendario.
Mini PCs: cuándo bajarlos de categoría#
Los mini PCs son maravillosos para homelab. Consumen poco, hacen poco ruido y permiten montar Proxmox, Docker, K3s o un nodo de servicios con bastante dignidad. Pero tampoco son eternos.
Yo miraría estos síntomas:
- Fuente de alimentación inestable o muy caliente.
- Reinicios raros sin causa clara.
- Puerto de red que negocia mal.
- BIOS sin actualizaciones desde hace años.
- NVMe demasiado caliente.
- Ventilador con ruido o polvo difícil de limpiar.
- Carga normal que ya va justa de RAM o CPU.
- Falta de repuestos sencillos.
No significa tirar el equipo. Significa cambiarlo de rol.
Un nodo que llevaba Home Assistant, DNS o Vaultwarden puede pasar a laboratorio. Un mini PC que ya no me gusta para producción puede correr pruebas de Kubernetes, runners, compilaciones, IA ligera o servicios prescindibles. La jubilación útil existe.
La pregunta que me haría no es “funciona?”. Es “me sentiría tranquilo si esto falla esta noche?”. Si la respuesta es no y el servicio importa, toca mover carga o planificar sustitución.
Aquí ayuda mucho haber pensado antes cómo dividir servicios críticos y laboratorio con dos máquinas. El hardware viejo no desaparece de golpe. Solo deja de mandar.
NAS y cajas de discos#
El NAS suele vivir demasiado tiempo porque es una caja que uno quiere olvidar. Si funciona, nadie quiere tocarlo. Tiene lógica. También es peligroso.
No me preocuparía solo por los discos. También miraría:
- Fuente de alimentación.
- Ventiladores.
- Bahías y backplane.
- Puertos de red.
- Sistema operativo con soporte.
- Actualizaciones de seguridad.
- Capacidad para restaurar fuera de esa caja.
El último punto es clave. Si el NAS muere, ¿puedo leer los datos en otro equipo? ¿Sé qué formato usa? ¿Tengo copia fuera? ¿La configuración está exportada? ¿El backup depende del mismo NAS que se acaba de morir?
Si la respuesta da vergüenza, no es un problema del NAS. Es un problema de diseño.
Para datos familiares, prefiero pensar en capas:
- NAS o servidor principal.
- Backup local separado.
- Copia fuera de casa o nube.
- Prueba de restauración.
- Inventario de dónde está cada cosa.
Esto ya se parece más a una operación aburrida, que es justo lo que quiero para fotos, documentos y recuerdos. La épica la dejamos para el laboratorio.
Switches, routers y puntos WiFi#
La red envejece de una forma especialmente molesta: con fallos intermitentes. Un cable malo, un switch cansado, una fuente débil o un punto WiFi saturado pueden fabricar síntomas que parecen DNS, servidor, Docker, Proxmox o brujería administrativa.
En el núcleo de casa, no usaría red “casi bien”. Si el router, el switch principal o el punto WiFi que cubre media casa empiezan a hacer cosas raras, los saco del camino rápido. No hay orgullo técnico en perder dos noches depurando un problema provocado por una fuente de 12 V que vale menos que una cena.
Señales de cambio:
- Cortes breves de enlace.
- Puertos que negocian a 100 Mbps sin razón.
- Calor excesivo.
- Fuente que zumba.
- Firmware abandonado con exposición a internet.
- WiFi inestable en zonas donde antes iba bien.
- Necesidad real de VLANs, PoE o más puertos que el equipo ya no cubre.
La red base debe ser aburrida. Para experimentar con VLANs, routers alternativos o reglas raras, mejor un entorno de pruebas. Ya he defendido una red doméstica sensata con VLANs, DNS y Tailscale, pero sensata también significa saber cuándo un aparato de red deja de merecer confianza.
Adaptadores, cables y fuentes: el inframundo del fallo#
Los adaptadores de corriente son los grandes sospechosos olvidados. Todo el mundo mira CPU, RAM, discos y logs. Luego el problema era una fuente barata que llevaba meses degradándose.
En un homelab lleno de mini PCs, discos USB, hubs, switches pequeños, ventiladores y docks, las fuentes importan. Mucho.
Mi inventario mínimo incluiría:
- Qué fuente alimenta cada equipo.
- Voltaje y amperaje.
- Si es original o reemplazo.
- Fecha aproximada.
- Repuesto compatible si el servicio es importante.
También revisaría cables. No con paranoia, pero sí con respeto. Un cable Ethernet malo puede hacerte perder horas. Un USB flojo en un disco externo puede corromper una copia. Un latiguillo demasiado doblado dentro de un armario puede crear problemas cuando mueves algo.
Esta es una de esas partes donde la impresión 3D y la organización física ayudan más de lo que parece. Etiquetas, bandejas y soportes no son decoración. Reducen errores cuando estás cansado. Lo conté en piezas impresas pequeñas para ordenar el rack doméstico.
Calendario de revisión que sí haría#
No montaría una ceremonia enorme. Si el mantenimiento exige una tarde entera cada mes, acabará abandonado.
Haría esto:
Cada mes:
- Revisar alertas de discos.
- Mirar backups recientes.
- Comprobar temperatura de NAS, mini PCs y NVMe.
- Revisar actualizaciones pendientes de firmware solo si afectan a seguridad o estabilidad.
- Limpiar filtros o polvo visible si toca.
Cada trimestre:
- Revisar inventario físico.
- Confirmar garantías y fechas de compra.
- Probar una restauración pequeña.
- Mirar uso real de cada equipo.
- Decidir si algo puede apagarse o bajar de categoría.
Cada año:
- Probar SAI.
- Revisar baterías.
- Revisar discos con más horas.
- Evaluar si el núcleo sigue teniendo margen.
- Hacer foto o diagrama actualizado del cableado.
- Retirar hardware que ya solo vive por pena.
La clave es que la revisión produzca decisiones. Si todos los trimestres miras lo mismo y nunca apagas, mueves ni sustituyes nada, no estás manteniendo. Estás visitando el museo.
Qué apuntaría en el inventario#
Un inventario útil no necesita ser una CMDB empresarial. Necesita responder preguntas cuando algo falla.
Para cada pieza física apuntaría:
- Nombre humano.
- Modelo.
- Número de serie si importa.
- Fecha de compra.
- Garantía.
- Rol actual.
- Nivel: núcleo, servicio útil o laboratorio.
- Consumo aproximado.
- Ubicación física.
- Fuente de alimentación.
- Dependencias.
- Plan de sustitución.
Ese último campo parece exagerado hasta que un equipo cae. “Sustituir por mini PC de reserva”, “mover servicio a NAS”, “restaurar desde backup en nodo X”, “comprar batería RBC compatible”. Una frase basta.
Ya hay una guía sobre inventario automático sin montar una CMDB. Para hardware físico, añadiría una capa manual. La automatización ve mucho, pero no sabe cuándo compraste un SAI ni dónde guardaste el adaptador de repuesto.
No renovar por ansiedad#
Hay otra trampa: convertir el ciclo de vida en excusa para comprar. Muy homelab, muy humana, bastante peligrosa.
No todo necesita renovación preventiva. Si un equipo está en laboratorio, no guarda datos importantes, consume poco y sabes reconstruirlo, puede vivir mucho tiempo. Si un disco viejo solo tiene una copia adicional de algo que ya está en dos sitios, tampoco hay drama.
La renovación preventiva tiene sentido cuando reduce riesgo real:
- Datos familiares.
- Servicios que usa más gente.
- Acceso remoto.
- Red base.
- Backups.
- Automatización de casa.
- Equipos sin reemplazo rápido.
Para lo demás, documentar y aceptar el riesgo puede ser suficiente. El objetivo no es tener hardware nuevo. Es saber qué riesgo estás aceptando.
Mi política final#
Si tuviera que dejarlo en una política doméstica, sería esta:
- El hardware crítico tiene fecha, backup y sustituto pensado.
- El hardware viejo baja de categoría antes de fallar.
- Las baterías del SAI se tratan como consumibles.
- Los discos se monitorizan, pero no se confunden con backups.
- La red base se mantiene aburrida y fiable.
- El laboratorio aprovecha restos, pero no sostiene la casa.
Esto no hace el homelab más espectacular. Lo hace más habitable.
Y esa es una diferencia importante. Un homelab familiar no debería depender de que todo aguante por orgullo. Debería estar diseñado para que las piezas envejezcan, se sustituyan y salgan del sistema sin convertir cada cambio en una pequeña crisis doméstica.
El hardware va a fallar. La parte que sí controlas es si te pilla con un plan o con cara de haber confiado demasiado en una caja con LEDs.