Copia de seguridad de Windows en NAS: la configuración que no falla aleatoriamente

Lo que realmente estamos construyendo (y lo que no)

Estamos construyendo copias fiables de Windows a un NAS a través de SMB con:

• Dos tipos de copia: a nivel de archivos (Robocopy) y opcionalmente a nivel de imagen (Windows Server Backup a SMB cuando proceda).
• Identidad controlada: una cuenta de backup dedicada, credenciales estables, sin sorpresas de “¿quién ejecutó la tarea la última vez?”.
• IO predecible: ajustes SMB que no se saboteen solos, y elecciones de almacenamiento en el NAS que no se desmoronen con tormentas de archivos pequeños.
• Pruebas: registros, códigos de salida, retención, verificación y simulacros de restauración.
• Velocidad de diagnóstico: sabrás rápido si el cuello de botella es DNS, autenticación, negociación SMB, disco, CPU, MTU o solapamiento de programación.

No pretendemos que esto reemplace un 3-2-1 adecuado. Un recurso compartido NAS no es una copia fuera de sitio, no es inmutable por defecto y no es a prueba de ransomware a menos que lo hagas así.

Hechos y contexto: por qué Windows→NAS es extraño

Un poco de contexto importa porque los modos de fallo están horneados en la historia, no en tu competencia.

1. SMB es antiguo. La línea del protocolo se remonta a los años 80; las capas de compatibilidad todavía persiguen desplegados modernos con “valores por defecto” que “ayudan”.
2. SMB1 es prácticamente un fósil. Fue ampliamente explotado (piensa en gusanos y movimiento lateral); las versiones modernas de Windows lo deshabilitan por defecto en muchas SKU por buenas razones.
3. “Recurso compartido” y “objetivo de backup” son bestias distintas. Los shares están diseñados para acceso interactivo; las copias golpean metadatos y crean flujos secuenciales largos, a menudo en la misma tarea.
4. La semántica de archivos en Windows es estricta. Flujos de datos alternativos, rutas largas, ACLs y manejo de archivos abiertos son normales; muchos appliances NAS imitan esto de forma imperfecta.
5. VSS existe porque las aplicaciones de Windows no cierran cortésmente. Las shadow copies se introdujeron para obtener snapshots consistentes mientras las apps siguen escribiendo.
6. El firmado SMB se volvió una línea base de seguridad. Muchos entornos lo requieren; puede impactar el rendimiento en CPUs NAS débiles o bajo alta concurrencia.
7. La desviación de tiempo rompe la autenticación de formas no obvias. Kerberos y la vida de los tokens no se impresionan por “solo cinco minutos”. Las tareas de backup fallan como si estuvieran encantadas.
8. Los proveedores de NAS optimizan para cargas mixtas. Tu carga de backup (millones de archivos pequeños, luego grandes flujos) es lo peor de ambos mundos.
9. “Éxito” a menudo significa “más o menos éxito”. Las herramientas pueden salir con código 0 con archivos omitidos, junctions excluidas o problemas de ruta a menos que trates los logs como evidencia.

Una cita que deberías tener presente, porque resume el trabajo: La esperanza no es una estrategia. (idea parafraseada, común en círculos de operaciones)

Principios de diseño que previenen fallos aleatorios

1) Haz la identidad aburrida: una cuenta de backup por ámbito

Crea una cuenta dedicada (local o de dominio) usada solo para backups. Dale acceso de lectura a las fuentes (o privilegios administrativos si debes, pero no empieces por ahí), y solo escritura cuando sea posible al objetivo NAS. Evita usar tu token de admin para backups programados. Tu política de rotación de contraseñas acabará encontrándose con el Programador de Tareas, y solo uno de ellos sobrevivirá.

2) Haz que el share del NAS tenga un propósito específico

Un share “Público” general es cómo obtienes caos de retención y auto-daño asistido por ransomware. Crea un share solo para backups con:

• dataset/volumen separado (para poder snapshotear y aplicar cuotas)
• share SMB separado (para poder ajustar configuraciones sin romper shares de usuarios)
• permisos separados (para que un “borrado accidental” requiera esfuerzo)

3) Prefiere “pull” solo si puedes asegurararlo

Respaldar empujando desde Windows al NAS es común y aceptable. Hacer pull desde el NAS (el NAS se conecta a Windows y copia datos) puede reducir la proliferación de credenciales en endpoints, pero suele ser peor para permisos de Windows y consistencia VSS. Si debes elegir, push suele ser más simple de dejar correcto—luego endurece el NAS para que los datos empujados no se puedan modificar después.

4) Elimina caminos de fallo silenciosos

Las copias fallan ruidosamente cuando la red está caída. Fallan silenciosamente cuando:

