Cómo verificar que una copia de seguridad realmente se restaura (sin arruinar el PC)

La capacidad de restauración es el producto, no “tener copias de seguridad”

Las copias de seguridad son un medio. Restaurar es el resultado. Si no puedes restaurar de forma fiable, no tienes copias de seguridad: tienes almacenamiento.

El truco es que “restaurar” no es una sola cosa. Una restauración puede significar:

• Restauración de archivo: “Dame taxes-2024.pdf.”
• Restauración de aplicación: “Devuélveme la base de datos a las 09:14 antes de la migración.”
• Restauración de sistema: “El PC debe arrancar y ser usable.”
• Recuperación ante desastres: “El negocio vuelve a funcionar: identidad, aplicaciones, datos, red, credenciales.”

La verificación debe coincidir con lo que afirmas poder hacer. Si tu plan es “puedo reinstalar el SO y restaurar archivos”, entonces verifica restauraciones de archivos. Si tu plan es “puedo restaurar una imagen bare-metal”, entonces verifica que arranque. Todo lo demás es teatro.

Y sí: puedes verificar restauraciones sin borrar tu máquina. Las técnicas principales son:

• Montajes de solo lectura de imágenes o snapshots de backup
• Restauraciones de prueba en un directorio de cuarentena
• Pruebas de arranque en VM usando una imagen de disco restaurada
• Checksums y comprobaciones de integridad del repositorio
• Simulacros de restauración con pasos documentados y tiempos

Una cita que vale la pena pegar en tu monitor:

“La esperanza no es una estrategia.” — General Gordon R. Sullivan

Broma #1: Las copias de seguridad son como los paracaídas—si solo las revisas después de saltar, lo estás haciendo en modo difícil.

Hechos e historia: por qué la verificación de backups es difícil

Algo de contexto ayuda porque muchos modos de fallo de backup se heredan de décadas de “generalmente funciona”. Aquí hay hechos concretos que explican el desorden actual:

1. Los primeros flujos de trabajo con cinta normalizaron “escribir una vez y esperar”. Verificar cada cinta era lento y desgastaba el medio; muchas instalaciones verificaban solo cabeceras o muestras aleatorias.
2. El término “ventana de backup” viene de los trabajos nocturnos con cinta. Moldeó el software alrededor de “terminar por la mañana”, no “restaurar rápido cuando entres en pánico”.
3. RAID redujo el tiempo de inactividad pero creó confianza falsa. La gente empezó a tratar la redundancia como backup, luego descubrió que la corrupción, el ransomware y el error humano no respetan la paridad.
4. Los checksums en sistemas de archivos (p. ej., ZFS) cambiaron expectativas. Detectan corrupción, pero no validan mágicamente la capacidad de restaurar una aplicación de forma consistente.
5. Las cadenas incrementales pueden ser frágiles. Pierde un eslabón o un índice de catálogo, y “backup exitoso” se convierte en “arqueología creativa”.
6. “Air-gapped” solía ser literal. Ahora a menudo es lógico (immutability/object-lock), porque la separación física es cara y operativamente dolorosa.
7. El ransomware cambió el modo de fallo de “disco muerto” a “todo está cifrado, incluidas las copias de red”. La verificación ahora incluye: ¿puedes restaurar datos limpios, rápido, offline?
8. La deduplicación hizo las restauraciones no evidentes. Los datos pueden existir solo como fragmentos referenciados por metadatos; perder metadatos puede ser fatal aunque los discos parezcan llenos.
9. El almacenamiento en la nube hizo la durabilidad barata pero las restauraciones potencialmente lentas. Egresos, limitaciones y tiempos de “rehidratación” se convierten en tiempo de inactividad real a menos que se prueben.

El patrón: la tecnología de backup evoluciona, pero el hábito humano persiste—la gente mide el éxito por si el trabajo terminó, no por si la restauración funciona bajo estrés.

Decide qué estás verificando: archivos, imágenes de sistema o recuperación completa

Antes de tocar una línea de comandos, decide la afirmación que quieres poder hacer. Elige una “promesa de restauración” primaria y una secundaria. De lo contrario harás un montón de comprobaciones que se sentirán productivas y no demostrarán nada.

1) Copias a nivel de archivo (la mayoría debería empezar aquí)

Herramientas típicas: rsync-based snapshots, Borg, Restic, Time Machine, Windows File History. Verificar significa:

• Las comprobaciones de integridad del repositorio tienen éxito
• Puedes listar snapshots/versiones
• Puedes restaurar una muestra aleatoria de archivos
• Permisos, marcas de tiempo y symlinks se ven correctos
• Para datos críticos: puedes restaurar todo el árbol a una nueva ubicación y comparar hashes

2) Copias basadas en imagen (estilo bare-metal)

