Historial de archivos: la copia de seguridad subestimada que supera a «Copia mis archivos»

Qué es realmente File History (y qué no lo es)

File History es una función de respaldo a nivel de archivo y con versiones en Windows. Supervisa ubicaciones específicas (tus bibliotecas, Escritorio, Contactos, Favoritos y opcionalmente más) y copia periódicamente los archivos cambiados a un destino de respaldo. Mantiene múltiples versiones para que puedas volver al documento de ayer, no solo al snapshot semanal de una carpeta.

Es mejor protegiendo lo que cambia todo el tiempo: hojas de cálculo, presentaciones, archivos de diseño, notas, scripts y ese «final_v7_REALMENTE_FINAL.pptx» que siempre vuelve de entre los muertos.

Lo que es

• Incremental: después de la primera ejecución, copia solo los archivos cambiados.
• Con versiones: conserva múltiples revisiones de archivos.
• Recuperable por el usuario: restauración vía interfaz o línea de comandos sin necesidad de iniciar en un entorno de recuperación.
• Destino local o en red: disco externo, disco interno secundario o recurso compartido SMB.

Lo que no es

• No es una imagen del sistema: no reconstruye una instalación de SO muerta por sí sola.
• No es un plan completo de recuperación del sistema: no restaurará aplicaciones instaladas, controladores o cargadores de arranque.
• No es un archivo de cumplimiento: no es inmutable ni una herramienta de retención legal.
• No es mágico contra todo ransomware: si tu destino de respaldo está escribible y en línea, el malware a veces puede alcanzarlo.

Piensa en File History como el cinturón de seguridad, no en la jaula antivuelco. Aún necesitas un plan completo de imágenes/DR. Pero un cinturón salva vidas en los choques aburridos, y la mayoría de las pérdidas de datos son aburridas.

Por qué “copia mis archivos” falla en la vida real

Las copias manuales producen un artefacto reconfortante: una carpeta en una unidad que parece «un respaldo». Operativamente, es un montón de aristas peligrosas.

Modo de fallo: no tiene versiones

Si copias un archivo una vez a la semana, has creado una instantánea semanal que se sobrescribe o se convierte en un laberinto de carpetas con fecha. En cualquier caso, restaurar «la versión del martes por la tarde antes de que la rompiera» se vuelve una cuestión de conjeturas. File History hace la pregunta precisa: elige un archivo, elige una marca de tiempo, restaura.

Modo de fallo: los humanos optimizan para hoy

Las personas copian lo que recuerdan. Saltan lo que es grande. Saltan lo que es “temporal”. Entonces esa carpeta temporal resulta ser el único sitio donde vivía la exportación del CRM.

Modo de fallo: el respaldo es lógicamente inconsistente

Copiar manualmente suele ser arrastrar y soltar desde el Explorador. Eso no es atómico. Es fácil capturar medio proyecto en medio de guardados, con referencias faltantes. File History tampoco es una herramienta de consistencia de bases de datos, pero al menos es lo suficientemente frecuente como para que puedas retroceder a un momento antes de la inconsistencia.

Modo de fallo: no se prueba

El proceso de restauración para copias manuales es “encuentra la cosa, espera que sea la correcta”. El flujo de restauración de File History es consistente, repetible y scriptable. Probar restauraciones se vuelve un hábito, no una expedición arqueológica.

Broma #1: Un respaldo manual es como una resolución de Año Nuevo: impresionante en enero, desaparecido en marzo.

Cómo funciona File History bajo el capó

File History no hace magia a nivel de bloques. Hace ingeniería pragmática orientada a archivos: detectar archivos cambiados, copiarlos a un destino, mantener una política de retención y exponer versiones mediante una interfaz y APIs.

Las piezas en movimiento

• servicio File History y tareas programadas: orquestan escaneos y copias.
• Configuración: almacenada por usuario, con superposición de políticas disponible vía Group Policy en entornos gestionados.
• Almacenamiento destino: disco local o recurso compartido SMB en red.
• Catálogo: metadatos usados para examinar y restaurar versiones.

Qué se respalda

Por defecto, File History rastrea las bibliotecas (Documentos, Imágenes, etc.), Escritorio, Favoritos, Contactos y algunas otras ubicaciones del perfil de usuario. Puedes añadir carpetas incluyéndolas en una biblioteca o mediante políticas. Esta decisión de diseño importa: está orientado a los datos de usuario, no a “todo lo que hay en C:\”. Eso es bueno para la recuperación de datos; es malo si esperas que capture directorios de aplicaciones personalizados fuera del perfil.

Versionado y retención

File History normalmente se ejecuta con una programación (a menudo horaria por defecto), copia archivos cambiados y conserva versiones antiguas según los ajustes de retención. La retención es la parte que la gente ignora hasta que el disco de respaldo se llena y File History deja de ser útil silenciosamente.

