Lista de verificación para la recuperación del servidor doméstico: contraseña, red, arranque y almacenamiento

Eva Wong

IceWhale author

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Home Server Recovery Checklist: Password, Network, Boot, and Storage

La recuperación de un servidor doméstico no debe comenzar con comandos aleatorios. Si olvidaste la contraseña, perdiste la dirección IP, rompiste la ruta de arranque o no puedes ver el almacenamiento, el movimiento más seguro es identificar primero qué capa falló: acceso, red, arranque o almacenamiento.

El orden importa. Recupera el acceso a la consola local antes de cambiar credenciales. Restaura la red antes de depender del SSH. Arregla el arranque solo después de confirmar el disco del SO. Toca el almacenamiento al final, porque el comando de reparación incorrecto en un pool degradado, arreglo RAID o sistema de archivos montado puede convertir un problema recuperable en pérdida de datos.

Detente antes de empeorar el problema

El primer paso de recuperación no es reparar. Es control de daños. No sigas forzando reinicios, intercambiando discos, reconstruyendo arreglos, formateando discos “desconocidos” o reinstalando el SO antes de saber qué falló.

Anota lo que ves. Toma fotos de las pantallas de error, el orden de arranque en BIOS, posiciones de bahías de discos, disposición de cables, arrendamientos IP del router y advertencias de almacenamiento. Un intento de recuperación suele fallar porque el usuario cambia demasiadas cosas antes de registrar el estado original.

Síntoma	Capa probable	Primera verificación segura
Contraseña de administrador olvidada	Acceso	Verifica sesión existente, clave SSH, segundo administrador o consola local
No se encuentra el servidor en la LAN	Red	Verifica la luz de enlace, el arrendamiento del router, el cable y la IP local
Arranca en modo rescate o GRUB	Arranque	Verifica el orden de arranque, el disco del SO y la opción de recuperación
El sistema operativo inicia pero faltan carpetas compartidas	Almacenamiento	Lista los discos y verifica el estado de montaje o del pool
RAID o ZFS muestran degradación	Almacenamiento	Lee el estado primero; no reconstruyas a ciegas

Si los datos importan, el primer objetivo es preservar lo que aún es legible. Un servidor que parece normal es menos importante que mantener la ruta de recuperación reversible.

Encuentra la capa fallida antes de arreglar la incorrecta

Muchos problemas de servidores domésticos parecen iguales desde afuera: la interfaz web no se abre. Eso no significa que haya fallado la misma parte. Un cable muerto, una dirección IP cambiada, un servicio web detenido, una cuenta bloqueada, un gestor de arranque roto, un pool de almacenamiento desmontado o un volumen Docker fallido pueden parecer “el servidor está caído.”

Comienza con verificaciones de bajo riesgo. ¿El dispositivo está encendido? ¿El router lo detecta? ¿La tarjeta de red muestra luces de enlace? ¿Puedes conectar un monitor y un teclado? ¿La BIOS o UEFI detecta el disco de arranque? ¿El sistema llega a una pantalla de inicio de sesión? ¿Los discos de datos son visibles?

Solo después de eso debes elegir la ruta de recuperación. La recuperación de contraseña no es reparación de red. La reparación de red no es reparación de arranque. La reparación de arranque no es reparación de almacenamiento. Mezclarlas demasiado pronto crea riesgos evitables.

La recuperación de contraseña requiere acceso local primero

Si olvidaste la contraseña de administrador, no comiences reinstalando el sistema operativo. Primero verifica si aún tienes una sesión web iniciada, un segundo usuario administrador, una clave SSH, una entrada en el gestor de contraseñas o acceso a la consola física.

El restablecimiento de contraseña solo debe hacerse en un dispositivo que usted posea o administre. Para sistemas Linux, siga el proceso de rescate documentado del sistema operativo en lugar de copiar comandos de arranque aleatorios de foros. La documentación para restablecer la contraseña root en Fedora es un ejemplo de referencia de recuperación específica del sistema operativo, pero el proceso exacto depende de su distribución y configuración de arranque.

Después de restaurar el acceso, limpie la razón por la que se necesitó la recuperación. Actualice el administrador de contraseñas, cree una cuenta de administrador de respaldo, rote las claves SSH expuestas si es necesario, confirme la configuración de autenticación de dos factores y documente cómo recuperar el acceso local la próxima vez.