Herramientas típicas: Veeam agents, Macrium, Clonezilla, Windows System Image Backup (legacy), algunas herramientas OEM. Verificar significa:

• La imagen es legible y montable (solo lectura)
• Puedes extraer archivos de ella
• Puedes arrancarla en una VM (la mejor prueba no destructiva)
• Tienes resuelto el manejo de drivers/bootloader (UEFI vs BIOS)

3) Copias con consistencia de aplicación

Si ejecutas bases de datos, servidores de correo o cualquier cosa con estado, las copias a nivel de archivo a menudo son “copias” en el mismo sentido en que una foto de un motor en marcha es “un motor de repuesto”. Necesitas quiescing, snapshots, WAL logs o dumps nativos de la app. Verificar significa:

• Puedes restaurar en una instancia de prueba
• El servicio arranca
• Pasas comprobaciones básicas de salud (versión de esquema, recuento de filas, replay de logs)

4) Modelo de amenazas: corrupción, ransomware y “ups”

Tu plan de verificación debe cubrir explícitamente:

• Corrupción de medio: bit rot, discos defectuosos, comportamiento raro del controlador
• Corrupción lógica: escrituras malas, aplicaciones con bugs, truncamiento silencioso
• Cambios maliciosos: ransomware, wipers, compromiso de credenciales
• Error humano: borrado, sobreescritura, sincronización de carpetas equivocada

Si solo verificas que “se pueden leer algunos bytes”, sigues expuesto a los desastres más comunes: restaurar la versión equivocada, restaurar datos cifrados o restaurar una copia que nunca capturó lo que pensabas que capturó.

Guion de diagnóstico rápido: encuentra el cuello de botella en minutos

Estás haciendo una restauración de prueba y va lenta, falla o produce resultados extraños. No divagues. Comprueba en este orden—primero/segundo/tercero—porque cada paso descarta rápidamente una gran clase de problemas.

Primero: ¿está sano el catálogo/repositorio de backups?

• Ejecuta la comprobación de integridad de la herramienta (Borg/Restic/etc.).
• Busca paquetes faltantes, índices dañados, fallos de autenticación o rarezas al hacer “prune”.
• Si el repositorio no está sano, para. Repara eso antes de afinar rendimiento.

Segundo: ¿se comporta el objetivo de restauración y el sistema de archivos?

• Confirma espacio libre, disponibilidad de inodos y permisos de escritura.
• Prueba el rendimiento bruto de escritura con un archivo temporal (luego bórralo).
• Comprueba si el antivirus/protección de endpoint está escaneando en tiempo real el directorio de restauración.

Tercero: ¿el transporte es lento o inestable?

• Para restauraciones por red: comprueba pérdida de paquetes, opciones de montaje SMB/NFS, sobrecarga de VPN.
• Para cloud/objeto: comprueba throttling, credenciales y si estás tirando desde almacenamiento frío.
• Mide con la restauración de un solo archivo grande, no con un directorio de 400k archivos pequeños.

Cuarto: ¿estás limitado por metadatos o archivos pequeños?

• Millones de archivos castigarán la latencia y los filtros de antivirus.
• Las restauraciones deduplicadas pueden estar limitadas por CPU (descompresión/descifrado) o por I/O (lecturas aleatorias).
• Prueba restaurar un subconjunto para ver si el tiempo escala linealmente o explota.

Quinto: ¿estás restaurando lo correcto?

• Confirma la marca temporal, el nombre del snapshot y la versión seleccionada.
• Busca indicios de ransomware: extensiones de archivo, entropía, “README_RESTORE_FILES”.
• Verifica que las muestras “conocidas buenas” se abran correctamente.

Tareas prácticas de verificación de restauración (comandos, salidas, decisiones)

A continuación hay tareas prácticas que puedes ejecutar en un workstation o servidor Linux. Aunque estés en Windows o macOS, las ideas se mapean fácilmente: listar backups, verificar repo, montar en solo lectura, restaurar a una sandbox, comparar checksums y hacer una prueba de arranque en VM.

Cada tarea incluye: un comando, qué significa la salida y qué decisión tomas a continuación. No son “demos bonitos”. Son los mismos movimientos que uso cuando alguien jura que las copias están bien y necesito pruebas antes de apostar el fin de semana.

Tarea 1: Confirma que estás probando la fuente de backup correcta

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
NAME   SIZE FSTYPE MOUNTPOINTS MODEL            SERIAL
sda    1.8T        /           Samsung_SSD_870   S6PUNX0T123456
sdb    3.6T ext4   /mnt/backup  WDC_WD40EFRX     WD-WCC4E7ABCDEF

Qué significa: Puedes ver qué disco es el disco de backup (/mnt/backup) y confirmar que no vas a probar por error contra el disco raíz activo.

Decisión: Si el objetivo de backup no es claramente identificable, etiquétalo ahora (etiqueta del sistema de archivos, unidad de montaje, etiqueta física). La ambigüedad es como las restauraciones se convierten en incidentes.