Destinos en red (SMB) y por qué son diferentes

Respaldar en un recurso compartido NAS es conveniente, especialmente para portátiles. También introduce los dos problemas clásicos: disponibilidad (VPN, Wi‑Fi, estados de suspensión) y límite de seguridad (el ransomware a veces puede alcanzar el recurso). La respuesta correcta raramente es “no uses un recurso compartido”. La respuesta correcta es: usa un recurso compartido, pero diseñalo como almacenamiento de producción con control del radio de impacto.

Aquí va la mentalidad de confiabilidad: File History es una canalización de automatización. Las canalizaciones necesitan monitoreo, gestión de capacidad y ejercicios periódicos de restauración. Si lo tratas como una casilla para marcar, se comportará como una casilla marcada: técnicamente activa, prácticamente inútil.

Una idea para la confiabilidad parafraseada de un ingeniero notable aplica perfectamente aquí: parafraseada de Werner Vogels: “Lo construyes, lo ejecutas”. Si habilitas respaldos, eres responsable de las restauraciones.

Hechos interesantes y breve historia (del tipo que cambia cómo piensas)

1. File History debutó en Windows 8 como una especie de sucesor a los flujos anteriores de “versiones anteriores”, con el objetivo de protección continua de archivos sin software adicional.
2. Previous Versions en Windows 7 a menudo dependía de Restaurar sistema y Volume Shadow Copy; File History cambió el valor predeterminado hacia un destino de respaldo explícito en lugar de solo snapshots locales.
3. El respaldo de archivos con versiones no es nuevo: los sistemas empresariales lo han hecho durante décadas; File History fue el movimiento de Microsoft para que “la gente normal también lo obtenga”.
4. Las bibliotecas no eran solo adorno de la interfaz: eran un mecanismo de agrupación funcional que File History puede rastrear sin que tengas que gestionar rutas manualmente.
5. Los recursos SMB como destinos fueron un guiño deliberado a usuarios móviles y configuraciones NAS de pequeñas empresas, no solo a discos USB externos.
6. Las políticas de retención son un problema de economía de almacenamiento: conservar cada versión para siempre es cómo descubres que “para siempre” es sorprendentemente caro.
7. El respaldo a nivel de archivo complementa la imagen de sistema: la imagen es para recuperación bare-metal; File History es para “borré/cambié esto” recuperación. Clases de incidentes diferentes, herramientas diferentes.
8. El ransomware cambió el modelo de amenaza: la guía de respaldos antigua asumía que el enemigo era la falla de hardware; ahora el enemigo también puede ser tus propias credenciales usadas a velocidad de máquina.

Configúralo con intención

Elige un destino con intención

Unidad externa: simple, rápida y generalmente fiable. Mala para portátiles si los usuarios la olvidan en casa. También fácil de robar junto con el portátil, lo que convierte el “respaldo” en “segunda copia de la pérdida”.

Disco interno secundario: conveniente, pero comparte la misma caja y a menudo el mismo dominio de fallo. Si la máquina se vuelve inservible, puedes perder ambos. Solo lo recomiendo si se combina con una segunda copia fuera de la máquina.

Recurso compartido en red (NAS): mejor equilibrio para muchas organizaciones, especialmente si los portátiles deambulan. Diseñalo correctamente: credenciales separadas, limitar permisos y considera hacer el recurso inaccesible cuando no se necesite (solo VPN, reglas de firewall o acceso condicional).

Define qué significa “protegido”

Si no decides explícitamente qué carpetas importan, Windows decidirá por ti, y Windows no rinde cuentas ante tu CFO.

• Asegura que las carpetas de trabajo principales estén dentro de bibliotecas (Documentos, Escritorio, etc.) o incluidas mediante políticas.
• Identifica carpetas “silenciosamente críticas”: repositorios de código fuente, exportaciones locales, carpetas de OneDrive que no se sincronizan, directorios de datos específicos de aplicaciones.
• Decide cómo tratar archivos multimedia grandes y caches. Respaldar caches es un impuesto que pagarás para siempre.

Establece retención basada en la realidad

La retención no es una emoción. Es una función de ventana de restauración (qué tan atrás podrías necesitar), tasa de cambio (con qué frecuencia cambian los archivos) y capacidad.

Reglas empíricas que resisten en producción:

• Si tus usuarios frecuentemente lamentan cambios en días, guarda 30–90 días de versiones.
• Si tu organización enfrenta “ediciones de fin de trimestre”, conserva más alrededor de los ciclos de reporte.
• No mantengas para siempre a menos que hayas hecho los cálculos y probado el comportamiento de poda.

No confundas sincronización en la nube con respaldo