• alcanzas límites de longitud de ruta
• tu usuario de backup no puede leer un subconjunto de carpetas
• tu trabajo dura más que la siguiente ejecución programada (solapamiento)
• tu NAS se queda sin inodos / espacio de metadatos / reserva de snapshots
• las sesiones SMB se caen por timeouts de inactividad a mitad de transferencia

Diseña para la detección: comprobación explícita de códigos de salida, envío de logs y pruebas periódicas de restauración.

5) No dejes que la “optimización” adelante a la observabilidad

Compresión, dedupe, copia multi-hilo, MTUs enormes, lecturas jumbo—todo esto puede ser genial. También puede hacer que los fallos sean intermitentes y difíciles de reproducir. Optimiza solo después de poder medir el rendimiento base y la tasa de errores.

Broma #1: Las copias de seguridad son como paracaídas: la única vez que las necesitas es un momento terrible para descubrir que compraste “requiere ensamblaje”.

Configuración del NAS que sobrevive a la realidad

Elige un diseño de almacenamiento que coincida con el IO de backup

Las copias suelen ser intensivas en escritura y en ráfagas. Las copias a nivel de archivo pueden ser intensivas en metadatos (archivos pequeños), mientras que las de imagen son escrituras secuenciales grandes. Tu NAS debería tener:

• Suficiente RAM para evitar thrashing de caches de metadatos.
• Discos que puedan sostener escrituras sin caer en un precipicio (los discos SMR son una “sorpresa” conocida para escrituras sostenidas).
• Redundancia acorde al impacto del negocio (mirrors/RAIDZ/RAID6, etc.).

Si tu NAS es ZFS-based, ten cuidado con la deduplicación. No es un almuerzo gratis; es una factura recurrente en RAM y CPU.

Configuración del share SMB: seguridad primero, luego rendimiento

Los valores por defecto varían según el proveedor. Lo que quieres, generalmente:

• Solo SMB2/SMB3 (deshabilitar SMB1).
• Encriptación: habilítala si cruzas redes no confiables; de lo contrario evalúa el impacto en CPU.
• Firmado: sigue tu baseline de seguridad; mide el rendimiento.
• Opportunistic locking / leasing: normalmente está bien; las cargas de backup son mayormente secuenciales, pero las tormentas de metadatos pueden comportarse raro.
• Manejadores duraderos: útiles cuando los clientes se reconectan tras fallos breves.

Permisos: “el backup puede escribir, pero no reescribir la historia”

En un día perfecto, tu host Windows puede crear nuevos conjuntos de backup pero no puede borrar o modificar los antiguos. Lograr verdadera inmutabilidad en SMB es complicado, pero puedes aproximarlo:

• Usa subcarpetas separadas por host y por tipo de backup.
• Haz que la cuenta de backup tenga escritura/creación en su propia carpeta; restringe el borrado cuando sea factible.
• Usa snapshots del NAS (horarios/diarios) con retención. Los snapshots son tu “deshacer”.
• Si tu plataforma lo soporta, usa WORM/snapshots inmutables o bloqueo de snapshots.

DNS, NTP y certificados: las partes aburridas que muerden

Si el NAS y Windows no concuerdan en la hora, o si DNS devuelve la IP equivocada por registros obsoletos, la autenticación SMB falla de forma que parece “extraño aleatorio de red”. Pon el NAS en la misma fuente NTP que tus controladores de dominio (o al menos dentro de una deriva sensata) y trata los registros DNS como configuración de producción.

Configuración en Windows: credenciales, scripts y programación

Usa Robocopy para copias a nivel de archivos, pero trátalo como una herramienta potente

Robocopy es fiable y brutalmente honesto—si lees sus códigos de salida correctamente. Las decisiones clave:

• /MIR refleja borrados (peligroso si apunta mal, útil si lo diseñas así).
• /Z modo reiniciable ayuda sobre enlaces inestables; /ZB puede recurrir a modo backup si los permisos lo permiten.
• /R y /W deciden si quieres esperar indefinidamente por archivos bloqueados (no lo quieres).
• /COPY:DAT vs /COPY:DATSOU depende de si necesitas preservar ACLs y auditoría.

Para la mayoría de setups de backup a NAS, copiarás datos y timestamps, y registrarás agresivamente. Si necesitas fidelidad de ACLs, debes probar restauraciones y verificar que el NAS realmente las preserve correctamente.

Windows Server Backup a SMB: útil, pero conoce su personalidad

Windows Server Backup (WSB) puede apuntar a una carpeta compartida remota, pero tiene limitaciones: gestiona su propia estructura de carpetas, puede no mantener múltiples versiones como esperas en un share, y puede comportarse distinto que respaldar a un disco dedicado. Úsalo cuando necesites específicamente estado del sistema, recuperación bare-metal o integración VSS a nivel de aplicaciones en Windows Server.