Tarea 2: Comprueba espacio libre y margen de inodos en el objetivo de restauración

cr0x@server:~$ df -h /restore-sandbox
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc1       500G  120G  355G  26% /restore-sandbox

cr0x@server:~$ df -i /restore-sandbox
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/sdc1      32768000 2100000 30668000    7% /restore-sandbox

Qué significa: El espacio está bien y tienes muchos inodos. Agotarse los inodos parece “No space left on device” aun cuando df -h está feliz.

Decisión: Si el uso de inodos es alto, restaura a un sistema de archivos formateado con mayor cantidad de inodos, o cambia tu enfoque de verificación (restaura menos archivos pequeños, o empaquétalos en tar primero).

Tarea 3: Validar un repositorio Borg (integridad antes que rendimiento)

cr0x@server:~$ export BORG_REPO=/mnt/backup/borg/laptop
cr0x@server:~$ borg check --verify-data
Starting full repository check
Verifying data integrity
Repository check complete, no problems found.

Qué significa: La estructura del repositorio y los chunks de datos coinciden con los hashes esperados. Esta es la forma más rápida de detectar escenarios de “parece montado, pero está corrupto”.

Decisión: Si esto falla, para. Clona el repo antes de hacer cualquier otra cosa. Las reparaciones pueden ser destructivas. Tu trabajo es preservar evidencia y opciones.

Tarea 4: Lista snapshots/archivos y confirma que la retención es real

cr0x@server:~$ borg list --short
laptop-2026-01-10T020001
laptop-2026-01-17T020001
laptop-2026-01-24T020001
laptop-2026-01-31T020001

Qué significa: Tienes múltiples puntos de restauración. Si la lista es más corta de lo esperado, las políticas de retención/prune podrían estar comiéndose el historial.

Decisión: Si solo tienes un snapshot, no tienes “copias de seguridad”, tienes un único punto de fallo con mejor marketing.

Tarea 5: Haz una restauración pequeña y quirúrgica a una sandbox

cr0x@server:~$ mkdir -p /restore-sandbox/test1
cr0x@server:~$ borg extract --progress --destination /restore-sandbox/test1 ::laptop-2026-01-31T020001 home/alex/Documents/taxes-2025.pdf
0.01 GB O 0.05 GB C 1 files restored

Qué significa: La herramienta puede materializar los datos. Esto prueba más que cualquier correo “backup succeeded” en verde.

Decisión: Si esto falla, captura el error e identifica si es por permisos, chunks faltantes o una ruta equivocada. No saltes a “el backup está mal” hasta confirmar que estás restaurando la ruta y el archivo correctos.

Tarea 6: Verifica que el archivo restaurado no está obviamente corrupto

cr0x@server:~$ file /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
/restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf: PDF document, version 1.7

cr0x@server:~$ sha256sum /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
5ef2bf9a9c3c6d1a0c7b1c0e8b0a5d2d3b2c1f1a9e0d6c5b4a3f2e1d0c9b  /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf

Qué significa: La firma del archivo es plausible. El checksum te da una identidad estable para comparaciones posteriores.

Decisión: Si file dice “data” o “ASCII text” para algo que debería ser un PDF o JPEG, sospecha de backups cifrados por ransomware o restauraciones truncadas.

Tarea 7: Revisa metadatos al azar (propietario, permisos, timestamps)

cr0x@server:~$ stat /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
  File: /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
  Size: 248112     Blocks: 488        IO Block: 4096   regular file
Device: 8,33   Inode: 131089      Links: 1
Access: (0640/-rw-r-----)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2026-01-31 02:14:03.000000000 +0000
Modify: 2026-01-29 18:51:22.000000000 +0000
Change: 2026-01-31 02:14:03.000000000 +0000

Qué significa: Los permisos y la propiedad se preservaron. Para algunas restauraciones (especialmente a shares Windows o NAS), aquí es donde las cosas fallan silenciosamente.

Decisión: Si la propiedad colapsa a root o los permisos quedan en 777, tu restauración puede “funcionar” pero tus aplicaciones fallarán. Ajusta las opciones de la herramienta de backup, las opciones de montaje o el manejo de ACLs.

Tarea 8: Comprobación de repositorio Restic + restauración selectiva

cr0x@server:~$ export RESTIC_REPOSITORY=/mnt/backup/restic/workstation
cr0x@server:~$ restic check
using repository at /mnt/backup/restic/workstation
created new cache in /home/cr0x/.cache/restic
load indexes
check all packs
check snapshots, trees and blobs
no errors were found

cr0x@server:~$ mkdir -p /restore-sandbox/restic-test
cr0x@server:~$ restic restore latest --target /restore-sandbox/restic-test --include "/home/alex/.ssh/config"
restoring  to /restore-sandbox/restic-test
Summary: Restored 1 files/dirs (1 B) in 0:00