OneDrive/Dropbox/Google Drive son geniales para sincronizar. Tampoco son lo mismo que tener un respaldo versionado con una retención y un límite de acceso independientes.

La sincronización replica errores rápidamente. El respaldo preserva el historial. Cuando puedas, quieres ambos.

Broma #2: Si tu “respaldo” es solo sincronización, felicitaciones: has creado un sistema de distribución de errores.

Tareas prácticas: comandos, salidas y la decisión que tomas (12+)

Estos son los tipos de comprobaciones que ejecutas cuando eres la persona que recibe la llamada cuando alguien no puede restaurar un archivo. Los comandos se muestran en un formato tipo shell Linux como se solicitó; trátalos como comandos operativos representativos que puedes ejecutar desde un host de salto que tenga herramientas de gestión de Windows disponibles (por ejemplo vía PowerShell remoting envuelto por scripts). Las salidas ilustran lo que debes buscar y la decisión que tomas a continuación.

Tarea 1: Confirma que la ruta del destino de respaldo se resuelve (caso de recurso compartido en red)

cr0x@server:~$ smbclient -L //nas01 -U CORP\\backupsvc
Password for [CORP\backupsvc]:
	Sharename       Type      Comment
	---------       ----      -------
	FileHistory$    Disk      File History targets
	IPC$            IPC       IPC Service (nas01)
SMB1 disabled -- no workgroup available

Qué significa: Puedes enumerar recursos compartidos, así que DNS, enrutamiento y autenticación funcionan. SMB1 está deshabilitado (bien).

Decisión: Si el recurso que esperas no aparece, detente y arregla el aprovisionamiento/permisos. Si la enumeración falla, diagnostica resolución de nombres, firewall o credenciales antes de tocar la configuración de File History.

Tarea 2: Comprueba que el usuario (o identidad de servicio) puede escribir en el recurso

cr0x@server:~$ smbclient //nas01/FileHistory$ -U CORP\\backupsvc -c 'mkdir _probe; rmdir _probe'
Password for [CORP\backupsvc]:

Qué significa: La ausencia de errores indica que crear/eliminar funcionó.

Decisión: Si obtienes “NT_STATUS_ACCESS_DENIED”, arregla las ACL. File History necesita acceso de escritura; recursos de solo lectura crean la ilusión de seguridad mientras producen cero respaldos utilizables.

Tarea 3: Revisa la capacidad y salud del sistema de archivos en el destino

cr0x@server:~$ df -h /mnt/filehistory
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.3T  6.9T  310G  96% /mnt/filehistory

Qué significa: 96% usado es un problema. Muchos sistemas se descomponen cerca del lleno: operaciones de metadatos lentas, escrituras fallidas, poda que no da abasto.

Decisión: Aumenta capacidad o ajusta retención/exclusiones antes de “depurar” File History. Un destino casi lleno es la causa raíz sorprendentemente frecuente.

Tarea 4: Identifica los mayores consumidores para ver si la retención está explotando

cr0x@server:~$ du -h --max-depth=2 /mnt/filehistory | sort -h | tail -n 10
120G	/mnt/filehistory/PC-044/UserA
180G	/mnt/filehistory/PC-112/UserB
240G	/mnt/filehistory/PC-039/UserC
410G	/mnt/filehistory/PC-021/UserD
1.1T	/mnt/filehistory/PC-008/UserE
1.3T	/mnt/filehistory/PC-008

Qué significa: Un endpoint/usuario está consumiendo una cantidad desproporcionada.

Decisión: Investiga ese endpoint por churn masivo de versiones (archivos PST, imágenes de VM, salidas de compilación). Excluye o reubica datos ruidosos. File History adora preservar fielmente tus peores hábitos de almacenamiento.

Tarea 5: Verifica que la estructura de directorios de File History exista y se esté actualizando

cr0x@server:~$ ls -lah /mnt/filehistory/PC-008
total 64K
drwxr-xr-x  6 root root 4.0K Jan 28 10:11 .
drwxr-xr-x 98 root root 4.0K Jan 28 10:11 ..
drwxr-xr-x  5 root root 4.0K Jan 28 09:02 Configuration
drwxr-xr-x 12 root root 4.0K Jan 28 10:10 Data
drwxr-xr-x  2 root root 4.0K Jan 28 10:10 Catalog
-rw-r--r--  1 root root  12K Jan 28 10:10 Config1.xml

Qué significa: Estructura típica de File History. Las marcas de tiempo recientes sugieren actividad.

Decisión: Si Catalog/Data no cambian por días, el cliente no está ejecutando respaldos o no puede alcanzar el destino.

Tarea 6: Confirma que un archivo específico tiene múltiples versiones en el destino

