El enfoque seguro consiste en tratar la captura de la firma del fallo, cambiar una variable a la vez y aplicar únicamente la solución correspondiente como una secuencia de comprobaciones observables, no como un solo comando.
En un servidor doméstico Linux con una carcasa de almacenamiento conectada directamente por USB, el riesgo práctico es que los discos USB DAS se desconecten, se reinicien o desaparezcan bajo carga. Registra la identidad actual y el punto de recuperación, empieza por el discriminador menos invasivo, interpreta los resultados correctos y fallidos antes de cambiar otra variable, y detente cuando el almacenamiento se vuelva inestable o cuando la única copia recuperable quede expuesta. El flujo de trabajo siguiente solo termina cuando la carga de trabajo original funciona correctamente o cuando las pruebas alcanzan un límite que requiere escalación.
Captura la firma exacta de la desconexión
Detén las aplicaciones con muchas escrituras y recopila journalctl -k -f o dmesg -w mientras reproduces la misma transferencia. Registra las marcas de tiempo, la topología USB, el fabricante y los ID de producto del puente, la velocidad negociada, los números de serie de los dispositivos, el estado del montaje y el primer error, antes de que los mensajes de reinicio posteriores oculten el evento iniciador.
Un caso resuelto de Ask Ubuntu muestra un caso típico de interrupción y desconexión de UAS, en el que los mensajes de interrupción de UAS y la desaparición del dispositivo deben interpretarse conjuntamente. Trata esa firma como una observación acotada, no como una prueba de que todas las desconexiones se deban a un error de UAS.
Detén las pruebas y protege los datos si los reinicios se repiten durante las escrituras, el sistema de archivos pasa a ser de solo lectura, la unidad emite clics o aumentan los contadores de errores de SMART y del dispositivo. No ejecutes una reparación del sistema de archivos a través de una ruta USB inestable.
Separa primero los problemas de alimentación y de señal
Reproduce la carga de trabajo con la carcasa original y cambia después un solo elemento: el cable, el puerto del equipo anfitrión, el adaptador de corriente o un concentrador con alimentación, cuando corresponda. Mantén constantes la unidad, el sistema de archivos, la carga de trabajo y la duración. Una carcasa para varias unidades alimentada por el bus que falla solo al arrancar los discos o durante escrituras simultáneas apunta a un problema de alimentación, aunque las lecturas en reposo sean correctas.
Comprueba si el enlace reduce su velocidad, se reinicia al mover el conector o falla únicamente a través de un puerto del panel frontal o de una extensión. Sustituye un cable sospechoso por uno corto y certificado, y evita los adaptadores durante la prueba de control. Si el error sigue a un puerto o al equipo anfitrión, deja la carcasa fuera del alcance de la prueba hasta comprobar el controlador y la gestión de energía.
Esta rama se considera superada cuando la carga original permanece conectada durante dos arranques en frío y una transferencia sostenida después de un único cambio en la ruta de hardware. Si todos los cables y puertos fallan con el mismo patrón de transacción, pasa a las pruebas del protocolo del puente y a las pruebas que distinguen entre la carcasa y la unidad.
Prueba UAS como una rama de compatibilidad, no como el culpable predeterminado
Confirma que el dispositivo usa actualmente uas y captura su ID USB exacto. Solo después de reproducir interrupciones específicas de UAS debes probar el mismo dispositivo con una excepción temporal y correctamente delimitada de usb-storage, o con un equipo anfitrión que sepas que utiliza la ruta de solo transferencia masiva. Durante esta prueba discriminatoria, espera una menor profundidad de cola o un rendimiento inferior.
Un hilo de resolución de problemas de Linux Mint recomienda observar los registros del kernel en busca de errores de UAS para revelar errores relacionados con UAS mientras el dispositivo está conectado. Usa la comparación para determinar si los reinicios desaparecen con la misma carga; ver simplemente la palabra uas en un registro no demuestra que sea la causa.
Si el transporte de solo transferencia masiva permanece estable dos veces mientras UAS falla repetidamente, conserva la solución alternativa únicamente para ese ID de fabricante/producto y comprueba las opciones de firmware o sustitución de la carcasa. Si ambos transportes fallan, elimina la excepción y continúa con el aislamiento de la alimentación, el puente, la temperatura o la unidad.
Determina si los errores siguen a la unidad o a la carcasa
Coloca la unidad sospechosa en una carcasa conocida como funcional o en una ruta SATA directa, y coloca una unidad de repuesto conocida como funcional en la DAS sospechosa. Ejecuta la misma prueba de lectura no destructiva antes de cualquier prueba de estrés de escritura. Los errores que siguen a la unidad implican sus medios o su controlador; los errores que permanecen con la DAS implican el puente, el plano posterior, la refrigeración, el cable o la alimentación.
La guía de resolución de problemas sobre la unidad y la carcasa de ZimaSpace explica con más detalle la decisión basada en el intercambio de componentes. Úsala después de probar el transporte para no confundir un fallo del puente con un medio defectuoso ni ocultar una unidad que falla mediante reinicios repetidos de la carcasa.
La recuperación se considera correcta cuando la carga de trabajo original permanece estable durante la reconexión, el reinicio y la E/S sostenida, sin nuevos reinicios del kernel ni errores del dispositivo. Escala el caso o sustituye el componente cuando el fallo lo sigue de forma constante; si los resultados siguen siendo mixtos, detén las escrituras, crea una imagen de los datos críticos a través de la ruta más estable y conserva los registros para el soporte de hardware.
Soporte y Consejos
Más para leer

Guía de migración de Borg Backup para trasladar un repositorio a un nuevo almacenamiento
Mueve un repositorio de Borg como un único objeto coherente: detén las escrituras, conserva las claves y la identidad, verifica las restauraciones y, después,...

Flujo de mantenimiento del repositorio de Restic: comprobar, podar, compactar y probar la restauración
Restic no tiene un comando compact independiente: prune realiza el reempaquetado. Protege los bloqueos y el espacio libre, vuelve a comprobar después y termina...

Guía de recuperación de Time Machine en NAS para historiales de copias de seguridad dañados o abandonados
Conserva el paquete antiguo. Separa el acceso al NAS, la identidad del destino, los daños en la imagen y el historial abandonado antes de...