Qué significa: La comprobación de integridad pasa y puedes restaurar un archivo sensible conocido. El config de SSH es un buen canario porque los permisos importan y la gente nota cuando están mal.

Decisión: Si restic check está limpio pero la restauración falla, sospecha de permisos del sistema de archivos en el objetivo o de una discordancia de rutas por reglas include/exclude.

Tarea 9: Verifica backups por snapshot con rsync comparando una muestra aleatoria

cr0x@server:~$ ls -1 /mnt/backup/snapshots | tail -5
2026-01-10
2026-01-17
2026-01-24
2026-01-31

cr0x@server:~$ find /mnt/backup/snapshots/2026-01-31/home/alex -type f | shuf -n 5
/mnt/backup/snapshots/2026-01-31/home/alex/Documents/taxes-2025.pdf
/mnt/backup/snapshots/2026-01-31/home/alex/Pictures/IMG_1882.jpg
/mnt/backup/snapshots/2026-01-31/home/alex/.ssh/config
/mnt/backup/snapshots/2026-01-31/home/alex/Projects/app/README.md
/mnt/backup/snapshots/2026-01-31/home/alex/Notes/meetings.txt

cr0x@server:~$ rsync -nac --delete /mnt/backup/snapshots/2026-01-31/home/alex/ /home/alex/ | head -20
sending incremental file list
.d..t...... ./
>fc........ Documents/taxes-2025.pdf
>fc........ Pictures/IMG_1882.jpg

sent 5,024 bytes  received 412 bytes  10,872.00 bytes/sec
total size is 148,801,932  speedup is 27,374.58 (DRY RUN)

Qué significa: -n hace un dry run; -c compara checksums; las líneas que empiezan con > indican diferencias de contenido. Eso puede significar que tus archivos en vivo cambiaron después del snapshot (normal) o que el snapshot no es lo que crees.

Decisión: Si ves diferencias en archivos que deberían ser estables (fotos antiguas, PDFs archivados), investiga. Puede haber corrupción silenciosa, una herramienta de sync reescribiendo archivos o la ruta del snapshot está equivocada.

Tarea 10: Monta una imagen de disco en solo lectura y navega (sin restauración riesgosa)

cr0x@server:~$ sudo mkdir -p /mnt/image
cr0x@server:~$ sudo losetup --find --partscan --read-only /mnt/backup/images/laptop-2026-01-31.img
/dev/loop7
cr0x@server:~$ lsblk /dev/loop7
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop7       7:7    0  238G  1 loop
├─loop7p1 259:0    0  512M  1 part
└─loop7p2 259:1    0  237G  1 part

cr0x@server:~$ sudo mount -o ro,noload /dev/loop7p2 /mnt/image
cr0x@server:~$ ls /mnt/image
bin  boot  etc  home  lib  opt  root  usr  var

Qué significa: Has probado que la imagen es estructuralmente legible y contiene un layout de sistema de archivos plausible. ro y noload reducen la probabilidad de modificar sistemas de archivos con journaling durante la prueba.

Decisión: Si el escaneo de particiones no muestra nada, sospecha de imagen corrupta, tipo de imagen equivocado o cifrado olvidado. Si el montaje falla, aún podrías extraer vía herramientas forenses, pero tu plan de “restauración simple” ya está en problemas.

Tarea 11: Confirma que la imagen restaurada tiene configuración del bootloader (sanidad rápida)

cr0x@server:~$ sudo test -e /mnt/image/boot/grub/grub.cfg && echo "grub.cfg present" || echo "grub.cfg missing"
grub.cfg present

cr0x@server:~$ sudo test -d /mnt_image/boot/efi && echo "EFI directory present" || echo "EFI directory missing"
EFI directory present

Qué significa: Buscas ingredientes obvios de arranque. No es definitivo, pero atrapa malentendidos como “la imagen solo capturó /home”.

Decisión: Si estos faltan y esperabas una imagen arrancable, revisa qué incluyó realmente tu herramienta de imagen. “Backup de sistema” a veces significa “algunas particiones”, que es una forma educada de decir “sorpresa”.

Tarea 12: Prueba de arranque de una imagen restaurada en una VM (la mejor prueba sin borrar)

cr0x@server:~$ qemu-system-x86_64 -m 4096 -enable-kvm -drive file=/mnt/backup/images/laptop-2026-01-31.img,format=raw,if=virtio -boot c -net nic -net user
SeaBIOS (version 1.16.3)
Booting from Hard Disk...
[    0.000000] Linux version 6.5.0 ...
Reached target Graphical Interface.

Qué significa: Este es el estándar de oro no destructivo para imágenes de backup: arranca. Acabas de probar “puedo restaurar una máquina” sin tocar el PC real.