cr0x@server:~$ find /mnt/filehistory/PC-008/Data -name "QuarterlyReport.xlsx*" | head
/mnt/filehistory/PC-008/Data/C/Users/UserE/Documents/QuarterlyReport.xlsx
/mnt/filehistory/PC-008/Data/C/Users/UserE/Documents/QuarterlyReport.xlsx (2025_12_18 09_00_12 UTC)
/mnt/filehistory/PC-008/Data/C/Users/UserE/Documents/QuarterlyReport.xlsx (2025_12_18 10_00_14 UTC)

Qué significa: Tienes versiones, no solo el archivo más reciente.

Decisión: Si solo existe el archivo base sin variantes con marca de tiempo, el versionado puede estar deshabilitado, la retención demasiado corta o los respaldos demasiado poco frecuentes para capturar cambios.

Tarea 7: Verifica la frescura del respaldo (comprobación RPO)

cr0x@server:~$ find /mnt/filehistory/PC-008/Catalog -type f -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort | tail -n 3
2026-02-03 17:00 /mnt/filehistory/PC-008/Catalog/Catalog1.edb
2026-02-03 17:00 /mnt/filehistory/PC-008/Catalog/Config1.xml
2026-02-03 17:00 /mnt/filehistory/PC-008/Catalog/Config2.xml

Qué significa: La última ejecución exitosa parece ser el 3 de feb a las 17:00.

Decisión: Compáralo con tu RPO requerido (por ejemplo, «dentro de 24 horas»). Si está obsoleto, trátalo como una falla incluso si la interfaz dice “activado”.

Tarea 8: Revisa desconexiones del destino en los logs del NAS (lado servidor)

cr0x@server:~$ grep -i "PC-008" /var/log/samba/log.smbd | tail -n 5
[2026/02/03 16:58:21.112233,  1] smbd/service.c:1234(make_connection_snum)
  PC-008 (10.20.4.88) connect to service FileHistory$ initially as user CORP\backupsvc
[2026/02/03 16:59:02.998877,  1] smbd/server_exit.c:999(exit_server_common)
  Server exit (NT_STATUS_END_OF_FILE)

Qué significa: Una conexión normal y luego desconexión. No necesariamente un problema.

Decisión: Si ves repetidos “ACCESS_DENIED”, “DISK_FULL” o “SHARING_VIOLATION”, arregla eso primero; el cliente de Windows suele decir la verdad de forma indirecta.

Tarea 9: Mide la latencia/jitter de red hacia el recurso (porque portátiles)

cr0x@server:~$ ping -c 5 nas01
PING nas01 (10.20.1.10) 56(84) bytes of data.
64 bytes from 10.20.1.10: icmp_seq=1 ttl=63 time=1.12 ms
64 bytes from 10.20.1.10: icmp_seq=2 ttl=63 time=1.31 ms
64 bytes from 10.20.1.10: icmp_seq=3 ttl=63 time=18.44 ms
64 bytes from 10.20.1.10: icmp_seq=4 ttl=63 time=2.01 ms
64 bytes from 10.20.1.10: icmp_seq=5 ttl=63 time=1.27 ms

Qué significa: Un pico a 18 ms. No es terrible, pero los picos se acumulan con operaciones SMB chatas.

Decisión: Si la latencia es consistentemente alta o hay pérdida de paquetes, espera un comportamiento de “respalda a veces”. Arregla la red/VPN o mueve a un destino local con sincronización periódica.

Tarea 10: Valida que el recurso soporte dialectos SMB modernos (seguridad y rendimiento)

cr0x@server:~$ smbclient //nas01/FileHistory$ -U CORP\\backupsvc -c 'protocol'
Password for [CORP\backupsvc]:
SMB3_11

Qué significa: SMB 3.11 está en uso. Bueno para características de seguridad y mejoras de rendimiento.

Decisión: Si estás atascado en dialectos antiguos, puedes encontrarte con bloqueos de políticas de seguridad o problemas de rendimiento. Actualiza la pila NAS/SMB en lugar de “ajustar” la capa equivocada.

Tarea 11: Comprueba si los respaldos se están podando (funcionamiento de retención)

cr0x@server:~$ find /mnt/filehistory/PC-008/Data -name "*UTC" | awk '{print $0}' | head -n 3
/mnt/filehistory/PC-008/Data/C/Users/UserE/Documents/QuarterlyReport.xlsx (2025_11_10 09_00_12 UTC)
/mnt/filehistory/PC-008/Data/C/Users/UserE/Documents/QuarterlyReport.xlsx (2025_11_11 09_00_12 UTC)
/mnt/filehistory/PC-008/Data/C/Users/UserE/Documents/QuarterlyReport.xlsx (2025_11_12 09_00_12 UTC)

Qué significa: Puedes ver versiones antiguas que datan de meses.