La recuperación de red viene antes de la reparación remota

Un servidor que no se puede alcanzar a través de la red puede estar perfectamente saludable. Antes de cambiar almacenamiento, cargadores de arranque o aplicaciones, restaure la comunicación local.

Síntoma de red	Causa probable	Primera solución
Sin arrendamiento del router	Problema con cable, puerto de switch, NIC o DHCP	Pruebe con un cable y puerto de router conocidos como buenos
Ping funciona, la interfaz web falla	Problema con el servicio web, firewall, contenedor o puerto	Verifique el estado del servicio después de iniciar sesión localmente
SSH funciona, la interfaz web falla	Problema en la capa de aplicación	Reinicie solo el servicio afectado, no todo el servidor
El acceso local funciona, el acceso remoto falla	Problema con VPN, túnel, router o DNS	Arregle el acceso remoto después de que el acceso LAN sea estable
La IP cambió después del reinicio	El arrendamiento DHCP cambió	Reserve la IP en el router o configure una dirección estática

Las comprobaciones útiles incluyen la lista de clientes del router, luces de enlace, escaneo de IP local, salida directa del monitor y comandos básicos como ip a, ping, y sshMantenga el objetivo limitado: primero obtenga acceso confiable a la LAN, luego arregle el acceso remoto, VPN, túnel, DNS o proxy inverso más tarde.

La reparación del arranque se trata del camino de arranque, no del grupo de datos.

Una falla de arranque no significa automáticamente que sus discos de datos estén dañados. La unidad del sistema operativo, el cargador de arranque, el orden del BIOS, la entrada UEFI, el dispositivo USB, la partición de recuperación o la actualización del kernel pueden ser el problema real.

Verifique el orden de arranque antes de tocar el almacenamiento. Confirme qué disco contiene el sistema operativo y cuáles contienen datos. Si el sistema soporta una partición de recuperación, una ranura de arranque de respaldo o una opción de rescate, úsela antes de reinstalar. Para sistemas que soportan ranuras de arranque dual, un camino de recuperación puede permitir que el servidor arranque desde una partición del sistema conocida como buena mientras mantiene los datos de usuario separados.

Para los usuarios de ZimaOS, la guía de recuperación del sistema ZimaOS explica el método rápido de recuperación del sistema usando particiones de arranque de respaldo. Este tipo de recuperación es útil porque se centra en poner el sistema operativo en funcionamiento nuevamente sin tratar los discos de datos como el primer objetivo de reparación.

Si usas un servidor Linux general, la reparación del arranque puede implicar un USB en vivo, montar la partición raíz correcta, entrar en un entorno de recuperación y reparar el cargador de arranque. Haz esto solo después de identificar el disco de arranque. Instalar accidentalmente un cargador de arranque o sistema operativo en un disco de datos es una de las formas más fáciles de empeorar la recuperación.

La recuperación de almacenamiento es lo último porque tiene el mayor riesgo

El almacenamiento es donde los errores de recuperación se vuelven costosos. No inicialices, formatees, fuerces ensamblaje, reconstruyas ni repares hasta saber con qué capa de almacenamiento estás trabajando.

Comienza con preguntas de solo lectura. ¿Se detectan todos los discos? ¿Qué disco falta? ¿Está importado el pool? ¿Está montado el sistema de archivos? ¿Hay advertencias SMART? ¿Está degradado el arreglo? ¿Faltan carpetas compartidas porque el pool falló o porque el sistema operativo arrancó sin montarlas?

Si puedes leer archivos críticos, cópialos antes de intentar una reparación arriesgada. El primer objetivo de la recuperación de almacenamiento no es que el servidor parezca normal. Es preservar los datos legibles antes de que la situación cambie.

Hacer Primero	Evitar Primero
Listar discos y particiones	Formatear un disco “desconocido”
Verificar estado del pool o arreglo	Crear un nuevo pool sobre discos antiguos
Registrar el orden de las bahías de disco	Mover discos sin etiquetar
Copiar datos críticos legibles	Iniciar una reconstrucción sin confirmar el miembro fallido
Verificar respaldos antes de reparar	Asumir que RAID es una copia de seguridad

