Backup profesional desde terminal: por qué no copiamos y pegamos (caso real)

Backup profesional desde terminal: por qué no copiamos y pegamos

Hoy ha entrado al laboratorio un móvil Android. Caso estándar: el cliente quiere asegurar todos los datos del dispositivo antes de una intervención. En el vídeo de abajo se ve lo que pasa después de las primeras comprobaciones: una ventana de terminal corriendo adb pull, transfiriendo el contenido del móvil al equipo del laboratorio a velocidad constante.

Lo que no se ve en el vídeo es lo que está pasando por debajo. Y eso es exactamente lo que separa una transferencia profesional verificable de un drag-and-drop casero.

Por qué los profesionales no usamos drag-and-drop

Cuando un cliente nos trae un dispositivo con datos críticos, hacer "arrastrar y soltar" desde el explorador de archivos es la forma más rápida... y la menos segura. Vamos por partes.

Preservación de metadata

Al arrastrar un archivo desde el móvil al PC con el explorador del sistema operativo, la fecha de creación en el destino se sustituye por la fecha actual del PC. Algunos metadatos extendidos (EXIF en fotos, permisos, ownership) pueden normalizarse o perderse en el proceso.

En recuperación de datos profesional, la metadata original es a veces el dato que importa. Una foto recuperada cuya fecha de creación no coincide con la original puede invalidar un peritaje, romper el orden cronológico de una galería de miles de imágenes, o simplemente confundir al cliente que esperaba ver sus recuerdos ordenados como los tenía.

Una transferencia desde terminal con los flags adecuados (adb pull -a, o rsync --times --perms) preserva la información tal y como estaba en el origen.

Atomicidad y reanudación

Imagínate arrastrar una carpeta de 5.000 fotos en el explorador y que se desconecte el cable a mitad. Lo que te encuentras en el destino es impredecible: algunos archivos completos, otros a medio escribir, otros simplemente ausentes. El sistema operativo te muestra un error genérico y no hay forma sencilla de saber qué quedó bien y qué no.

Una transferencia profesional desde terminal:

• detecta la desconexión y la registra,
• mantiene un manifiesto de qué ya está verificado,
• al reanudar, salta lo correcto y solo reintenta lo pendiente,
• evita escribir archivos parciales encima de los buenos.

Esto convierte una operación que sería traumática en una pausa de 30 segundos.

Verificación por hash

La pregunta clave: ¿cómo sabes que el archivo que ahora está en tu PC es bit-a-bit idéntico al original del móvil?

Con drag-and-drop, no lo sabes. Se asume. Y la asunción funciona el 99% de las veces, pero el 1% restante es donde un cliente abre un archivo importante meses después y descubre que está corrupto, sin saber si la corrupción venía del móvil o del proceso de copia.

Profesionalmente, después de la transferencia se calcula el hash SHA-256 de cada archivo en origen y destino, y se comparan. Si difieren, se vuelve a transferir solo ese archivo y se relanza el hash. Esto es lo que hace que un caso resista una auditoría o un peritaje.

Evitar duplicados (delta sync)

Si el cliente vuelve días después con el mismo dispositivo para una segunda lectura o para confirmar que falta un archivo concreto, repetir la transferencia entera de 80 GB es una pérdida de tiempo y, sobre todo, una oportunidad para que algo se rompa por reescritura innecesaria.

rsync --partial --append-verify y comandos equivalentes comparan qué cambió en origen y solo transfieren las diferencias. Más rápido, menos invasivo, más limpio.

Control de errores I/O silenciosos

Aquí viene la parte invisible. Cuando un sector del almacenamiento del móvil empieza a degradarse (especialmente en NAND envejecida), el sistema operativo a veces devuelve datos incorrectos sin lanzar un error. El explorador de archivos no te avisa de nada: simplemente copia bytes erróneos como si fueran correctos.

Una transferencia profesional puede:

• forzar relectura del sector ante sospecha,
• comparar resultados de lecturas múltiples,
• detectar inconsistencias,
• marcar el archivo como "leído pero no verificable",
• escalar el caso a recuperación a nivel inferior (lectura NAND directa) si es necesario.

Es la diferencia entre creerse que tienes los datos y saber con certeza que los tienes.

Las herramientas que usamos

No hay una sola herramienta universal. Según el dispositivo y el escenario, usamos:

• adb pull — el estándar para Android con USB Debugging activado. Es lo que se ve en el vídeo de este caso. Sin requerir root.
• rsync sobre SSH — cuando el móvil está rooteado o tenemos Termux con SSH activo. Permite delta sync, reanudación y verificación.
• dd / imagen sector-a-sector — para casos forenses o cuando hay que copiar el almacenamiento completo, incluido espacio libre con posibles archivos borrados recuperables.
• lftp / sftp — para NAS, servidores o transferencias remotas con reintento automático.
• Lectura NAND con hardware dedicado (chip-off, ISP, JTAG) — cuando el dispositivo no comunica y hay que ir directamente a la memoria. Esto es trabajo de microsoldadura, otra liga.