Decisión: Si esperas retención de 90 días pero las versiones solo llegan a una semana, algo está podando agresivamente (política) o los respaldos fallan intermitentemente y solo tienes puntos dispersos.

Tarea 12: Confirma que existe un “candidato de restauración” antes de prometérselo a un usuario

cr0x@server:~$ ls -1 "/mnt/filehistory/PC-008/Data/C/Users/UserE/Desktop/Notes.txt"* | tail -n 5
/mnt/filehistory/PC-008/Data/C/Users/UserE/Desktop/Notes.txt (2026_02_01 12_00_05 UTC)
/mnt/filehistory/PC-008/Data/C/Users/UserE/Desktop/Notes.txt (2026_02_02 12_00_06 UTC)
/mnt/filehistory/PC-008/Data/C/Users/UserE/Desktop/Notes.txt (2026_02_03 12_00_06 UTC)
/mnt/filehistory/PC-008/Data/C/Users/UserE/Desktop/Notes.txt (2026_02_03 17_00_08 UTC)
/mnt/filehistory/PC-008/Data/C/Users/UserE/Desktop/Notes.txt

Qué significa: Existen múltiples versiones recientes, incluidos puntos del mismo día.

Decisión: Puedes decir con confianza al usuario “podemos restaurar de ayer o de las 17:00”. Si no existen versiones, pivota inmediatamente a otros caminos de recuperación (historial en la nube, archivos adjuntos de correo, shadow copies, herramientas forenses).

Tarea 13: Detecta churn fuera de control: archivos grandes que cambian constantemente

cr0x@server:~$ find /mnt/filehistory/PC-112/Data -type f -size +2G -printf "%s %p\n" | sort -n | tail -n 5
3435973836 /mnt/filehistory/PC-112/Data/C/Users/UserB/Documents/Outlook.pst (2026_02_02 09_00_01 UTC)
3435973836 /mnt/filehistory/PC-112/Data/C/Users/UserB/Documents/Outlook.pst (2026_02_02 10_00_02 UTC)
3435973836 /mnt/filehistory/PC-112/Data/C/Users/UserB/Documents/Outlook.pst (2026_02_02 11_00_03 UTC)
3435973836 /mnt/filehistory/PC-112/Data/C/Users/UserB/Documents/Outlook.pst (2026_02_02 12_00_03 UTC)
3435973836 /mnt/filehistory/PC-112/Data/C/Users/UserB/Documents/Outlook.pst

Qué significa: Archivo PST de varios GB capturado cada hora. Eso no es “respaldo”, es “calentador de almacenamiento”.

Decisión: Excluye PSTs de File History y respáldalos por otro método (retención en servidor de correo, manejo dedicado de PST o migración de usuarios fuera de PSTs). O acepta el costo con los ojos abiertos.

Tarea 14: Verifica que el destino no sea silenciosamente de solo lectura (regresión de sistema de archivos/permisos)

cr0x@server:~$ touch /mnt/filehistory/.write_test && echo "ok"
ok

Qué significa: El punto de montaje es escribible en el servidor. (Si diagnosticas desde el lado del cliente, validarías escritura SMB desde la identidad cliente.)

Decisión: Si esto falla con “Read-only file system” o “No space left”, detente. File History no puede compensar la física.

Guía rápida de diagnóstico: encuentra el cuello de botella sin conjeturas

Cuando File History “no funciona”, la gente salta a alternar configuraciones. Así es como pierdes medio día y terminas con el mismo problema más confusión nueva. Usa este orden.

Primero: ¿Hay datos recientes en el destino?

• Revisa marcas de tiempo en Catalog/Data para la máquina/usuario afectado.
• Si están obsoletos, asume que los respaldos no se ejecutan o no pueden alcanzar el destino.
• Si están actuales, el problema probablemente sea el flujo de restauración, inclusión de archivos o expectativa del usuario.

Segundo: ¿El destino está sano y escribible?

• Capacidad (evita >90% usado).
• Salud del sistema de archivos (errores de volumen NAS, remonte en solo lectura, agotamiento de cuotas).
• Permisos (negación de escritura tras un cambio de ACL es común).

Tercero: ¿La ruta es estable desde el punto de vista del cliente?

• Recurso compartido accesible en el mismo estado de red que usa el usuario (problemas de split-tunnel de VPN, portales cautivos Wi‑Fi, fallos al reanudar de suspensión).
• Compatibilidad DNS y dialecto SMB.
• Autenticación (rotación de credenciales, contraseñas vencidas, prompts de MFA que rompen el acceso en segundo plano).

Cuarto: ¿Estás respaldando el conjunto de datos correcto?

• Inclusión de carpetas: ¿el archivo está dentro de bibliotecas / rutas incluidas?
• Exclusiones: ¿alguien excluyó una carpeta para “ahorrar espacio”?
• Churn de archivos grandes: PST/VM/artefactos de compilación que ahogan todo lo demás.