Programador de tareas: ejecuta como identidad de servicio, no “cuando estoy conectado”

Las copias programadas deben ejecutarse con independencia de si alguien está conectado. Usa una cuenta dedicada (de dominio o local), configura “Ejecutar tanto si el usuario está conectado como si no” y guarda las credenciales. Luego endurece esa cuenta. Este no es el lugar para creatividad.

Broma #2: Nada te envejece más rápido que una copia “completada con éxito” que no puede restaurarse.

Tareas prácticas (comandos, salidas, decisiones)

Estas son tareas concretas que puedes ejecutar desde una caja de administración Linux, una shell del NAS o un jump host. Cada una incluye lo que la salida significa y qué decisión tomar. Úsalas como procedimiento operativo estándar cuando diagnostiques “fallos aleatorios”.

Tarea 1: Verifica que el DNS sea estable para el nombre del NAS

cr0x@server:~$ dig +short nas01.corp.local
10.20.30.40

Significado de la salida: Obtuviste un registro A. Si ves múltiples IPs que cambian, puede que estés usando round-robin, registros obsoletos o confusión por NAS multihomed.

Decisión: Si la IP es inestable o incorrecta, arregla el DNS primero. No ajustes SMB sobre un objetivo en movimiento.

Tarea 2: Comprueba accesibilidad y latencia básica (ICMP)

cr0x@server:~$ ping -c 5 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=64 time=0.512 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=64 time=0.488 ms
64 bytes from 10.20.30.40: icmp_seq=3 ttl=64 time=0.501 ms
64 bytes from 10.20.30.40: icmp_seq=4 ttl=64 time=0.497 ms
64 bytes from 10.20.30.40: icmp_seq=5 ttl=64 time=0.493 ms

--- 10.20.30.40 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4090ms
rtt min/avg/max/mdev = 0.488/0.498/0.512/0.010 ms

Significado de la salida: Baja latencia y sin pérdida. Si ves pérdida o picos, SMB “aleatoriamente” se detendrá y reconectará.

Decisión: Si hay pérdida de paquetes, deja de culpar al Backup de Windows. Arregla switches, Wi‑Fi, cableado o enlaces sobrecargados.

Tarea 3: Confirma que TCP 445 es accesible (SMB)

cr0x@server:~$ nc -vz 10.20.30.40 445
Connection to 10.20.30.40 445 port [tcp/microsoft-ds] succeeded!

Significado de la salida: El puerto está abierto. Si caduca o es rechazado, tienes problemas de firewall o enrutamiento.

Decisión: Si está bloqueado, arregla la política de red antes de tocar credenciales o permisos de share.

Tarea 4: Lista shares SMB para confirmar que la negociación funciona

cr0x@server:~$ smbclient -L //10.20.30.40 -U 'CORP\backup_svc%REDACTED'
	Sharename       Type      Comment
	---------       ----      -------
	backups         Disk      Windows backups
	IPC$            IPC       IPC Service (nas01)
SMB1 disabled -- no workgroup available

Significado de la salida: La autenticación tuvo éxito y el share existe. La línea “SMB1 disabled” está bien; es una buena señal.

Decisión: Si la lista falla con NT_STATUS_LOGON_FAILURE, estás en territorio de credenciales/identidad, no de almacenamiento.

Tarea 5: Valida que puedes escribir y leer un archivo de prueba en el share

cr0x@server:~$ smbclient //10.20.30.40/backups -U 'CORP\backup_svc%REDACTED' -c 'mkdir _smb_test; cd _smb_test; put /etc/hosts hosts.txt; ls; get hosts.txt /tmp/hosts.txt; del hosts.txt; cd ..; rmdir _smb_test'
  hosts.txt                         A      173  Tue Feb  4 12:10:11 2026
getting file \_smb_test\hosts.txt of size 173 as /tmp/hosts.txt (28.2 KiloBytes/sec) (average 28.2 KiloBytes/sec)

Significado de la salida: Crear/escribir/leer/borrar tuvo éxito. Si borrar falla pero escribir sí, tus permisos “algo solo añadir” pueden estar funcionando (o mal configurados).

Decisión: Decide si las copias deben poder borrar. Si usas /MIR en Robocopy, el permiso de borrado importa mucho.

Tarea 6: Mide el rendimiento bruto con un archivo grande (chequeo rápido de realidad)

cr0x@server:~$ dd if=/dev/zero of=/tmp/backup_test.bin bs=16M count=256 status=progress
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2 s, 2.1 GB/s

