Etiqueta: linux

  • Salvando datos de un HDD moribundo: SMART + ddrescue paso a paso

    Diagnóstico y plan de rescate para un disco duro mecánico (HDD) con degradación física acelerada, usando los atributos SMART como evidencia y ddrescue como herramienta de recuperación.

    Estado crítico del disco (HDD Seagate 1TB)

    El análisis partió de los reportes de smartctl -a /dev/sda. El disco presentaba una degradación física acelerada y exponencial en la superficie de los platos, provocada principalmente por desgaste (21,665 horas de uso) y un historial de impactos mecánicos (ID 191 G-Sense: 492 eventos registrados).

    La gravedad se hizo evidente al comparar cómo empeoraron los atributos SMART en cuestión de días:

    Atributo SMARTEvoluciónSignificado
    Sectores Reasignados (ID 5)64 → 1,224 → 1,248El disco se está quedando sin sectores de repuesto
    Sectores Pendientes (ID 197)56 (estable)Sectores inestables esperando ser remapeados
    Errores Incorregibles (ID 187)1 → 37Errores que el hardware no pudo solucionar por sí solo
    Auto-tests (corto y extendido)Fallaron (Read failure)Bloqueo físico al intentar leer el LBA 1934650888

    Por qué estos números importan

    Un disco mecánico sano tiene sectores de repuesto reservados de fábrica para reemplazar automáticamente los que empiezan a fallar — es un proceso normal y silencioso que ocurre en cualquier disco con el paso del tiempo. El problema real empieza cuando el conteo de sectores reasignados crece de forma acelerada en pocos días (como en este caso, de 64 a más de 1,200): significa que el disco está agotando esa reserva mucho más rápido de lo esperado, y que la superficie física está fallando de forma activa, no por desgaste gradual normal.

    Los errores incorregibles son aún más serios: representan sectores que ni siquiera el propio firmware del disco pudo reparar o remapear — ahí es donde empieza la pérdida real de datos si no se actúa a tiempo.

    Estrategia de mitigación: temperatura

    Mantener el disco lo más fresco posible (en este caso, a 26°C) ayuda a estabilizar la mecánica interna y evitar la dilatación térmica de los componentes, ganando tiempo valioso antes de que el disco falle por completo. Sin embargo, esto no frena el daño físico — solo reduce el estrés adicional. La recomendación práctica es mantener el equipo apagado hasta tener listo el disco de reemplazo, y encenderlo solo el tiempo estrictamente necesario para el rescate.

    Monitoreo en tiempo real

    Para vigilar la temperatura del disco mientras se trabaja en él, sin generar lecturas SMART adicionales innecesarias que añadan estrés:

    watch -n 5 "sudo smartctl -A /dev/sdb | grep Temperature"

    Rescate de datos con ddrescue

    ddrescue es la herramienta correcta para este escenario porque, a diferencia de rsync o cp, no se detiene ante un error de lectura: registra el sector problemático en un archivo de log, lo salta, y continúa copiando el resto — maximizando la cantidad de datos recuperados incluso con un disco en mal estado. Herramientas normales de copiado abandonan la operación completa ante el primer error de I/O.

    Opción disco a disco (clonación completa)

    Copia el disco completo, sector por sector, a otro disco de igual o mayor capacidad en bytes:

    sudo ddrescue -d -f -r3 /dev/sdb /dev/sda /home/usuario/rescate.log

    Los parámetros clave: -d usa acceso directo al disco (evita la caché del sistema, más preciso para discos dañados), -f fuerza la operación incluso en dispositivos que ddrescue considera «raros», y -r3 indica 3 reintentos por sector antes de darlo por perdido y continuar.

    Opción rescate selectivo (recomendada para minimizar estrés mecánico)

    En vez de clonar el disco completo, se puede rescatar solo el contenido de una partición específica hacia una carpeta destino en otro disco sano — reduce el tiempo total de operación y el desgaste mecánico adicional sobre un disco que ya está fallando:

    sudo ddrescue -d /dev/sdb1 /home/usuario/datos_rescatados /home/usuario/rescate_datos.log

    Buenas prácticas para este tipo de rescate

    • El archivo de log de ddrescue es crítico: si el proceso se interrumpe (corte de luz, reinicio), volver a ejecutar el mismo comando con el mismo archivo de log retoma exactamente donde quedó, sin repetir sectores ya copiados.
    • Nunca trabajar directamente sobre el disco dañado para tareas que no sean estrictamente el rescate — cada lectura adicional es una oportunidad más de que un sector marginal termine de fallar.
    • Priorizar la opción selectiva cuando se sabe exactamente qué datos importan, en vez de clonar el disco completo — menos tiempo de disco encendido, menos riesgo.
    • La temperatura ayuda pero no cura: es una medida para ganar tiempo durante el rescate, no una solución — el disco debe reemplazarse sin importar cuánto se estabilicen los números tras enfriarlo.
  • Abrir puertos detrás de NAT cuando el ISP bloquea UPnP y NAT-PMP

    Un problema común en homelabs: quieres exponer un servicio P2P (un nodo, un servidor de juego, un servicio de mensajería descentralizada) a internet, pero el router del ISP tiene bloqueados los protocolos estándar de apertura automática de puertos. Este es el diagnóstico y las alternativas cuando eso pasa.

    Diagnóstico del problema

    Se intentó forzar al router del ISP a abrir el puerto de forma automática desde la terminal de la máquina local, pero ambos protocolos estándar fallaron porque el ISP los tiene bloqueados o desactivados:

    • UPnP: falló con el error No valid UPNP Internet Gateway Device found.
    • NAT-PMP: falló con el error Connection refused (errno=111), lo que confirma que el router rechaza las peticiones de reenvío de puertos.

    Comandos utilizados para el diagnóstico

    Instalación de herramientas de mapeo automático:

    sudo apt install miniupnpc natpmpc

    Intento de apertura con UPnP:

    upnpc -a $(hostname -I | cut -d' ' -f1) 18080 18080 TCP

    Intento de apertura con NAT-PMP:

    natpmpc -a 18080 18080 tcp

    Verificación local de que el servicio está escuchando en el puerto:

    sudo ss -tulpn | grep :18080

    Alternativas sin acceso al router

    Al no tener las credenciales del router ni soporte de apertura automática, estas son las alternativas para saltarse el NAT del ISP de forma gratuita, de menor a mayor esfuerzo:

    A. Usar el servicio en modo «privado» (la opción sin cambios)

    No es necesario hacer nada. El servicio funcionará haciendo conexiones salientes (outbound) sin problema — se puede sincronizar, consultar y usar localmente. El único inconveniente es que otros nodos externos no podrán iniciar conexiones hacia el equipo (inbound).

    B. Redes mesh (para conectar tus propios dispositivos)

    Si el objetivo es conectar un celular o laptop propio al servicio de casa estando fuera, sin necesitar acceso público real, la solución más simple es usar Tailscale o ZeroTier. Ambas evitan el router usando UDP hole punching, sin necesidad de configurar nada en él.

    Instalar ZeroTier:

    curl -s https://install.zerotier.com | sudo bash
    sudo zerotier-cli join [ID_DE_TU_RED]

    C. Túnel SSH inverso (para exponer el servicio 100% público y gratis)

    Se puede crear una cuenta en Oracle Cloud (Always Free Tier) para obtener un VPS gratuito con IP pública, y redirigir el tráfico desde ahí hacia el equipo local sin gastar dinero:

    ssh -N -R 18080:localhost:18080 usuario@ip_vps_gratis

    Con esto, cualquier conexión que llegue al puerto 18080 del VPS se reenvía automáticamente al puerto 18080 de la máquina local, sin que el router del ISP intervenga en absoluto.

    D. Exposición temporal (pruebas rápidas)

    Si solo se necesita exponer el puerto temporalmente, para una prueba puntual desde afuera:

    sudo snap install ngrok
    ngrok tcp 18080

    Cuál elegir según el caso

    • Modo privado — suficiente si el servicio solo se necesita para uso propio, sin depender de conexiones entrantes de terceros.
    • Red mesh (Tailscale/ZeroTier) — ideal para acceso personal remoto (celular, laptop) sin exponer nada realmente a internet público.
    • Túnel SSH inverso — la opción más robusta y permanente si se necesita exposición pública real y gratuita, aprovechando un VPS con IP fija.
    • ngrok — el más rápido de levantar, pero pensado para pruebas puntuales, no para uso permanente (la URL/puerto cambia en el plan gratuito).