Decisión: Si falla al arrancar, captura la salida de la consola. Culpables comunes: desajuste UEFI vs BIOS, initramfs sin drivers para virtio, root cifrado sin manejo de clave, o bootloader instalado en el lugar equivocado.

Tarea 13: Verificación de snapshot ZFS con scrub + restauración puntual

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:18:22 with 0 errors on Sun Feb  2 03:20:41 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          sda       ONLINE       0     0     0
          sdb       ONLINE       0     0     0

errors: No known data errors

cr0x@server:~$ zfs list -t snapshot -o name,creation | tail -3
tank/home@2026-01-24  Sun Jan 24 02:00 2026
tank/home@2026-01-31  Sun Jan 31 02:00 2026
tank/home@2026-02-02  Sun Feb  2 02:00 2026

cr0x@server:~$ mkdir -p /restore-sandbox/zfs-test
cr0x@server:~$ zfs clone tank/home@2026-01-31 tank/home-restore-test
cr0x@server:~$ zfs set mountpoint=/restore-sandbox/zfs-test tank/home-restore-test
cr0x@server:~$ ls /restore-sandbox/zfs-test/alex/Documents | head
invoices
taxes-2025.pdf

Qué significa: El scrub verifica checksums en disco; el clone prueba que puedes materializar una vista puntual y acceder archivos sin copiar todo el dataset.

Decisión: Si el scrub muestra errores de checksum, trata la pool como comprometida hasta entender si la redundancia los corrigió. Si clone/mount falla, podrías tener conflictos de namespace o mountpoint—arregla eso antes de una restauración real.

Tarea 14: Detectar “backups cifrados” tras un incidente de ransomware (test de entropía)

cr0x@server:~$ python3 - <<'PY'
import os, math
p="/mnt/backup/snapshots/2026-01-31/home/alex/Documents"
files=[os.path.join(p,f) for f in os.listdir(p) if os.path.isfile(os.path.join(p,f))][:20]
def entropy(data):
    from collections import Counter
    c=Counter(data)
    n=len(data)
    return -sum((v/n)*math.log2(v/n) for v in c.values())
for f in files:
    with open(f,'rb') as fh:
        b=fh.read(65536)
    e=entropy(b) if b else 0
    print(f"{e:0.2f} {os.path.basename(f)}")
PY
7.98 Q1-report.docx
7.99 taxes-2025.pdf
7.97 notes.txt

Qué significa: Entropía muy alta en muchos tipos de archivos puede ser una señal de cifrado (o formatos comprimidos). No es una condena; es una alarma de humo.

Decisión: Si la entropía es sospechosa, abre algunos archivos en un entorno de visualización seguro e inspecciona cabeceras con file. Si tus backups capturaron salida ya cifrada por ransomware, tu “restauración” es solo volver a la escena del crimen.

Tarea 15: Cronometra la restauración (porque RTO es un número, no una sensación)

cr0x@server:~$ /usr/bin/time -v borg extract --destination /restore-sandbox/perf ::laptop-2026-01-31T020001 home/alex/Projects
	Command being timed: "borg extract --destination /restore-sandbox/perf ::laptop-2026-01-31T020001 home/alex/Projects"
	User time (seconds): 92.11
	System time (seconds): 18.44
	Percent of CPU this job got: 325%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:45.33
	Maximum resident set size (kbytes): 812344
	File system outputs: 702400

Qué significa: Tienes tiempos reales, uso de CPU y I/O. Si la CPU está al 100%, el cifrado/compresión puede ser el limitador. Si los outputs del sistema de archivos son enormes y el tiempo es largo, el almacenamiento es el limitador.

Decisión: Usa estos números para decidir si tu plan de restauración cumple la realidad. Si no puedes restaurar dentro del tiempo de inactividad aceptable, cambia algo: disco objetivo más rápido, diferentes opciones de herramienta de backup o un plan de restauración por niveles.

Tarea 16: Desmontar/limpiar de forma segura (porque dejar loop devices es como convertir “prueba” en “misterio”)

cr0x@server:~$ sudo umount /mnt/image
cr0x@server:~$ sudo losetup -d /dev/loop7
cr0x@server:~$ losetup -a | grep loop7 || echo "loop7 detached"
loop7 detached

Qué significa: Tu prueba dejó el sistema limpio. Esto importa en hosts compartidos y máquinas de larga vida donde montajes y loops residuales generan confusión posterior.

Decisión: Si el desmontaje falla por “busy”, encuentra el proceso que lo mantiene (lsof +f -- /mnt/image) y detenlo. No hagas detach forzado a menos que aceptes el riesgo.

Tres microhistorias corporativas desde las trincheras de la restauración

Microhistoria 1: El incidente causado por una suposición equivocada