cr0x@server:~$ time smbclient //10.20.30.40/backups -U 'CORP\backup_svc%REDACTED' -c 'put /tmp/backup_test.bin _perf/backup_test.bin'
real	0m39.214s
user	0m0.081s
sys	0m0.051s

Significado de la salida: Si un archivo de 4 GiB tarda ~39s, estás en ~100–120 MB/s efectivo, típico para 1GbE una vez aparecen overheads. Si es 10 MB/s, hay algo mal.

Decisión: Si el rendimiento es bajo, buscarás en red (duplex, MTU), CPU del NAS (signing/encryption) o velocidad de escritura en disco.

Tarea 7: Comprueba rápidamente la salud de los discos del NAS (resumen SMART)

cr0x@server:~$ sudo smartctl -H /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.15.0] (local build)
SMART overall-health self-assessment test result: PASSED

Significado de la salida: “PASSED” es necesario, no suficiente. Si falla, detente: estás respaldando a un objetivo moribundo.

Decisión: Reemplaza discos fallando y vuelve a comprobar el estado de resilver/rebuild del array antes de confiar en los backups.

Tarea 8: Inspecciona capacidad del NAS y presión de inodos

cr0x@server:~$ df -h /mnt/backups
Filesystem      Size  Used Avail Use% Mounted on
tank/backups     40T   31T  9.0T  78% /mnt/backups

cr0x@server:~$ df -i /mnt/backups
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
tank/backups     20000000 8400000 11600000   43% /mnt/backups

Significado de la salida: Espacio e inodos abundantes. Si el uso de inodos está cerca del 100%, las copias de archivos pequeños fallarán incluso con TB libres.

Decisión: Si hay presión de inodos, ajusta retención, consolida archivos pequeños (archiva) o usa otro enfoque de backup para ese conjunto de datos.

Tarea 9: Detecta caídas de sesión SMB observando logs (syslog del NAS)

cr0x@server:~$ sudo tail -n 20 /var/log/samba/log.smbd
[2026/02/04 12:03:09.120145,  1] ../../source3/smbd/service.c:787(make_connection_snum)
  make_connection_snum: Connect path is '/mnt/backups' for service [backups]
[2026/02/04 12:05:44.772903,  1] ../../source3/smbd/sesssetup.c:157(auth3_check_password)
  check_ntlm_password:  Authentication for user [CORP]\[backup_svc] -> [backup_svc] FAILED with error NT_STATUS_WRONG_PASSWORD

Significado de la salida: Tienes fallos de autenticación a mitad de la operación. Eso no es “aleatorio”. Es rotación de credenciales, credenciales en caché o múltiples tareas usando contraseñas distintas.

Decisión: Arregla la gestión de cuentas: coordina la rotación con tareas programadas o usa gMSA (si estás en dominio y el cliente lo soporta).

Tarea 10: Confirma que el host Windows puede resolver y alcanzar el NAS (desde un jump host Linux, verifica ARP y enrutamiento)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 via 10.20.30.1 dev eth0 src 10.20.30.50 uid 1000
    cache

Significado de la salida: La ruta está clara. Si el tráfico hairpinea a través de un firewall inesperadamente, lo verás aquí.

Decisión: Si el enrutamiento es extraño, arréglalo—SMB odia el enrutamiento asimétrico y los firewalls stateful que sorprenden.

Tarea 11: Mide problemas de MTU en el path (detección de agujero negro)

cr0x@server:~$ ping -c 3 -M do -s 1472 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.
1480 bytes from 10.20.30.40: icmp_seq=1 ttl=64 time=0.605 ms
1480 bytes from 10.20.30.40: icmp_seq=2 ttl=64 time=0.598 ms
1480 bytes from 10.20.30.40: icmp_seq=3 ttl=64 time=0.602 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2041ms

Significado de la salida: El MTU estándar funciona sin fragmentación. Si esto falla en una red donde los jumbo frames están “habilitados”, puede haber MTU inconsistente causando bloqueos.

Decisión: Estandariza MTU end-to-end o deshabilita jumbo frames. Jumbo a medio configurar es un generador clásico de “rendimiento aleatorio”.

Tarea 12: Verifica que el NAS no esté limitado por CPU durante transferencias SMB

cr0x@server:~$ top -b -n 1 | head -n 12
top - 12:11:26 up 31 days,  4:22,  2 users,  load average: 6.21, 6.02, 5.44
Tasks: 214 total,   1 running, 213 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.4 us,  3.1 sy,  0.0 ni, 82.9 id,  0.2 wa,  0.0 hi,  1.4 si,  0.0 st
MiB Mem :  64384.0 total,   8120.5 free,  10212.0 used,  46051.5 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.  53500.2 avail Mem