En el caso del Android de hoy, la herramienta fue adb pull con flags específicos. No es la más sofisticada — es la adecuada para este caso. Esa es la diferencia entre un técnico experimentado y uno que aplica siempre la misma herramienta a todos los casos.

El procedimiento del caso de hoy

Sin identificar al cliente, este es el procedimiento real que aplicamos:

1. USB Debugging activado en el móvil (Ajustes → Opciones de desarrollador → Depuración USB).
2. Verificación de conexión con adb devices. El móvil debe aparecer como device, no unauthorized. Si aparece unauthorized, se acepta el diálogo de confianza en la pantalla del móvil.
3. Directorio destino limpio y trazable con timestamp y caso identificable: ~/labwork/caso-AAAA-MM-DD/raw/. Disco de trabajo cifrado, nunca disco personal.
4. Comando con preservación de metadata: adb pull -a /sdcard/ ~/labwork/caso-AAAA-MM-DD/raw/. El flag -a mantiene fecha de modificación y modo originales.
5. Empaquetado con tar para entrega: una vez extraídos los archivos del móvil, se empaquetan en un único contenedor con tar -cvf ~/labwork/caso-AAAA-MM-DD/WhatsApp_Backup.tar ~/labwork/caso-AAAA-MM-DD/raw/WhatsApp/. La captura de pantalla de arriba es exactamente este paso: tar empaquetando la carpeta WhatsApp del móvil con todas sus notas de voz, fotos, vídeos y bases de datos. El formato .tar preserva permisos, fechas y estructura de directorios tal cual estaban en origen, y es el estándar de transferencia verificable en entornos UNIX.
6. Verificación por hash: SHA-256 del .tar resultante y de cada archivo extraído. Cualquier inconsistencia obliga a relanzar la transferencia de ese archivo concreto antes de cerrar el caso.
7. Manifiesto del proceso: listado completo con nombre, tamaño, hash y timestamp. Se entrega al cliente como prueba documental.

Todo se ejecuta en un equipo dedicado al laboratorio (no en un PC personal) con cifrado de disco activado. Los datos se borran del equipo con triple pasada DoD tras 7 días desde la entrega confirmada al cliente.

Drag-and-drop vs adb pull

Un resumen rápido de las diferencias prácticas:

• Preservación de fecha original: drag-and-drop la pierde o normaliza; adb pull con -a la mantiene.
• Verificación por hash: drag-and-drop no la hace; adb pull seguido de sha256sum sí.
• Reanudación tras corte: drag-and-drop empieza de cero; adb pull y rsync continúan desde el último archivo verificado.
• Registro del proceso: drag-and-drop deja como mucho un mensaje de error genérico; herramientas de terminal generan log completo.
• Control de errores I/O silenciosos: drag-and-drop no avisa; con herramientas adecuadas se detectan.
• Velocidad real: drag-and-drop oscila, sin throttling controlable; terminal ofrece velocidad constante y optimizable.
• Admisibilidad en peritaje: drag-and-drop no; transferencia con hash y manifiesto sí.

Qué preguntar al técnico antes de autorizar

Si vas a confiarle a alguien la recuperación o backup de un dispositivo con datos críticos, hay tres preguntas que delatan en un minuto si el técnico realmente sabe lo que hace:

1. ¿Cómo verifica la integridad de los archivos tras la transferencia?

Respuesta correcta: hash SHA-256 (u otro hash criptográfico) comparado entre origen y destino. Si la respuesta es "los abro y compruebo" o "veo que ocupan lo mismo", es señal de que no hay verificación real.

2. ¿Qué pasa si el equipo se desconecta a mitad de transferencia?

Respuesta correcta: reanuda desde el último archivo verificado. Si la respuesta es "lo vuelvo a empezar" o "copio otra vez todo", se están perdiendo horas en cada transferencia — y, peor, no hay garantía de que la segunda vuelta no introduzca nuevos errores.

3. ¿Me entrega manifiesto del proceso?

Un profesional serio te entrega los datos junto con un listado de archivos transferidos, hashes, timestamps y log del proceso. Si no menciona ninguno de estos elementos, el servicio es de nivel doméstico aunque cobre como profesional.

Por qué importa

Hacer backup desde terminal no es "cosa de hackers" ni una exageración técnica. Es la diferencia entre una transferencia profesional verificable y una operación amateur que puede silenciar errores hasta que el cliente abra un archivo importante meses después y descubra que falta o está corrupto.

En el caso del Android de hoy, los datos del cliente llegaron al equipo del laboratorio con verificación SHA-256 al 100%, manifiesto firmado por timestamp y sin un solo error de transferencia. Eso es lo que vale la diferencia.

Si tienes un dispositivo con datos críticos y no estás seguro de cómo te van a tratar la transferencia, pregunta directamente al técnico por esos tres puntos antes de autorizar. Lo que conteste te dirá más que cualquier reseña.

Más contexto sobre el servicio en recuperación de datos Android, cómo funciona el proceso completo o calculadora de presupuesto.