La empresa tenía una bonita historia de backup: incrementales nocturnos, full semanales, replicado offsite. Todos se sentían seguros. A los auditores se les mostró un PDF con gráficas de retención y una captura de pantalla del widget “último trabajo succeeded”. El problema era que el widget medía la finalización del backup, no el éxito de la restauración.

Una falla del controlador de almacenamiento tumbó el servidor de archivos primario. No era catastrófico—hasta que empezó la restauración. La herramienta pidió “volumen 12” en una secuencia que ya no existía, porque el “full” semanal no era realmente completo. Era un synthetic-full construido a partir de incrementales más metadatos en una base de datos de catálogo.

La base de datos del catálogo se había respaldado… en el mismo almacenamiento que falló. Así que el “full backup” estaba conceptualmente presente, pero prácticamente irrecuperable. Las copias estaban intactas en chunks con instrucciones faltantes.

Acabaron reconstruyendo lo suficiente para restaurar shares críticos, pero la línea temporal quedó así: dos días de triage, un día de recuperación parcial y luego una goteo de peticiones de usuarios durante semanas.

La suposición equivocada: “Un job de backup exitoso implica la capacidad de restaurar.” No lo implica. Debes verificar las rutas de restauración, incluidos catálogos, claves y dependencias de metadatos.

Microhistoria 2: La optimización que se volvió contra ellos

Otro equipo se enorgullecía de su ratio de dedupe. Afinaron su software de backup para máxima compresión y dedupe agresiva, luego movieron repositorios a discos más baratos y lentos. En el papel: enorme ahorro. En los dashboards: genial.

Luego llegó la primera restauración real a escala: un desarrollador borró un directorio de proyecto y lo necesitaba rápido. El tiempo de restauración fue horrible. El sistema de backup tuvo que rehidratar un bosque de pequeños chunks repartidos por los discos, descifrar, descomprimir y reconstruir metadatos de archivos. La CPU se disparó. Las búsquedas de disco se volvieron salvajes. La red estaba bien; el almacenamiento del repo no.

Intentaron “arreglarlo” con más threads. Eso aumentó la presión de I/O aleatorio y lo empeoró. También disparó límites de tasa en la puerta de enlace de almacenamiento de objetos que usaban para copias offsite. Ahora las restauraciones eran lentas y ruidosas.

Lo que finalmente funcionó fue aburrido: mantener una capa de restauración reciente en almacenamiento rápido (NVMe o al menos SSD decente), usar compresión sensata y tratar la dedupe como una característica de coste, no de recuperación. Aún deduplicaban—solo que no a costa del rendimiento de restauración.

El traspié: Optimizar para eficiencia de almacenamiento puede sabotear el tiempo de restauración (RTO). Las restauraciones son el carril de emergencia; no lo llenes con ladrillos para ahorrar costes.

Microhistoria 3: La práctica aburrida que salvó el día

Un pequeño grupo de operaciones tenía un ritual mensual: “viernes de simulacro de restauración”. No era glamuroso. Elegían host aleatorio, fecha aleatoria, restauraban en una VM sandbox y ejecutaban una lista corta: arrancar, iniciar sesión, verificar algunos endpoints de la app y comprobar que los conjuntos de datos más críticos estaban presentes.

La gente se quejaba porque tomaba medio día y no producía nuevas funciones. La dirección lo toleraba porque el equipo escribía informes limpios: tiempo de restauración, puntos de fallo y correcciones puestas en cola en el trabajo normal.

Entonces llegó un incidente de ransomware vía credencial de workstation comprometida. Los atacantes cifraron shares de red e intentaron borrar backups. Las settings de inmutabilidad resistieron en las copias offsite, pero eso no fue lo decisivo.

Lo decisivo fue la memoria muscular del simulacro de restauración. Ya tenían: procedimientos probados, un método conocido para seleccionar snapshots buenos y una red de restauración en cuarentena. Restauraron datos limpios, los validaron y devolvieron servicios con mínima improvisación.

La práctica salvadora: Los simulacros rutinarios convierten la recuperación de desastres de “un misterio técnico” a “una operación ensayada”. Lo aburrido es una característica.

Listas de verificación / plan paso a paso

Lista A: Verificación de copias a nivel de archivo (30–90 minutos)

1. Elige un punto de restauración. Escoge un snapshot de la semana pasada y otro del mes pasado. Estás probando retención y versionado, no solo el job de ayer.
2. Ejecuta integridad del repositorio. Para tu herramienta: borg check, restic check, etc.
3. Restaura a un directorio sandbox. Nunca restaures sobre la ruta original para pruebas.
4. Restaura una muestra aleatoria + una crítica. La aleatoria atrapa lo desconocido; la crítica atrapa la realidad del negocio.
5. Valida contenido. Usa file, abre documentos de forma segura, valida archivos comprimidos, ejecuta comprobaciones de apps si aplica.
6. Valida metadatos. Permisos, propietarios, timestamps, symlinks, ACLs donde sean relevantes.
7. Mide el tiempo. La velocidad de restauración también forma parte de “funciona”.
8. Anota los comandos exactos que ejecutaste. Si no puedes repetirlo, no lo verificaste; tuviste suerte una vez.