Significado de la salida: La CPU está mayormente ociosa. Si ves CPU de sistema alta durante transferencias (especialmente con cifrado/firmado SMB), la CPU del NAS se vuelve el cuello de botella.

Decisión: Si está limitada por CPU, considera deshabilitar cifrado SMB en LANs de confianza, actualizar la CPU del NAS o moverte a 10GbE solo si la CPU puede seguir el ritmo.

Tarea 13: Confirma la salud del pool/dataset ZFS (si aplica)

cr0x@server:~$ zpool status
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features.
  scan: scrub repaired 0B in 09:12:33 with 0 errors on Sun Feb  2 03:10:22 2026
config:

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  raidz2-0  ONLINE       0     0     0
	    sda     ONLINE       0     0     0
	    sdb     ONLINE       0     0     0
	    sdc     ONLINE       0     0     0
	    sdd     ONLINE       0     0     0
	    sde     ONLINE       0     0     0
	    sdf     ONLINE       0     0     0

errors: No known data errors

Significado de la salida: El pool está sano; se corren scrubs; sin errores. Si ves errores de checksum, tu objetivo de backup puede estar corrompiendo datos.

Decisión: Si hay errores, deja de tratar el NAS como seguro. Arregla hardware, cableado, firmware HBA, problemas de RAM, y verifica de nuevo las copias.

Tarea 14: Lista snapshots y confirma que existe retención (si aplica)

cr0x@server:~$ zfs list -t snapshot -o name,used,creation -s creation | tail -n 5
tank/backups@auto-2026-02-04_0800   1.2G  Tue Feb  4 08:00 2026
tank/backups@auto-2026-02-04_0900   1.1G  Tue Feb  4 09:00 2026
tank/backups@auto-2026-02-04_1000   1.3G  Tue Feb  4 10:00 2026
tank/backups@auto-2026-02-04_1100   1.2G  Tue Feb  4 11:00 2026
tank/backups@auto-2026-02-04_1200   1.4G  Tue Feb  4 12:00 2026

Significado de la salida: Los snapshots ocurren regularmente. Si no tienes snapshots, no tienes “colchón” contra ransomware o desastres por /MIR.

Decisión: Si faltan snapshots, impleméntalos antes de declarar el sistema de backup “terminado”.

Tarea 15: Revisa la configuración del servidor SMB para fallback a protocolos débiles (Samba)

cr0x@server:~$ testparm -s | egrep -i 'server min protocol|server max protocol|smb encrypt|server signing'
	server min protocol = SMB2_10
	server max protocol = SMB3_11
	server signing = mandatory
	smb encrypt = disabled

Significado de la salida: No permites SMB1. El firmado es obligatorio. El cifrado está desactivado (aceptable en LANs de confianza; no aceptable en redes hostiles).

Decisión: Si el protocolo mínimo es SMB1, cámbialo. Si necesitas cifrado, habilítalo y vuelve a medir CPU y rendimiento.

Tarea 16: Confirma que la ruta del share no esté en una capa de filesystem lenta

cr0x@server:~$ mount | grep backups
tank/backups on /mnt/backups type zfs (rw,xattr,noacl)

Significado de la salida: Estás en el dataset previsto. Si encuentras backups terminando en un volumen OS pequeño o en un dispositivo cache por accidente, has hallado el culpable de “se acabó el espacio aleatoriamente”.

Decisión: Asegura que las rutas de share apunten al dataset/volumen con cuotas y política de snapshots correctas.

Guía de diagnóstico rápido

Esta es la versión “alguien espera en la llamada”. El objetivo es identificar el cuello de botella en minutos, no en horas.

Primero: ¿es resolución de nombres, enrutamiento o acceso a puertos?

• Comprueba resolución DNS del nombre del NAS (Tarea 1).
• Pingealo y busca pérdida/picos de latencia (Tarea 2).
• Confirma que TCP 445 es accesible (Tarea 3).

Si falla cualquiera de estos: es infraestructura de red. No pierdas tiempo rotando contraseñas o afinando Robocopy.

Segundo: ¿es autenticación o autorización?

• Lista shares y autentica (Tarea 4).
• Escribe/lee un archivo de prueba (Tarea 5).
• Revisa logs Samba del NAS por fallos de logon (Tarea 9).

Si puedes listar shares pero no escribir: permisos. Si puedes escribir a veces, pero no después de cambios de contraseña: higiene de credenciales.

Tercero: ¿es rendimiento (CPU NAS, disco o red MTU)?

• Prueba rápida de throughput con un archivo grande (Tarea 6).
• Chequeo de MTU (Tarea 11).
• Carga CPU del NAS durante la transferencia (Tarea 12).
• Salud de disco y estado del pool (Tareas 7 y 13).
• Capacidad/inodos (Tarea 8).

