Lo que hace distinta a la recuperación de un SSD
Un SSD no tiene cabezales ni platos girando; guarda los datos en chips de memoria NAND gestionados por una controladora con su propio firmware. Esa controladora mantiene una tabla de traducción (FTL) que decide dónde vive realmente cada bloque, reparte el desgaste entre celdas y, en casi todas las unidades modernas, cifra todo sobre la marcha. Por eso un SSD rara vez falla «mecánicamente»: falla la electrónica, el firmware o el propio NAND, y recuperar no consiste en leer un disco, sino en entender y, a veces, reconstruir la lógica de esa controladora.
Esa diferencia tiene una consecuencia incómoda: en un disco duro, un archivo borrado suele seguir ahí hasta que algo lo sobrescribe; en un SSD, la propia unidad puede borrarlo activamente en segundos. La urgencia, entonces, no es una táctica de venta, es física.
¿Por qué TRIM puede borrar tus datos para siempre?
Cuando borras un archivo o formateas, el sistema operativo envía a la unidad el comando TRIM (o «Deallocate» en NVMe). La controladora desvincula esos bloques lógicos y los marca para la recolección de basura, el proceso interno que devuelve las celdas a su estado libre. Mientras tanto, cualquier lectura por software devuelve ceros gracias a un mecanismo llamado «cero determinista tras TRIM». En el momento en que la recolección de basura aplica el pulso de borrado sobre esas celdas, los datos desaparecen a nivel físico: ni el software ni un laboratorio pueden revertirlo.
TRIM está activo por defecto en Windows desde la versión 7 y en macOS desde 10.6.8, y en los NVMe el proceso es casi instantáneo. La única ventana de recuperación lógica es el intervalo entre que TRIM desvincula el bloque y la recolección de basura lo borra. Por eso la primera instrucción que damos por teléfono es siempre la misma: apaga la unidad y no la vuelvas a encender. Cada minuto encendida acorta esa ventana. Lo explicamos a fondo en SSD vs disco duro: por qué la recuperación no es igual.
¿Por qué fallan los SSD?
Las causas que llegan al laboratorio son, casi siempre, electrónicas o de firmware, no de uso normal:
- Muerte de la controladora. Es la causa más común de muerte súbita: la unidad funcionaba ayer y hoy la BIOS no la detecta. Suele originarse en la sección de alimentación auxiliar o en el bloque de control del firmware.
- Corrupción de firmware. Un fallo o un error conocido del firmware deja la unidad «bloqueada» (bricked); algunas familias arrastran defectos que la inutilizan sin previo aviso.
- Degradación del NAND. Las celdas tienen un número finito de ciclos de escritura; en unidades muy usadas, el desgaste acumulado provoca errores irreparables.
- Corte eléctrico. Una interrupción a media escritura puede dañar las tablas de traducción y dejar la unidad inconsistente o inaccesible.
- «No detectado en la BIOS». Más que un problema en sí, es el síntoma que comparten el fallo de controladora y la corrupción grave de firmware.
Un matiz sobre el desgaste: las memorias QLC y TLC de alta densidad que abaratan los SSD de consumo toleran menos ciclos de escritura que las antiguas MLC, y en cargas intensas —bases de datos, edición de vídeo, máquinas virtuales— envejecen antes de lo que muchos esperan. Los SSD empresariales usan NAND y sobreaprovisionamiento pensados para eso; montar unidades de consumo en un servidor es una causa silenciosa de fallos prematuros.
El cifrado lo cambia todo
Aquí está el punto que más casos decide. La mayoría de los SSD modernos cifran todos los datos con AES-256 de fábrica, y la clave de cifrado vive dentro de la controladora. Mientras la controladora funciona, el cifrado es invisible. Pero si la controladora muere, el contenido de los chips NAND es solo texto cifrado: extraer los chips por chip-off devuelve ruido, no archivos. Recuperar los datos exige, entonces, revivir la controladora original —reparando su placa o entrando en su modo de servicio—, porque sin ella no hay clave.
Lo mismo ocurre con BitLocker en modo hardware: la clave de cifrado del soporte sigue dentro de la controladora del SSD. Si muere la controladora, ni un chip de seguridad intacto en la placa base la descifra. El caso inverso sí se resuelve: si falla la placa base pero el SSD está sano, la clave de recuperación de 48 dígitos —respaldada en la cuenta de Microsoft o en Entra ID— desbloquea la unidad en otro equipo compatible. Por eso, ante un SSD cifrado, ubicar y conservar esa clave de recuperación es tan importante como el propio diagnóstico.
En el mundo corporativo esto pesa todavía más. Muchas flotas de portátiles activan el cifrado por hardware (Opal, eDrive) como política, a veces sin que el usuario lo perciba. Por eso, en cada caso documentamos primero si la unidad está cifrada y con qué mecanismo: ese dato cambia por completo la estrategia y las expectativas. Saber de antemano dónde vive la clave —en la controladora, en un chip de la placa o en una cuenta corporativa— ahorra tiempo y evita callejones sin salida.
SATA, M.2 y NVMe: ¿en qué se diferencian para recuperar?
El formato y el protocolo cambian la dificultad. Un SSD SATA con un fallo lógico o de firmware tiene buenas probabilidades cuando se trata antes de intentar reparaciones caseras. El NVMe es más exigente: usa cifrado siempre activo ligado al enclave seguro de la controladora y circuitos de alimentación más complejos, con varios rieles de voltaje independientes para la interfaz PCIe, la DRAM y los canales de NAND. Además, su comando «Deallocate» dispara una recolección de basura especialmente agresiva, lo que reduce todavía más la ventana para datos borrados.
El éxito depende mucho de qué controladora falló y de si puede revivirse para acceder al enclave seguro. Trabajamos por familias de controladora —Phison, Silicon Motion, Samsung (Elpis, Pascal), SandForce— porque cada una entra en modo diagnóstico de una forma distinta. M.2, por su parte, es solo un formato físico: una unidad M.2 puede ser SATA o NVMe por dentro, y eso define todo el procedimiento. Conviene insistir en una idea: la etiqueta del fabricante no basta para saber cómo recuperar. Dos unidades del mismo modelo pueden llevar controladoras distintas según el lote, y cada generación de firmware se comporta diferente, así que identificamos la controladora real en el diagnóstico antes de elegir la herramienta y el modo de acceso.
Señales de que un SSD está por fallar
Un SSD pocas veces avisa con ruidos, pero deja pistas. Conviene actuar —y respaldar— ante cualquiera de estas señales: lentitud repentina y sostenida en lecturas o escrituras; archivos que se corrompen o desaparecen sin explicación; el sistema que se congela al copiar datos; la unidad que pasa a modo de solo lectura, una protección que algunos SSD activan al agotar su vida útil; o que aparezca y desaparezca de forma intermitente en el administrador de discos. Las utilidades del fabricante muestran indicadores SMART de desgaste —porcentaje de vida restante, bloques reasignados, total de datos escritos— que adelantan el final. Cuando esos números se disparan, la unidad todavía funciona, pero entró en cuenta regresiva: es el momento de copiar los datos y planificar el reemplazo, no de esperar a que deje de detectarse.
¿Qué NO debes hacer con un SSD que falla?
En un SSD, los errores se pagan más caro que en un disco duro porque la ventana es más corta y la electrónica es menos indulgente:
- No lo dejes encendido. Si borraste algo por error o la unidad empezó a fallar, apágala de inmediato: mantenerla con corriente permite que la recolección de basura termine de borrar.
- No reinstales el sistema ni reformatees «para ver si arranca». Cada escritura nueva consume celdas y dispara TRIM sobre lo que quedaba.
- No ejecutes software de recuperación a la ligera. En un SSD con TRIM, escanear en vivo no devuelve lo borrado y sí puede provocar más escrituras de fondo.
- No la congeles. El viejo truco del congelador es un mito de los discos duros mecánicos y en un SSD solo añade humedad y daño.
- No intentes un chip-off casero. Quitar chips NAND sin las herramientas y la lógica de reconstrucción adecuadas, y sin poder descifrar, destruye la única copia.
Cómo recuperamos un SSD
El procedimiento se adapta a la causa, pero el principio se mantiene: nada de experimentos sobre la unidad en vivo, y bloqueo de escritura para que ningún comando de fondo —TRIM, Deallocate o recolección de basura— llegue al NAND durante el trabajo.
1. Diagnóstico en modo servicio
Con herramientas profesionales evaluamos si responde la controladora, si el fallo es de alimentación, de firmware o de NAND, y si la unidad está cifrada. En 6 horas sabemos qué vía es viable y qué esperar.
2. Reparación de placa o modo diagnóstico
Si el problema es de alimentación o circuitería de soporte, la reparación a nivel de placa devuelve el acceso a la controladora original. Si no, entramos en el modo de servicio del fabricante según la familia de controladora.
3. Lectura por controladora o chip-off
Cuando la controladora revive, leemos a través de ella. Cuando está muerta y la unidad no está cifrada, recurrimos al chip-off: extraemos los chips NAND y los leemos directamente.
4. Reconstrucción de FTL y descifrado
Reconstruimos la tabla de traducción para reordenar los datos crudos del NAND y, en unidades cifradas, aplicamos el descifrado a través de la controladora revivida.
5. Verificación y entrega
Validamos la integridad contra tu lista de prioridades y entregamos los datos en un dispositivo nuevo, con su informe.
# La unidad NVMe no es detectada por el sistema $ nvme list Node SN Model Namespace Usage (sin dispositivos) # la BIOS/SO no ve el SSD $ smartctl -i /dev/nvme0 Read NVMe Identify Controller failed # la controladora no responde # Se intenta el modo servicio del fabricante (según familia de controladora) $ pc3000-ssd --vendor phison --mode diag entrada en modo servicio... lectura de la tabla de traducción (FTL) Nota: unidad con AES-256; el descifrado depende de revivir la controladora.
Cuando el sistema no detecta el SSD, la lectura por la interfaz normal no es opción: hay que hablarle a la controladora en su modo de servicio. Y si la unidad está cifrada, esa controladora es, además, la única que tiene la clave.
SSD externos y unidades cifradas
Los SSD externos añaden una pieza más: un chip puente (USB) entre el conector y el NAND. Cuando el puente falla, la unidad «desaparece» del sistema aunque los datos sigan intactos, y la recuperación pasa por reparar o puentear ese chip. En modelos como WD My Passport SSD o SanDisk Extreme, el puente también cifra y exige la placa original para autenticar: quitar el SSD interno solo da datos bloqueados. En equipos Apple esa lógica de soldado y cifrado se lleva al extremo: lo vemos en la recuperación de datos en Mac. Por eso, con un externo que dejó de montar, la regla vale doble: no insistas conectándolo una y otra vez, que cada intento puede empeorar el daño del puente.
¿Recuperan un SSD que no aparece en la BIOS?
Sí, en muchos casos. Que la BIOS no detecte la unidad apunta casi siempre a un fallo de controladora o de firmware, no a la pérdida del NAND, así que los datos suelen seguir en los chips. La vía es revivir la controladora —por reparación de placa o por su modo de servicio— para leer a través de ella, sobre todo si la unidad está cifrada. No prometemos resultados antes de diagnosticar, pero «no aparece en la BIOS» está lejos de ser una sentencia.
Casos frecuentes en empresas panameñas
Atendemos SSD y NVMe de portátiles de dirección con información sensible, estaciones de trabajo de diseño e ingeniería, servidores con discos NVMe y unidades externas de respaldo que dejaron de montar. El patrón corporativo se repite: alguien borró o reformateó por error y siguió usando el equipo, o un NVMe «murió» de un día para otro sin aviso. En el primer caso corremos contra el reloj de TRIM; en el segundo, contra la electrónica de la controladora. Coordinamos la recepción en toda la república y, cuando el caso es crítico, activamos la línea de emergencia. Una vez recuperado, dejamos la recomendación honesta: en almacenamiento de estado sólido, la copia de seguridad frecuente no es opcional, porque la ventana para rescatar un borrado es de minutos, no de días. Antes de empezar acordamos qué datos son prioritarios —los proyectos en curso, los correos, la base de datos local— para rescatarlos primero cuando la ventana es estrecha. Y si el equipo afectado es el portátil de una persona clave en plena operación, la línea de emergencia 24/7 permite arrancar el diagnóstico sin esperar, con el recargo que ese servicio prioritario conlleva.
Preguntas frecuentes
Depende de si TRIM ya actuó. Si apagaste la unidad de inmediato, hay una ventana; si seguiste usándola, la recolección de basura pudo borrar las celdas para siempre. Lo honesto es no prometer nada hasta diagnosticar. La regla de oro: apaga ya y no escribas nada más.
No necesariamente. Ese síntoma suele ser un fallo de controladora o de firmware, no del NAND, así que los datos suelen estar. Revivimos la controladora por reparación de placa o por su modo de servicio para leer a través de ella. Es uno de los casos que más vemos.
No. El chip-off lee el contenido crudo del NAND, pero si la unidad está cifrada con AES-256 —lo habitual en NVMe modernos— ese contenido es texto cifrado sin la controladora. En esos casos la vía no es el chip-off, sino revivir la controladora original que guarda la clave.
Por lo general sí. El NVMe combina cifrado siempre activo, circuitos de alimentación más complejos y una recolección de basura más agresiva. El SATA con fallo lógico o de firmware tiene buenas probabilidades si se trata a tiempo. En ambos, el factor decisivo es no seguir usando la unidad.
Sí, con matices. Si falló el equipo pero el SSD está sano, la clave de recuperación de 48 dígitos desbloquea la unidad en otro equipo. Si murió la controladora del SSD cifrado, hay que revivirla primero, porque la clave del soporte vive en ella. Conserva siempre tu clave de recuperación.
Cada proyecto corporativo se trabaja bajo acuerdo de confidencialidad (NDA) y con cadena de custodia documentada, con procesos auditados bajo ISO 9001:2015. Al cierre purgamos de forma segura las copias de trabajo si así se acuerda.