ZFS, RAID y discos individuales necesitan rutas diferentes

Un solo disco ext4 o XFS, un pool ZFS, un arreglo RAID mdadm, un disco de respaldo USB y un volumen de aplicación Docker no deben repararse de la misma manera.

Tipo de almacenamiento	Primera Verificación	Qué No Hacer Primero
Sistema de archivos Linux único	Disco visible, estado de montaje, tipo de sistema de archivos	Ejecutar reparación en el volumen incorrecto o montado
Pool ZFS	`estado de zpool`, estado de importación, dispositivos fallidos o degradados	Crear un nuevo pool sobre discos existentes
RAID por software	Estado del arreglo, miembros faltantes, estado degradado	Forzar ensamblaje sin conocer el orden de los miembros
Disco de respaldo USB	Cable, carcasa, sistema de archivos, otra máquina	Asumir que el disco falló antes de probar la carcasa
Volumen de la aplicación Docker	Ruta, permisos, archivos de base de datos, montajes bind	Eliminar y reinstalar la aplicación primero

La documentación de solución de problemas y recuperación de pools ZFS de Oracle es útil porque separa los problemas de ZFS en dispositivos faltantes, dispositivos dañados y datos corruptos. Esa distinción es importante. Un dispositivo faltante, un disco dañado y datos corruptos no requieren la misma respuesta.

ZFS tampoco usa un modelo tradicional de fsck. Para sistemas ZFS, las comprobaciones de estado, scrubs, importaciones, resilvering y copias de seguridad forman parte del pensamiento de recuperación. Para sistemas de archivos no ZFS, use la herramienta de reparación específica del sistema de archivos correcta solo después de confirmar el estado del volumen y el montaje.

La recuperación de aplicaciones debe esperar hasta que el sistema base sea estable

No comience con Docker, aplicaciones multimedia, herramientas de sincronización o paneles. Las aplicaciones están por encima del sistema base. Si el sistema operativo, la red, el montaje del almacenamiento o los permisos están rotos, la aplicación fallará nuevamente después de reiniciarla.

Confirme primero la pila base: el servidor arranca, la red local funciona, el almacenamiento está montado, los permisos son correctos y los datos críticos están respaldados. Luego revise los servicios de aplicaciones, contenedores, puertos, reglas de proxy inverso, archivos de base de datos y volúmenes de aplicaciones.

Muchas fallas de aplicaciones después de la recuperación son problemas de rutas. El pool de almacenamiento montado en una ubicación diferente. Un volumen de Docker apunta a una carpeta antigua. Un archivo de base de datos está presente pero pertenece al usuario incorrecto. Una aplicación multimedia se inicia pero no puede ver la biblioteca. Corrija la ruta de almacenamiento antes de reinstalar la aplicación.

Construya un kit de recuperación antes de la próxima falla

La mejor recuperación se prepara antes de que el servidor falle. Un servidor doméstico es más fácil de reparar cuando los detalles importantes se almacenan fuera del propio servidor.

Elemento de recuperación	Por qué es importante
Entrada en el gestor de contraseñas	Evita que la recuperación de contraseña sea el primer paso
Cuenta de administrador de respaldo	Proporciona otra vía cuando falla una cuenta
Copia de seguridad de clave SSH	Restaura el acceso al terminal sin depender solo de contraseñas
Monitor, teclado y USB de arranque	Permite la reparación local cuando se pierde el acceso a la red
Lista de reservas DHCP del router	Ayuda a encontrar el servidor después de cambios en el router o la red
Mapa de bahías de disco	Evita reemplazar o mover el disco incorrecto
Notas sobre la disposición del almacenamiento	Documenta el diseño de RAID, ZFS, pool y montaje
Archivos Compose y configuraciones de aplicaciones	Acelera la recuperación de Docker y aplicaciones
Copia de seguridad fuera de línea o fuera del sitio	Protege los datos cuando el servidor no puede repararse rápidamente

Guarde este kit en un lugar al que el servidor dañado no necesite acceder. Una nota de recuperación almacenada solo en el NAS fallido no es una nota de recuperación.

Sepa cuándo detener la recuperación DIY