Regla general: Si el throughput para archivos grandes está bien pero las copias son lentas, el problema es metadatos/archivos pequeños, antivirus o demasiados trabajos concurrentes. Si el throughput de archivos grandes es malo, es el transporte o la ruta de escritura del NAS.

Cuarto: ¿es la programación y el solapamiento?

Este es el fallo sigiloso. Los trabajos se alargan, comienza la siguiente ejecución, las sesiones colisionan, aumentan los locks y obtienes backups parciales. Audita la programación y asegura que solo una tarea por host esté activa a la vez a menos que hayas comprobado que la concurrencia funciona.

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

1) Síntoma: “Falla con acceso denegado, pero solo en algunas carpetas”

Causa raíz: La cuenta de backup no tiene derechos a rutas protegidas, o UAC/filtrado de tokens cambia el comportamiento entre ejecución interactiva y programada.

Solución: Usa una cuenta de servicio dedicada; otórgale explícitamente derechos de lectura a los árboles necesarios; prueba usando la misma identidad que usa la tarea programada. Evita “funciona cuando lo ejecuto como admin”. Eso no es una prueba; es una confesión.

2) Síntoma: “Robocopy dice éxito, pero faltan archivos”

Causa raíz: Ignoraste los códigos de salida y las líneas de resumen de Robocopy; archivos omitidos por longitud de ruta, junctions, archivos bloqueados o exclusiones.

Solución: Analiza códigos de salida; falla la tarea si hay cuentas omitidas/erróneas; habilita logging; decide cómo manejar junctions (/XJ) y rutas largas (habilita rutas largas en la política de Windows cuando aplique).

3) Síntoma: “Backup a NAS es aleatoriamente lento, a veces bien”

Causa raíz: MTU desajustada, enlaces Wi‑Fi, ajustes de ahorro de energía en NIC, saturación de CPU por firmado/cifrado SMB, o trabajos concurrentes que causan contención de disco en el NAS.

Solución: Estandariza MTU; usa enlaces cableados para servidores; mide CPU del NAS; escalona horarios; limita hilos de Robocopy; considera NIC/VLAN separada para backups.

4) Síntoma: “Funcionó meses y empezó a fallar tras rotación de contraseñas”

Causa raíz: La tarea programada guarda credenciales antiguas; el NAS tiene tokens de sesión en caché; múltiples tareas usan secretos diferentes.

Solución: Adopta gMSA cuando sea posible; si no, coordina la rotación de credenciales y actualiza todas las tareas en un solo cambio. Verifica revisando logs de fallo de autenticación en el NAS.

5) Síntoma: “El NAS tiene espacio, pero las copias fallan con ‘no space left’”

Causa raíz: Reserva de snapshots, cuotas o agotamiento de inodos. O el share apunta a un volumen más pequeño del que crees.

Solución: Revisa df -h y df -i (Tarea 8), cuotas y la ruta subyacente del share (Tarea 16). Ajusta retención; amplía el dataset; deja de fingir que 90% lleno es “suficiente”.

6) Síntoma: “WSB a share de red mantiene solo una versión / sobrescribe raro”

Causa raíz: El comportamiento de WSB para shares remotos difiere de discos dedicados; gestiona versiones de forma distinta y puede no mantener el historial que esperas.

Solución: Usa WSB a un disco dedicado o a un target iSCSI si necesitas versionado real, o envuélvelo con snapshots del NAS para que las versiones existan en la capa de almacenamiento.

7) Síntoma: “Las copias se detienen a mitad, luego reanudan, luego corrompen”

Causa raíz: Red inestable, caídas de sesión SMB o NIC/driver defectuoso. A veces un firewall “útil” inspeccionador reinicia sesiones.

Solución: Revisa pérdida y logs (Tareas 2 y 9). Deshabilita offloads problemáticos de la NIC en Windows (prueba) y elimina middleboxes stateful del path de backup cuando sea posible.

8) Síntoma: “Ransomware cifró también las copias en el NAS”

Causa raíz: Las credenciales de backup tenían derechos de borrado/modificación; las copias eran solo otro share escribible; no había política de snapshots inmutables.

Solución: Aplica capas: credenciales de mínimo privilegio, snapshots con retención (y inmutabilidad/bloqueo si está disponible), segmentación de red y al menos una copia offline/offsite. Un share SMB escribible por sí solo no protege.

Listas de verificación / plan paso a paso

Fase 1: Construye un objetivo NAS que se comporte