Quinto: ¿Puedes restaurar un archivo conocido ahora mismo?

• Elige un archivo pequeño que sepas que cambia a diario (un archivo de notas).
• Confirma que existen múltiples versiones y se pueden restaurar.
• Si la restauración falla, podrías tener corrupción de catálogo o problemas de permisos/rutas en la restauración.

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

1) “File History está activado, pero no hay nada”

Síntomas: La interfaz dice habilitado; el destino contiene pocos o ningún dato; la hora del último respaldo es antigua.

Causa raíz: Destino desconectado (USB desenchufado, recurso de red inalcanzable) o permisos revocados tras un cambio de política.

Solución: Haz que el destino esté siempre disponible según el patrón de trabajo del usuario (NAS accesible por VPN, Wi‑Fi estable). Valida permisos de escritura con una prueba de crear/eliminar. Agrega monitoreo de obsolescencia.

2) “Los respaldos funcionaban hasta que endurecimos la seguridad”

Síntomas: Falla repentinamente tras rotación de contraseñas/despliegue de MFA/endurecimiento SMB.

Causa raíz: La identidad usada para acceder al recurso ya no puede autenticarse silenciosamente, o hay incompatibilidad de dialecto/cifrado SMB.

Solución: Usa un modelo de autenticación soportado que funcione para acceso en segundo plano (credenciales de dispositivo, patrones de identidad de servicio gestionada, o credenciales por usuario con políticas apropiadas). Asegura SMB 3.x y ajustes de seguridad modernos en el NAS.

3) “El disco de respaldo está lleno y File History dejó de ayudar”

Síntomas: El destino alcanza alta utilización; los respaldos se vuelven esporádicos; errores sobre espacio.

Causa raíz: Retención configurada a “para siempre”, más archivos grandes con alto churn (PST, bases de datos, imágenes VM).

Solución: Define una ventana real de retención; excluye archivos grandes con churn; aumenta capacidad; aplica cuotas por equipo/usuario si el NAS lo soporta.

4) “Restauramos, pero es la versión equivocada”

Síntomas: El usuario restaura y aún ve contenido corrupto/no deseado.

Causa raíz: Intervalo de respaldo demasiado largo; los cambios ocurrieron entre ejecuciones; el usuario espera granularidad por guardado.

Solución: Reduce el intervalo para endpoints de alto valor, o complementa con versionado a nivel de aplicación (SharePoint/OneDrive) para documentos colaborativos.

5) “Se está respaldando, pero el rendimiento es horrible”

Síntomas: Ventiladores del portátil encendidos; picos en la red; NAS saturado en horas laborales.

Causa raíz: Muchos endpoints ejecutan en la misma programación; la ventana de respaldo coincide; sobrecarga de metadatos SMB en almacenamiento lento; antivirus escaneando el destino agresivamente.

Solución: Escalonar horarios vía política; mejorar el rendimiento de disco y metadatos del NAS; excluir el destino de backup de escaneos innecesarios (con cuidado y revisión de seguridad).

6) “No respalda esa carpeta que nos importa”

Síntomas: Alguna ruta crítica nunca aparece en el respaldo.

Causa raíz: File History respalda bibliotecas y ubicaciones seleccionadas; la carpeta vive en otro lugar (directorio de datos de aplicación personalizado, ruta fuera de biblioteca).

Solución: Mueve los datos a una ubicación protegida (recomendado), añádela a una biblioteca o fuerza la inclusión con política. Luego verifica que existan versiones.

7) “El ransomware cifró también los respaldos”

Síntomas: El destino de respaldo tiene archivos cifrados; las versiones no son utilizables.

Causa raíz: El destino estaba en línea y escribible con las mismas credenciales que usó el malware.

Solución: Añade una capa offline/immutable: unidad desconectada periódica, snapshots de NAS con eliminación restringida, o credenciales separadas y segmentación de red. File History es una capa, no una fortaleza.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: El incidente causado por una suposición equivocada

La empresa estaba en plena migración a una nueva plataforma de gestión documental. Se dijo a los equipos: “Pon todo en la carpeta sincronizada y estás seguro”. La mayoría lo hizo. Un pequeño subgrupo de finanzas no lo hizo, porque sus macros se rompían cuando cambiaban las rutas, así que siguieron trabajando desde el Escritorio y una carpeta local llamada Exports.

IT había habilitado File History “hace tiempo”, pero nadie validó el alcance. En su mente, “respaldo” significaba “todo el perfil de usuario”. En realidad, File History apuntaba a una unidad USB en cada PC de escritorio. Los portátiles —donde realmente trabajaba finanzas— lo tenían habilitado pero sin un destino accesible la mayor parte de los días. La interfaz seguía pareciendo tranquilizadora.