Algunas fallas ya no son tareas de solución de problemas. Son situaciones de recuperación de datos. Si la única copia de datos importantes está en el servidor, cada comando debe considerarse un riesgo.

Detenga la recuperación DIY cuando falten múltiples discos, un disco haga clic, el RAID o el pool estén degradados o poco claros, se haya reemplazado el disco incorrecto, una importación de pool solicite opciones destructivas o los datos sean críticos para el negocio sin copia de seguridad.

En ese punto, apaga si es apropiado, etiqueta las unidades, documenta el estado actual, evita reconstrucciones repetidas y busca ayuda antes de que la posibilidad de recuperación disminuya. La recuperación de un servidor doméstico no se trata de demostrar que puedes arreglar todo tú mismo. Se trata de saber cuándo otro comando puede reducir la posibilidad de recuperación.

Lista final de verificación de recuperación

Paso	Acción
1	Detén los reinicios forzados y registra los síntomas actuales.
2	Confirma energía, cable, pantalla, teclado y conexión al router.
3	Revisa el BIOS o UEFI para la detección de la unidad de arranque y las unidades de datos.
4	Recupera el acceso a la consola local antes de depender de SSH o la interfaz web.
5	Restablece credenciales solo en un sistema que poseas y puedas acceder localmente.
6	Restaura el acceso LAN: DHCP, IP estática, estado del enlace y concesión del router.
7	Corrige el orden de arranque o la partición de recuperación antes de tocar los discos de datos.
8	Identifica el tipo exacto de almacenamiento: disco único, RAID, ZFS, USB o volumen de aplicación.
9	Verifica el estado del almacenamiento antes de usar herramientas de reparación, reconstrucción, importación o sistema de archivos.
10	Copia datos críticos legibles antes de una reparación riesgosa.
11	Reinicia las aplicaciones solo después de que el sistema operativo, la red, el almacenamiento y los permisos estén estables.
12	Actualiza tu kit de recuperación para que la misma falla sea más fácil la próxima vez.

La recuperación funciona mejor cuando es aburrida. Avanza desde el acceso a la red, de la red al arranque, del arranque al almacenamiento y del almacenamiento a las aplicaciones. Omite ese orden solo si ya sabes exactamente qué capa falló.

Preguntas frecuentes

¿Qué debo hacer primero si no puedo acceder a mi servidor doméstico?

Comienza con revisiones físicas y de red: energía, cable, concesión del router, salida de pantalla, acceso al teclado y consola local. No inicies la reparación del almacenamiento hasta saber si el problema es de acceso, red, arranque o almacenamiento.

¿Cómo recupero una contraseña olvidada del servidor doméstico?

Usa una sesión de administrador existente, cuenta de administrador de respaldo, clave SSH, consola local o modo de rescate específico del sistema operativo. Solo restablece una contraseña en un dispositivo que poseas o administres, y actualiza tu gestor de contraseñas después.

¿Por qué puedo hacer ping a mi servidor doméstico pero no abrir la interfaz web?

La red puede estar funcionando mientras el servicio web, contenedor, proxy inverso, firewall o puerto de la aplicación están caídos. Verifica el estado del servicio después de confirmar que el pool de almacenamiento y las rutas de la aplicación están disponibles.

¿Debo ejecutar fsck después de un apagado incorrecto?

No automáticamente. Primero identifica el sistema de archivos y confirma que el volumen es seguro para reparar. ZFS no sigue el mismo modelo fsck que los sistemas de archivos tradicionales, así que usa herramientas específicas de estado y recuperación del pool.

¿Qué debo hacer si mi pool ZFS está degradado?

Primero verifica el estado del pool, identifica el dispositivo faltante o fallido, y evita crear un nuevo pool o sobrescribir etiquetas. Si los datos son importantes y no hay respaldo, conserva los archivos legibles antes de intentar reparaciones riesgosas.

¿La reinstalación del sistema operativo borra los datos del NAS?

Depende de la configuración del disco y las opciones del instalador. Muchos servidores domésticos separan las unidades del sistema operativo y de datos, pero seleccionar el disco incorrecto durante la reinstalación puede destruir los datos. Confirma la unidad de arranque y las unidades de datos antes de reinstalar.