1. Crea un dataset/volumen dedicado para backups (separado de shares de usuario).
2. Habilita snapshots regulares (horarias + diarias es común; ajusta según necesidades del negocio).
3. Crea un share SMB dedicado (por ejemplo, backups) apuntando solo a ese dataset.
4. Deshabilita SMB1; requiere SMB2+.
5. Decide firmado/encriptación según tu baseline de seguridad; mide margen de CPU.
6. Crea una identidad de backup dedicada (CORP\backup_svc o usuario NAS local).
7. Configura permisos para que la cuenta pueda escribir en su destino pero no borrar historial a la ligera.
8. Configura cuotas/alertas para que “NAS lleno” sea un ticket antes de convertirse en fallo.

Fase 2: Construye un trabajo Windows que no mienta

1. Elige método de backup por carga:
   • Robocopy para nivel de archivo (buen predeterminado).
   • WSB para estado del sistema/bare metal (casos de servidor).
2. Escribe un script que registre en una ruta local estable y en el NAS (si está alcanzable).
3. Haz que la tarea falle con códigos de salida no cero/no deseados, no por intuición.
4. Progámala con el Programador de Tareas bajo una identidad dedicada.
5. Escalona horarios entre hosts para evitar estampidas al NAS a medianoche.
6. Realiza un simulacro de restauración en un host no productivo. Mide tiempo. Documenta.

Fase 3: Operacionalízalo (la parte que la gente omite)

1. Envía logs a un sitio central (aunque sea otro share o un colector de logs).
2. Alerta por fallo, pero también por “tarea no se ejecutó” y “tarea duró 2x más”.
3. Mensualmente: verifica que existan snapshots y que la retención sea la esperada.
4. Trimestralmente: simulacro de restauración para al menos un host representativo.
5. Tras cualquier actualización de firmware del NAS: vuelve a correr pruebas de throughput y autenticación.

Tres microhistorias corporativas desde el terreno

Incidente causado por una suposición equivocada: “Es un file share, así que está bien”

Una empresa mediana pasó de discos USB de backup a un NAS brillante. El plan era simple: crear un share, dar a “Domain Admins” derechos completos y apuntar Robocopy de todos los servidores Windows a él. Lo llamaron backups centralizados. Centralizado sí que estaba.

La suposición errónea fue sutil: asumieron que las semánticas SMB son uniformes entre dispositivos y que “derechos completos” evita problemas de permisos. En realidad, varios servidores tenían rutas largas y junctions hacia caches de aplicaciones. Robocopy omitió algunas rutas, registró advertencias, devolvió un código distinto de “0” y el script envolvente aún envió un correo de “ÉXITO” porque solo comprobaba si existía un archivo de log.

El fallo apareció durante una solicitud de restauración: el “backup” de un servidor no incluía el único directorio que importaba. No porque el NAS estuviera caído, sino porque la copia había estado incompleta silenciosamente durante meses.

La solución no fue exótica. Escribieron una comprobación real de códigos de salida, convirtieron el manejo de junctions en una política explícita (/XJ en algunos lugares, incluir donde haga falta), habilitaron rutas largas donde aplicaba y añadieron una prueba semanal de restauración muestreada. El NAS no cambió. Cambió la veracidad de su proceso.

Optimización que salió mal: “Activemos todas las funciones de velocidad”

Otra organización tenía quejas de rendimiento: las copias entraban en horas laborales. Alguien activó jumbo frames en las NIC del NAS y habilitó cifrado SMB “por cumplimiento”, pensando que el hardware moderno lo soportaría.

Funcionó en una prueba rápida: un archivo grande copiado rápido desde un host. Entonces comenzaron los backups nocturnos. Bajo concurrencia, la CPU del NAS se disparó por cifrado y firmado, y un switch intermedio tenía jumbo frames mal configurados. Algunos clientes se estancarían, reconectarían y continuarían—excepto que el comportamiento de reconexión no fue consistente entre versiones de Windows y drivers de NIC.

El resultado parecía aleatorio: algunos hosts tenían éxito, otros fallaban, algunos tardaban 8 horas en vez de 2. El volumen de tickets subió. La gente empezó a debatir qué fase lunar era mejor para backups.

La solución fue aburrida: volver MTU a 1500 en todas partes (hasta garantizar jumbo end-to-end), mantener firmado según política, deshabilitar cifrado selectivamente en la VLAN de backups de confianza y limitar la concurrencia. Las copias volvieron a terminar antes del amanecer. El rendimiento vino de la consistencia, no de palancas heroicas.

Práctica aburrida pero correcta que salvó el día: snapshots + mínimo privilegio

Un tercer entorno había hecho dos cosas “no sexys” desde el inicio: el share de backup vivía en su propio dataset con snapshots horarios, y la cuenta de backup podía escribir nuevos datos pero no tenía permisos amplios de borrado. No era inmutabilidad perfecta, pero era mucho más difícil arruinar la historia.