Luego se ejecutó un script de limpieza. Estaba destinado a borrar archivos exportados antiguos de más de 30 días. Usó timestamps locales. Un bug de zona horaria más una ruta equivocada borraron el conjunto de trabajo activo. Finanzas lo llamó “un evento de desaparición masiva”.

Intento de restauración uno: sincronización en la nube. Nada, porque no estaba sincronizado. Intento de restauración dos: File History. Los respaldos estaban obsoletos por semanas; el recurso destino no era accesible por VPN, y nadie lo notó. Lo único recuperable vino de archivos adjuntos de correo y un par de archivos que alguien había copiado a una carpeta personal meses antes.

La causa raíz no fue el script. Los scripts fallan. La causa raíz fue la suposición de que “activado” significaba “operacional”. Después hicieron tres cosas: movieron las exportaciones a una carpeta respaldada por biblioteca, hicieron que el destino de File History fuera accesible por VPN y añadieron una comprobación simple de obsolescencia que alertaba cuando las máquinas no habían respaldado en 48 horas.

Mini-historia 2: La optimización que salió mal

Un equipo de IT tenía una queja razonable: el NAS se saturaba a las 9am. Cientos de endpoints iniciaban File History a la hora en punto. La latencia del array de almacenamiento se disparó, y los usuarios culparon “la red”.

Optimizaban. O eso creían. Configuraron la frecuencia de File History a cada 10 minutos para “mejor protección”, asumiendo que deltas más pequeños significarían menos carga por ejecución. La carga no se redujo; se dispersó. En lugar de un pico por hora, crearon una tormenta de fondo permanente: churn constante de metadatos SMB, escrituras pequeñas constantes y una cola que nunca se vaciaba.

Peor, intentaron “ayudar” excluyendo carpetas temporales de forma amplia, y por accidente excluyeron una carpeta donde un equipo de ingeniería guardaba claves locales de firma de builds. Esas claves no debían estar allí, pero estaban. Cuando un portátil murió, la restauración no incluyó las claves; la recuperación llevó días e implicó recrear cadenas de confianza, no solo restaurar archivos.

La solución no fue un ajuste místico. Volvieron la frecuencia a horaria, escalonaron los horarios por OU, mejoraron la capa de metadatos del NAS y crearon exclusiones dirigidas basadas en churn medido (PSTs, VM images) en lugar de “todo lo que suene temporal”. También aprovecharon el incidente para forzar que el material de claves estuviera en un almacén gestionado. La mejor estrategia de respaldo es no tener que respaldar secretos desde portátiles en absoluto.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo legal recibió una hoja de cálculo de asesores externos. Fue editada, reeditada y pasada entre personas. Alguien eventualmente sobrescribió una versión que contenía un conjunto crítico de notas. No fue solo un “ups”. Era un riesgo: plazos, presentaciones en tribunal, daño reputacional, todo el paquete.

Llamaron a IT con la solicitud habitual: “¿Pueden recuperar la versión anterior?” En muchas organizaciones, ahí es donde empiezas a improvisar. Esta vez fue aburrido. Maravillosamente aburrido.

El endpoint tenía File History respaldando a un destino en red. La retención estaba en 90 días. Las pruebas de restauración formaban parte de las operaciones trimestrales, así que el helpdesk conocía el flujo y no tuvo que adivinar. Sacaron la línea de tiempo de historial de archivos, seleccionaron la versión de la mañana anterior y la restauraron a una carpeta separada para evitar sobrescribir el archivo actual.

Toda la operación tomó minutos. La nota post-incidente fue corta: “Restaurado desde la versión de File History en la marca de tiempo X; el usuario confirmó.” Sin drama, sin búsqueda por correo, sin rituales nocturnos de “quizás lo recuperamos de una shadow copy”.

Ese es el punto. Los mejores respaldos son los que hacen que los incidentes sean aburridos.

Listas de verificación / plan paso a paso (opera File History como producción)

Paso a paso: un despliegue sensato para una pequeña organización

1. Elige un destino: recurso NAS (preferido para portátiles) o unidad externa (aceptable para escritorios), pero no “una partición secundaria al azar” a menos que también tengas copias fuera de la máquina.
2. Crea un recurso dedicado: separado de los recursos compartidos generales. Aplica cuotas por dispositivo/usuario si tu NAS lo soporta.
3. Establece permisos con control del radio de impacto: los usuarios solo pueden escribir en su área de respaldo; evita dar amplios derechos de eliminación.
4. Define carpetas incluidas: asegúrate de que las carpetas de trabajo estén en bibliotecas o sean incluidas por política.
5. Define exclusiones: archivos grandes con alto churn (PST, imágenes VM, salidas de build) deben manejarse de forma distinta.
6. Establece frecuencia: horaria es un buen valor por defecto. Incrementa solo para cargas de alto valor y bajo churn.
7. Establece retención: 30–90 días es un punto común. “Para siempre” es una decisión presupuestaria, no una casilla para marcar.
8. Valida restauración: restaura un archivo desde tres puntos en el tiempo: ayer, la semana pasada, el mes pasado.
9. Monitorea obsolescencia: alerta cuando una máquina no ha producido un respaldo en N horas/días.
10. Documenta el flujo de restauración: capturas y notas de “dónde viven las versiones”. La restauración es el producto.