Lista B: Verificación de imagen sin borrar (60–180 minutos)

1. Monta en solo lectura. Prueba que puedes leer particiones y archivos.
2. Extrae un archivo. Saca un archivo de la imagen (o copia desde el FS montado) y valídalo.
3. Prueba de arranque en VM. QEMU/VirtualBox/Hyper-V—elige tu veneno. El arranque es la prueba.
4. Confirma que el login funciona. Si está cifrado, confirma que puedes suministrar la clave. Si usa TPM, planifica en torno a ello.
5. Documenta detalles del modo de arranque. UEFI vs BIOS, estado de secure boot, drivers del controlador de disco.
6. Registra tiempos y puntos problemáticos. Si tardó 2 horas en arrancar y arreglar drivers, ese es tu tiempo real de recuperación.

Lista C: Verificación consciente de ransomware (añadir 30–120 minutos)

1. Verifica que exista una copia inmutable/offline. Si el atacante puede borrarla, no es un plan de recuperación.
2. Elige un punto de restauración “conocido limpio”. Usa la línea temporal del incidente. No restaures ayer solo porque es el más reciente.
3. Escanea los datos restaurados en cuarentena. Usa escaneo offline, evita ejecutar binarios restaurados.
4. Busca indicadores de cifrado. Extensiones de archivo, entropía, cabeceras corruptas, archivos README sospechosos.
5. Restaura primero a red aislada. No reintroduzcas malware restaurando directamente en redes de producción.

Broma #2: Si tu plan de restauración depende de “la única persona que sabe cómo”, felicitaciones—has construido un RAID-0 humano.

Errores comunes: síntomas → causa raíz → solución

Esta es la parte donde dejamos de ser corteses con “mejores prácticas” y hablamos de lo que realmente falla a las 2 a.m.

1) Síntoma: “Backup succeeded”, pero la restauración dice archivo/snapshot no encontrado

Causa raíz: Estás restaurando desde un repositorio/objetivo distinto al que se hizo el backup, o la retención/prune eliminó el punto de restauración.

Solución: Verifica ruta/credenciales del repo; lista snapshots y confirma convenciones de nombres. Añade alertas sobre recuento y antigüedad de snapshots, no solo sobre el éxito del job.

2) Síntoma: La restauración funciona para algunos archivos, falla para otros con checksum o “chunk missing”

Causa raíz: Corrupción del repositorio, almacenamiento defectuoso, uploads interrumpidos o un pack de dedupe dañado.

Solución: Ejecuta checks de integridad regularmente; conserva múltiples copias independientes; no almacenes la única copia del repo en un disco de consumo sin scrubs.

3) Síntoma: Los archivos restaurados existen pero las apps no arrancan (errores de permisos, config inaccesible)

Causa raíz: ACL/xattr no preservadas, restore hecho con usuario equivocado o restauración sobre un FS que no puede representar metadatos (p. ej., FAT/exFAT).

Solución: Usa un FS que soporte los metadatos requeridos; asegura que las flags de la herramienta incluyan xattrs/ACLs; restaura como root cuando haga falta y después ajusta propiedad intencionalmente.

4) Síntoma: La restauración es dolorosamente lenta, pero la CPU está alta y el disco parece inactivo

Causa raíz: Overhead de compresión/descifrado, descompresión single-threaded o overhead de metadata/archivos pequeños combinado con escaneo antivirus.

Solución: Haz un benchmark con la restauración de un único archivo grande; excluye la ruta de restauración del escaneo en tiempo real durante las pruebas; ajusta el paralelismo con cuidado; guarda backups recientes en medios más rápidos.

5) Síntoma: Montar una imagen funciona, pero el arranque en VM falla al instante

Causa raíz: Modo de arranque mismatch (UEFI vs BIOS), falta de partición EFI, restricciones de secure boot o drivers faltantes para virtio.

Solución: Arranca la VM en el mismo modo; usa emulación SATA si no hay drivers virtio; confirma que existe la partición EFI; planifica el manejo de claves de secure boot.

6) Síntoma: La restauración termina, pero los datos son “galimatías” o no se pueden abrir

Causa raíz: Respaldaste salida cifrada de ransomware, o la herramienta copió archivos temporales mientras la app escribía (estado inconsistente).

Solución: Elige un snapshot conocido limpio; implementa backups consistentes con la aplicación (dumps de BD, snapshots con quiesce); añade archivos canario que deben abrirse correctamente.

7) Síntoma: La restauración offsite es posible pero tarda días