Aun así fueron atacados por ransomware en una workstation que tenía acceso a algunos drives compartidos. El malware intentó recorrer la red y cifrar todo lo escribible. Alcanzó el NAS, encontró el share de backup e hizo daño—daño limitado.

Lo que los salvó no fue un producto mágico en endpoints. Fue que el snapshot de la noche anterior estaba intacto y el malware no pudo borrar fácilmente el historial de snapshots. La ruta de restauración fue clara: revertir el dataset afectado al snapshot conocido bueno y luego restaurar clientes.

El postmortem fue casi aburrido, que es el mayor elogio en operaciones. Su trabajo “extra” de snapshots y permisos convirtió una restauración potencialmente catastrófica en un fin de semana largo de pasos rutinarios y documentados.

Preguntas frecuentes

1) ¿Debo usar “Copia de seguridad y restauración (Windows 7)” integrada a un NAS?

Puedes, pero es legado y peculiar. Para setups modernos, prefiere Robocopy para nivel de archivo, y Windows Server Backup para imágenes de servidor/estado del sistema si necesitas ese flujo de trabajo.

2) ¿Es necesario el firmado SMB y ralentizará las copias?

Muchos baselines corporativos lo requieren. Sí, puede reducir el throughput en CPUs NAS débiles o con muchos streams paralelos. Mide antes y después, y vigila la CPU del NAS durante transferencias.

3) ¿Debería habilitar cifrado SMB?

Si el tráfico de backup cruza redes no confiables o infraestructuras compartidas que no controlas, el cifrado tiene sentido. En una VLAN de backups dedicada y confiable dentro de un CPD puede ser opcional. Si lo habilitas, vuelve a probar throughput y margen de CPU.

4) ¿Necesito VSS si solo copio archivos?

Si copias bases de datos, PSTs o cualquier cosa que permanezca abierta y cambie durante el backup, necesitas un enfoque con conciencia de la aplicación. Robocopy solo puede copiar versiones inconsistentes de archivos activos. Usa herramientas VSS-aware o métodos nativos de la aplicación para esas cargas.

5) ¿Las copias deben usar /MIR en Robocopy?

Sólo cuando estés absolutamente seguro del path destino y tengas protección por snapshots en el NAS. /MIR borrará archivos en el destino que no estén en el origen. Si apuntas mal una vez, aprenderás a qué sabe la adrenalina.

6) ¿Cómo mantengo múltiples versiones si Robocopy refleja cambios?

Usa snapshots del NAS para versionado, o implementa rotación en estructuras de carpetas (con conjuntos por fecha) y poda según una política. Los snapshots suelen ser la capa de versiones más limpia para un NAS.

7) ¿Cómo sé que las copias son restaurables?

Restaurando. Como mínimo: elige un host por trimestre, restaura un conjunto representativo a un entorno aislado y verifica que la aplicación arranca o la integridad de archivos. Los logs no son evidencia de restaurabilidad; las restauraciones sí.

8) ¿Cuál es la mejor forma de proteger copias NAS contra ransomware?

Aplica capas: credenciales de mínimo privilegio, snapshots con retención (e inmutabilidad/bloqueo si está disponible), segmentación de red y al menos una copia offline/offsite. Un share SMB escribible solo no protege.

9) Mis backups son lentos solo con archivos pequeños. ¿Por qué?

Los archivos pequeños demandan muchos metadatos: muchas búsquedas de directorio, comprobaciones ACL y viajes de ida y vuelta SMB. Mejora con discos/SSDs más rápidos para metadatos, más RAM, menos trabajos concurrentes y expectativas realistas. También excluye caches irrelevantes y artefactos de compilación de las copias.

10) ¿Puedo usar un único share para todos los servidores?

Puedes, pero no deberías a menos que tengas permisos por subcarpeta y cuotas estrictas. Un share tiende a convertirse en un cajón de sastre con peleas por retención y sobrescrituras accidentales. Separa por host o por entorno al menos.

Próximos pasos para consolidarlo

1. Elige tu método de backup por carga: Robocopy para nivel de archivo, WSB para estado del sistema/bare metal.
2. Construye el objetivo NAS correctamente: dataset dedicado, snapshots, SMB2/3 solo, permisos sensatos.
3. Estandariza identidad: una cuenta servicio de backup, probada en el mismo contexto que usa el Programador de Tareas.
4. Instrumenta y alerta: códigos de salida, parseo de logs, “no se ejecutó” y “duró demasiado”.
5. Haz un simulacro de restauración y documenta los pasos mientras aún están frescos y un poco vergonzosos.

Si haces solo una cosa esta semana: implementa snapshots y verifica una restauración. Todo lo demás es optimización; esas dos son supervivencia.