Lista operativa: semanal

• Revisa capacidad del destino y tasa de crecimiento; predice cuándo alcanzarás 85% usado.
• Identifica los mayores consumidores; detecta nuevas fuentes de churn.
• Revisa fallos recientes en logs (NAS y reportes del cliente si están disponibles).
• Realiza una prueba de restauración en un endpoint aleatorio.

Lista operativa: trimestral

• Reevalúa la retención según las solicitudes reales de restauración.
• Valida que los equipos críticos tengan sus carpetas reales de trabajo incluidas.
• Ejecuta un ejercicio de mesa: ransomware afecta a un portátil—qué se restaura, qué no.
• Revisa el modelo de permisos en el recurso; quita excepciones que se hayan colado.

Preguntas frecuentes

1) ¿Es File History un “respaldo real”?

Es un respaldo real para archivos de usuario: versionado, incremental, restaurable. No es una imagen completa del sistema. Combínalo con un enfoque de imágenes/DR para recuperación del SO.

2) ¿Puedo usar File History con un NAS?

Sí. Funciona bien con un recurso SMB. Asegúrate de que el recurso sea accesible en las condiciones reales de red del usuario (VPN, Wi‑Fi doméstico), y trata los permisos como un límite de seguridad.

3) ¿Por qué mi destino de respaldo se llena tan rápido?

Por lo general la retención es demasiado larga y estás respaldando archivos grandes con alto churn (PSTs, imágenes VM, grandes archivos reescritos). Soluciona excluyendo/reubicando churn y estableciendo una ventana de retención que puedas permitirte.

4) ¿File History respalda todo bajo C:\Users?

No. Por defecto rastrea bibliotecas y un conjunto de ubicaciones visibles al usuario. Si tu carpeta importante está fuera de esas, puede no estar incluida. Muévela, inclúyela en una biblioteca o fuerza inclusión por política.

5) ¿El ransomware puede cifrar los respaldos de File History?

Puedes; depende de cómo está conectado el destino y qué credenciales están en juego. Reduce el riesgo con credenciales separadas, permisos limitados, snapshots/immutabilidad en NAS cuando sea posible y una copia offline para casos extremos.

6) ¿Cuál es la frecuencia adecuada de respaldo?

Horaria es un valor por defecto sensato. Respaldos más frecuentes aumentan la sobrecarga y pueden salir mal en almacenamiento compartido. Si necesitas casi tiempo real, considera versionado a nivel de aplicación o una herramienta de respaldo distinta diseñada para eso.

7) ¿Cuánto tiempo debería conservar versiones?

Empieza con 30–90 días para la mayoría de entornos de trabajadores del conocimiento. Ajusta según patrones reales de restauración y presupuesto de almacenamiento. “Para siempre” rara vez es el valor por defecto correcto.

8) ¿Cómo sé que realmente está funcionando?

No confíes en “activado”. Verifica la frescura en el destino, confirma que existen múltiples versiones de un archivo editado con frecuencia y realiza una prueba de restauración. Luego añade monitoreo de obsolescencia para no depender de sensaciones.

9) ¿File History es redundante si usamos OneDrive?

No necesariamente. OneDrive ofrece sincronización e historial de versiones dentro del servicio. File History aporta una copia adicional con su propia retención y límite de destino. Para roles de alto valor, tener capas es racional.

Siguientes pasos que puedes hacer hoy

• Elige una máquina y verifica: destino accesible, respaldos frescos, versiones presentes, restauración funciona.
• Encuentra tus mayores culpables de churn en el destino (PST/VM/artefactos de build) y decide excluir o manejar por separado.
• Establece una política de retención que encaje con tu presupuesto de almacenamiento y solicitudes reales de restauración.
• Añade chequeos de obsolescencia: si un dispositivo no ha respaldado en 48 horas, no está “protegido”, está “esperando”.
• Ejecuta un ejercicio de restauración con un archivo real de usuario. Documenta los pasos. Haz que el incidente sea aburrido antes de que llegue el incidente.

File History no es llamativo. Está bien. El mejor respaldo es el que corre en silencio, conserva versiones y restaura rápido—especialmente cuando tu único otro plan es “copia mis archivos”, que no es un plan.