Causa raíz: Offsite está en enlace lento, limitado, en almacenamiento frío o nunca planificaste egreso y tiempo de rehidratación.

Solución: Mantén una capa local rápida para restauración de datos recientes; prueba restauraciones offsite trimestralmente; documenta un RTO realista para el peor caso.

8) Síntoma: Tras una restauración descubres carpetas faltantes que “deberían estar”

Causa raíz: Reglas exclude demasiado amplias, cambios en rutas, sorpresas con symlinks o respaldar la raíz equivocada.

Solución: Audita patrones include/exclude; mantiene un manifiesto de directorios críticos; prueba restauraciones de árboles completos, no solo unos cuantos archivos.

Preguntas frecuentes (FAQ)

1) ¿Puedo verificar backups sin restaurarlo todo?

Sí. Haz checks de integridad más restauraciones selectivas de archivos aleatorios y críticos. Para imágenes, monta en solo lectura y haz una prueba de arranque en VM. Estás probando la ruta, no copiando terabytes por deporte.

2) ¿Cuál es la mejor prueba no destructiva para una imagen de sistema?

Arrancar la imagen en una VM. Montar prueba legibilidad; arrancar prueba toda la pila: particiones, bootloader, kernel/initramfs y viabilidad básica del OS.

3) ¿Cuántos archivos debo revisar al azar?

Suficientes para cubrir diversidad: algunos archivos grandes, muchos pequeños, directorios distintos y elementos “pesados en metadatos” (symlinks, configs sensibles a permisos). Me gustan 20 archivos aleatorios más 10 críticos como línea base.

4) ¿Debo confiar en el comando “verify” o “check” de una herramienta?

Confía en lo que afirma: integridad estructural y criptográfica. No prueba que puedas restaurar rápido, elegir el snapshot correcto o reconstruir una app correctamente. Así que ejecuta el check y luego haz una restauración real de prueba.

5) ¿Y Windows? No estoy ejecutando comandos Linux.

El flujo de trabajo es el mismo: valida el conjunto de backups, monta la imagen en solo lectura, extrae archivos y prueba en Hyper-V o VirtualBox. Cambian los nombres; los modos de fallo no.

6) Si tengo RAID/ZFS redundante, ¿necesito verificación de restauración?

Sí. La redundancia ayuda con fallos de hardware, no con borrados, ransomware, malas actualizaciones o “sincronizar la carpeta equivocada en todas partes”. Las copias son viaje en el tiempo; RAID no lo es.

7) ¿Con qué frecuencia debo hacer simulacros de restauración?

Mensual para sistemas que te quitan el sueño. Trimestral como mínimo para el resto. Tras cambios importantes (nueva herramienta de backup, nuevo cifrado, nuevo almacenamiento), haz un simulacro inmediatamente—el cambio es donde se amontonan los problemas.

8) ¿Cuál es la diferencia entre “verificación de backup” y “prueba de recuperación ante desastres”?

La verificación demuestra que puedes restaurar datos desde medios/repositorios. Las pruebas de DR demuestran que puedes restaurar el servicio: cómputo, red, identidad, dependencias, monitorización y acceso. La verificación es necesaria; la prueba DR es la versión adulta.

9) ¿Cómo evito restaurar ransomware de vuelta a mi entorno?

Restaura en una sandbox aislada, escanea offline y elige un punto de restauración anterior a los primeros signos de compromiso. Asume que lo “más reciente” está contaminado hasta probar lo contrario.

10) ¿Necesito checksums si mi herramienta de backup ya cifra?

El cifrado no garantiza integridad a menos que sea cifrado autenticado y esté bien implementado. La mayoría de herramientas modernas hacen integridad, pero aun así quieres checks de repositorio más pruebas de restauración periódicas porque metadatos y catálogos pueden fallar.

Siguientes pasos que puedes hacer hoy

Práctico, no heroico:

1. Elige una carpeta crítica (documentos, fotos, repositorios) y haz una restauración en sandbox de 10 archivos desde un snapshot de hace una semana.
2. Ejecuta la comprobación de integridad de tu herramienta y guarda la salida en un lugar que no sea el disco de backup.
3. Mide el tiempo de restauración para un directorio medio (unos GB). Anota el número. Ese es tu RTO inicial.
4. Si usas backups de imagen, haz una prueba de arranque en VM una vez. Es la forma más rápida de convertir creencia en evidencia.
5. Programa un simulacro de restauración repetible (mensual). Ponlo en calendario como cualquier otro mantenimiento. Si no está programado, no ocurrirá.
6. Documenta los pasos de restauración en lenguaje claro con comandos exactos, dónde están las claves/contraseñas y cómo encontrar el snapshot correcto.

La verificación no es paranoia. Es control de calidad para tu yo futuro—que estará cansado, estresado y muy poco impresionado por el checkmark verde de ayer.