Sauvegarde Windows vers NAS : la configuration qui ne plante pas au hasard

Ce que nous construisons réellement (et ce que nous ne construisons pas)

Nous construisons des sauvegardes Windows fiables vers un NAS via SMB avec :

• Deux types de sauvegarde : au niveau fichier (Robocopy) et, en option, au niveau image (Windows Server Backup vers SMB lorsque c’est adapté).
• Identité contrôlée : un compte de sauvegarde dédié, des identifiants stables, pas de surprises « qui a lancé la tâche cette fois ? ».
• IO prévisible : réglages SMB qui ne se sabotent pas eux‑mêmes, et choix de stockage NAS qui tiennent face aux rafales de petits fichiers.
• Preuve : logs, codes de sortie, rétention, vérification et exercices de restauration.
• Vitesse de diagnostic : vous saurez rapidement si le goulot est DNS, auth, négociation SMB, disque, CPU, MTU ou chevauchement de planification.

Nous ne prétendons pas que cela remplace une stratégie 3-2-1. Un partage NAS n’est pas une copie hors site, n’est pas immuable par défaut et n’est pas à l’épreuve des ransomwares sans mesures supplémentaires.

Faits et contexte : pourquoi Windows → NAS est particulier

Quelques éléments de contexte comptent parce que les modes de défaillance sont hérités de l’histoire, pas de votre compétence.

1. SMB est ancien. La lignée du protocole remonte aux années 1980 ; des couches de compatibilité hantent encore les déploiements modernes via des valeurs par défaut « utiles ».
2. SMB1 est pratiquement fossile. Il a été largement exploité (vers, déplacement latéral) ; les versions modernes de Windows le désactivent par défaut dans de nombreuses éditions pour de bonnes raisons.
3. « Partage réseau » et « cible de sauvegarde » sont des bêtes différentes. Les partages sont conçus pour l’accès interactif ; les sauvegardes martèlent les métadonnées et créent de longs flux séquentiels, souvent dans le même job.
4. La sémantique des fichiers Windows est stricte. Flux de données alternatifs, chemins longs, ACLs et gestion des fichiers ouverts sont normaux ; de nombreux appliances NAS imitent cela de façon imparfaite.
5. VSS existe parce que les applications Windows n’arrêtent pas gentiment d’écrire. Les copies ombres permettent des snapshots cohérents pendant que les applications continuent d’écrire.
6. Le signing SMB est devenu un standard de sécurité. Beaucoup d’environnements l’exigent ; il peut impacter le débit sur des CPU NAS faibles ou sous forte concurrence.
7. La dérive horaire casse l’auth de façon non triviale. Kerberos et les durées de vie des tokens ne tiennent pas compte du « ce n’est que cinq minutes ». Les jobs de sauvegarde échouent comme s’ils étaient hantés.
8. Les vendeurs NAS optimisent pour des charges mixtes. Votre charge de sauvegarde (millions de petits fichiers, puis gros flux) est le pire des deux mondes.
9. « Succès » veut souvent dire « succès-ish ». Les outils peuvent retourner 0 avec des fichiers sautés, des jonctions exclues ou des problèmes de chemins à moins que vous ne traitiez les logs comme des preuves.

Une citation à garder, parce qu’elle résume le travail : L’espoir n’est pas une stratégie. (idée paraphrasée, courante en exploitation)

Principes de conception qui évitent les pannes aléatoires

1) Rendre l’identité ennuyeuse : un compte de sauvegarde par périmètre

Créez un compte dédié (local ou domaine) utilisé uniquement pour les sauvegardes. Donnez‑lui un accès lecture aux sources (ou les droits admin si nécessaire, mais ne commencez pas par ça), et en écriture seule si possible sur la cible NAS. Évitez d’utiliser votre propre jeton admin pour des tâches planifiées. Votre politique de rotation de mot de passe rencontrera un jour le Planificateur de tâches, et un seul des deux survivra.

2) Faire du partage NAS une cible dédiée

Un partage « Public » général mène au chaos de rétention et à l’auto‑sabotage en cas de ransomware. Créez un partage uniquement pour les sauvegardes avec :

• dataset/volume séparé (pour snapshots et quotas)
• partage SMB séparé (pour tuner les paramètres sans casser les partages utilisateurs)
• permissions séparées (pour que « suppression accidentelle » nécessite un effort)

3) Privilégier le « push » si vous pouvez le sécuriser

Les sauvegardes poussées depuis Windows vers le NAS sont courantes et correctes. Les sauvegardes en « pull » (le NAS se connecte à Windows et copie) peuvent réduire la prolifération d’identifiants sur les endpoints, mais sont souvent pires pour les permissions Windows et la cohérence VSS. Si vous devez choisir, le push est généralement plus simple à faire correctement—puis durcissez le NAS pour que les données poussées ne puissent pas être modifiées ensuite.

4) Éliminer les chemins d’échec silencieux

Les sauvegardes échouent bruyamment quand le réseau est down. Elles échouent silencieusement quand :

• vous atteignez les limites de longueur de chemin
• votre utilisateur de sauvegarde ne peut pas lire une partie des dossiers
• votre job tourne plus longtemps que le prochain déclenchement (chevauchement)
• votre NAS manque d’inodes / espace métadonnées / réserve de snapshot
• les sessions SMB sont coupées par des timeouts d’inactivité en plein transfert

Concevez pour la détection : vérification explicite des codes de sortie, envoi des logs, et tests de restauration périodiques.

5) Ne laissez pas « optimisation » devancer l’observabilité

Compression, déduplication, copie multi‑threads, MTU gigantesque, lectures jumbo—cela peut être excellent. Cela peut aussi rendre les pannes intermittentes et difficiles à reproduire. Optimisez seulement après avoir mesuré le débit de base et le taux d’erreur.

Blague #1 : Les sauvegardes sont comme les parachutes : la fois où vous en aurez besoin est un mauvais moment pour découvrir que vous avez acheté « nécessite un assemblage ».

Configuration côté NAS qui survit à la réalité

Choisir un agencement de stockage adapté à l’IO des sauvegardes

Les sauvegardes sont typiquement orientées écriture et en rafales. Les sauvegardes au niveau fichier peuvent être lourdes en métadonnées (petits fichiers), tandis que les sauvegardes image sont de gros écritures séquentielles. Votre NAS devrait avoir :

• Assez de RAM pour éviter le thrashing des caches de métadonnées.
• Des disques capables de soutenir les écritures sans s’effondrer (les disques SMR sont une « surprise ! » connue pour les écritures soutenues).
• Une redondance adaptée à l’impact métier (mirrors/RAIDZ/RAID6 etc.).

Si votre NAS est basé sur ZFS, soyez prudent avec la déduplication. Ce n’est pas gratuit ; c’est une facture récurrente en RAM et CPU.

Paramètres du partage SMB : sécurité d’abord, puis performance

Les valeurs par défaut varient selon les vendeurs. Ce que vous voulez généralement :

• SMB2/SMB3 seulement (désactivez SMB1).
• Chiffrement : activez si vous traversez des réseaux non fiables ; sinon évaluez l’impact CPU.
• Signing : suivez votre baseline sécurité ; mesurez le débit.
• Opportunistic locking / leasing : généralement ok ; les charges de sauvegarde sont majoritairement séquentielles, mais les tempêtes de métadonnées peuvent se comporter étrangement.
• Handles durables : utiles quand les clients se reconnectent après de brèves coupures.

Permissions : « la sauvegarde peut écrire, mais pas réécrire l’histoire »

Idéalement, votre hôte Windows peut créer de nouveaux jeux de sauvegarde mais ne peut pas supprimer ou modifier les anciens. Obtenir une vraie immutabilité sur SMB est délicat, mais vous pouvez l’approcher :

• Utilisez sous‑dossiers séparés par hôte et par type de sauvegarde.
• Faites que le compte de sauvegarde ait création/écriture dans son propre dossier ; restreignez la suppression si faisable.
• Utilisez des snapshots NAS (horaire/quotidien) avec rétention. Les snapshots sont votre « annulation ».
• Si la plateforme le permet, utilisez les WORM/snapshots immuables ou le verrouillage de snapshots.

DNS, NTP et certificats : les parties ennuyeuses qui mordent

Si le NAS et Windows ne sont pas d’accord sur l’heure, ou si DNS renvoie une IP erronée à cause d’enregistrements obsolètes, l’auth SMB échoue de façon à la fois subtile et bruyante. Placez le NAS sur la même source NTP que vos contrôleurs de domaine (ou au moins dans une dérive raisonnable) et traitez les enregistrements DNS comme de la config de production.

Configuration côté Windows : identifiants, scripts et planification

Utilisez Robocopy pour les sauvegardes au niveau fichier, mais traitez‑le comme un outil puissant

Robocopy est fiable et brutalement honnête—si vous interprétez correctement ses codes de sortie. Les décisions clés :

• /MIR réplique les suppressions (dangereux si mal pointé, utile si vous concevez pour ça).
• /Z le mode redémarrable aide sur les liaisons instables ; /ZB peut basculer en mode backup si les permissions le permettent.
• /R et /W décident si vous voulez attendre indéfiniment sur des fichiers verrouillés (vous ne le voulez pas).
• /COPY:DAT vs /COPY:DATSOU dépend si vous devez préserver ACLs et auditing.

Pour la plupart des configurations sauvegarde→NAS, vous copierez les données et les horodatages, et vous journaliserez de façon agressive. Si vous avez besoin de fidélité ACL, vous devez tester les restaurations et vérifier que le NAS les préserve correctement.

Windows Server Backup vers SMB : utile, mais connaître ses spécificités

Windows Server Backup (WSB) peut cibler un dossier partagé distant, mais il a des contraintes : il gère sa propre structure de dossiers, peut ne pas conserver plusieurs versions comme vous l’attendez sur un partage, et peut se comporter différemment que la sauvegarde vers un disque dédié. Utilisez‑le quand vous avez spécifiquement besoin de l’état système, de la récupération bare‑metal ou d’une intégration VSS applicative sur Windows Server.

Planificateur de tâches : exécuter sous une identité service, pas « quand je suis connecté »

Les sauvegardes planifiées doivent s’exécuter que quelqu’un soit connecté ou non. Utilisez un compte dédié (domaine ou local), choisissez « Exécuter que l’utilisateur soit connecté ou non » et stockez les identifiants. Ensuite durcissez ce compte. Ce n’est pas le moment d’être créatif.

Blague #2 : Rien ne vous fait vieillir plus vite qu’une sauvegarde « terminée avec succès » qui ne peut pas être restaurée.

Tâches pratiques (commandes, sorties, décisions)

Voici des tâches concrètes que vous pouvez exécuter depuis une machine admin Linux, un shell NAS ou un jump host. Chacune inclut ce que la sortie signifie et la décision que vous en tirez. Utilisez‑les comme procédure opérationnelle standard lors du diagnostic de « pannes aléatoires ».

Task 1: Verify DNS is stable for the NAS name

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

Signification de la sortie : Vous avez un enregistrement A. Si vous voyez plusieurs IP changeantes, vous tombez peut‑être sur du round‑robin, des enregistrements obsolètes ou une confusion de NAS multi‑homé.

Décision : Si l’IP est instable ou incorrecte, corrigez le DNS d’abord. Ne touchez pas SMB sur une cible mouvante.

Task 2: Check basic reachability and latency (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

Signification de la sortie : Faible latence et pas de perte. Si vous voyez de la perte ou des pics, SMB va « se bloquer » et se reconnecter de façon aléatoire.

Décision : Si perte de paquets, arrêtez de blâmer Windows Backup. Corrigez les commutateurs, le Wi‑Fi, le câblage ou les liaisons surchargées.

Task 3: Confirm TCP 445 is reachable (SMB)

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

Signification de la sortie : Le port est ouvert. Si c’est un timeout ou refusé, vous avez des problèmes de pare‑feu ou de routage.

Décision : Si bloqué, corrigez la politique réseau avant de toucher aux identifiants ou permissions de partage.

Task 4: List SMB shares to confirm negotiation works

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

Signification de la sortie : L’authentification a réussi et le partage existe. La ligne « SMB1 disabled » est normale ; c’est un bon signe.

Décision : Si la liste échoue avec NT_STATUS_LOGON_FAILURE, vous êtes en territoire d’identifiants/identité, pas de stockage.

Task 5: Validate you can write and read a test file on the 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)

Signification de la sortie : Création/écriture/lecture/suppression réussies. Si la suppression échoue mais l’écriture réussit, vos permissions « en mode ajout seulement » peuvent fonctionner (ou être mal configurées).

Décision : Décidez si les sauvegardes doivent pouvoir supprimer. Si vous utilisez /MIR avec Robocopy, la permission de suppression est critique.

Task 6: Measure raw throughput with a large file (quick reality check)

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

Signification de la sortie : Si un fichier de 4 GiB prend ~39s, vous êtes autour de ~100–120 MB/s effectifs, typique pour 1GbE après overhead. Si c’est 10 MB/s, quelque chose cloche.

Décision : Si le débit est faible, cherchez du côté réseau (duplex, MTU), CPU NAS (signing/chiffrement) ou vitesse d’écriture disque.

Task 7: Check the NAS disk health quickly (SMART summary)

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

Signification de la sortie : « PASSED » est nécessaire, pas suffisante. Si ça échoue, arrêtez : vous sauvegardez vers une cible moribonde.

Décision : Remplacez les disques défaillants, puis re‑vérifiez l’état de resilver/rebuild de l’array avant de faire confiance aux sauvegardes.

Task 8: Inspect NAS capacity and inode pressure

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

Signification de la sortie : Beaucoup d’espace et d’inodes. Si l’utilisation des inodes est proche de 100%, les sauvegardes de petits fichiers échoueront même avec des To libres.

Décision : Si pression d’inodes élevée, ajustez la rétention, consolidez les petits fichiers (archivez) ou utilisez une approche de sauvegarde différente pour ce jeu de données.

Task 9: Detect SMB session drops by watching logs (NAS syslog)

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

Signification de la sortie : Vous avez des échecs d’authentification en cours de session. Ce n’est pas « aléatoire ». C’est rotation d’identifiants, cache d’identifiants ou tâches multiples utilisant des mots de passe différents.

Décision : Corrigez la gestion des comptes : coordonnez la rotation avec les tâches planifiées ou utilisez un gMSA (si vous êtes domaine et que le client le supporte).

Task 10: Confirm the Windows host can resolve and reach the NAS (from a Linux jump host, check ARP and routing)

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

Signification de la sortie : La route est claire. Si le trafic fait du hairpinning via un pare‑feu de façon inattendue, vous le verrez ici.

Décision : Si le routage est étrange, corrigez‑le—SMB déteste le routage asymétrique et les surprises de pare‑feu stateful.

Task 11: Measure path MTU issues (blackhole detection)

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

Signification de la sortie : MTU standard OK sans fragmentation. Si cela échoue sur un réseau où les jumbo frames sont « activés », vous pouvez avoir un MTU incohérent provoquant des blocages.

Décision : Standardisez le MTU bout en bout ou désactivez les jumbo frames. Le jumbo partiellement configuré est un classique générateur de « débit aléatoire ».

Task 12: Verify the NAS is not CPU-bound during SMB transfers

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

Signification de la sortie : Le CPU est majoritairement inactif. Si vous voyez beaucoup d’utilisation CPU système pendant les transferts (surtout avec chiffrement/signing SMB), le CPU NAS devient le goulot.

Décision : Si CPU saturé, envisagez de désactiver le chiffrement SMB sur VLANs de confiance, d’upgrader le CPU NAS ou de passer au 10GbE seulement si le CPU peut suivre.

Task 13: Confirm ZFS pool/dataset health (if applicable)

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

Signification de la sortie : Le pool est sain ; les scrubs tournent ; pas d’erreurs. Si vous voyez des erreurs de checksum, votre cible de sauvegarde peut corrompre les données.

Décision : Si erreurs présentes, cessez de considérer le NAS comme sûr. Corrigez le matériel, câblage, firmware HBA, RAM, puis re‑vérifiez les sauvegardes.

Task 14: List snapshots and confirm retention exists (if applicable)

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

Signification de la sortie : Les snapshots se font régulièrement. Si vous n’avez pas de snapshots, vous n’avez pas de tampon « oups » contre ransomware ou /MIR accidentel.

Décision : Si les snapshots manquent, mettez‑les en place avant de déclarer le système de sauvegarde « terminé ».

Task 15: Check SMB server config for weak protocol fallback (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

Signification de la sortie : Vous n’autorisez pas SMB1. Le signing est obligatoire. Le chiffrement est désactivé (correct sur LAN de confiance ; pas correct sur réseaux hostiles).

Décision : Si le min protocol est SMB1, changez‑le. Si vous avez besoin de chiffrement, activez‑le et re‑mesurez CPU et débit.

Task 16: Confirm the share path isn’t on a slow filesystem tier

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

Signification de la sortie : Vous êtes sur le dataset prévu. Si vous trouvez des sauvegardes atterrissant sur un petit volume OS ou un device cache par erreur, vous avez trouvé le coupable du « pleine‑soudainement » aléatoire.

Décision : Assurez‑vous que les chemins de partage mappent vers le dataset/volume avec les bons quotas et la bonne politique de snapshots.

Mode opératoire de diagnostic rapide

Version « quelqu’un attend au téléphone ». L’objectif est d’identifier le goulot en quelques minutes, pas en heures.

Premier : est‑ce la résolution de noms, le routage ou l’accès au port ?

• Vérifiez la résolution DNS du nom NAS (Task 1).
• Pinger et rechercher perte/pics de latence (Task 2).
• Confirmez que le TCP 445 est atteint (Task 3).

Si l’un de ces éléments échoue : c’est l’infrastructure réseau. Ne perdez pas de temps à faire tourner les mots de passe ou tuner Robocopy.

Second : est‑ce l’authentification ou l’autorisation ?

• Lister les partages et authentifier (Task 4).
• Écrire/lire un fichier test (Task 5).
• Vérifier les logs Samba du NAS pour des échecs de connexion (Task 9).

Si vous pouvez lister les partages mais pas écrire : permissions. Si vous pouvez écrire parfois mais pas après des changements de mot de passe : hygiène des identifiants.

Troisième : est‑ce la performance (CPU NAS, disque ou réseau MTU) ?

• Test rapide de débit avec un gros fichier (Task 6).
• Vérification sanity MTU (Task 11).
• Charge CPU NAS pendant transfert (Task 12).
• Etat disque et pool (Tasks 7 et 13).
• Capacité / inodes (Task 8).

Règle générale : Si le débit gros‑fichier est correct mais les sauvegardes sont lentes, le problème vient des métadonnées/petits fichiers, d’un antivirus ou trop de jobs concurrents. Si le débit gros‑fichier est mauvais, c’est le transport ou le chemin d’écriture du NAS.

Quatrième : est‑ce la planification et le chevauchement ?

C’est la défaillance furtive. Les jobs tournent longtemps, le suivant démarre, les sessions entrent en collision, les verrous augmentent et vous avez des sauvegardes partielles. Auditez les planifications et assurez‑vous qu’un seul job par hôte est actif à la fois sauf si vous avez prouvé que la concurrence fonctionne.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “It fails with access denied, but only on some folders”

Cause racine : Le compte de sauvegarde n’a pas les droits sur des chemins protégés, ou le filtrage de token/UAC change le comportement entre exécution interactive et planifiée.

Correction : Utilisez un compte de service dédié ; accordez‑lui explicitement les droits de lecture sur les arbres requis ; testez en utilisant la même identité que celle du job planifié. Évitez « ça marche quand je le lance en admin ». Ce n’est pas un test ; c’est une confession.

2) Symptom: “Robocopy says success, but files are missing”

Cause racine : Vous avez ignoré les codes de sortie et les lignes de résumé de Robocopy ; fichiers sautés à cause de longueur de chemin, jonctions, fichiers verrouillés ou exclusions.

Correction : Parsez les codes de sortie ; faites échouer le job si des fichiers sont sautés/échoués ; activez le logging ; décidez comment gérer les jonctions (/XJ) et les chemins longs (activez les chemins longs dans la stratégie Windows si applicable).

3) Symptom: “Backup to NAS is randomly slow, sometimes fine”

Cause racine : MTU mismaché, liens Wi‑Fi, paramètres d’économie d’énergie du NIC, saturation CPU par signing/chiffrement SMB, ou jobs concurrents causant contention disque sur le NAS.

Correction : Standardisez le MTU ; utilisez des liaisons filaires pour les serveurs ; mesurez le CPU NAS ; étalez les horaires ; limitez les threads Robocopy ; envisagez NIC/VLAN séparés pour les sauvegardes.

4) Symptom: “It worked for months, then started failing after password rotation”

Cause racine : La tâche planifiée a stocké des anciens identifiants ; le NAS a des sessions mises en cache ; plusieurs tâches utilisent des secrets différents.

Correction : Adoptez gMSA si possible ; sinon coordonnez la rotation des identifiants et mettez à jour toutes les tâches planifiées en un seul changement. Vérifiez via les logs d’échec d’auth du NAS.

5) Symptom: “NAS has space, but backups fail with ‘no space left’”

Cause racine : Réserve de snapshot, quotas, ou épuisement d’inodes. Ou le partage pointe vers un volume plus petit que prévu.

Correction : Vérifiez df -h et df -i (Task 8), les quotas et le chemin backing du partage (Task 16). Ajustez la rétention ; augmentez le dataset ; arrêtez de prétendre que 90% plein est « largement suffisant ».

6) Symptom: “WSB to network share keeps only one version / overwrites weirdly”

Cause racine : Le comportement de WSB pour les partages distants diffère des disques dédiés ; il gère les versions différemment et peut ne pas conserver l’historique attendu.

Correction : Utilisez WSB vers un disque dédié ou une cible iSCSI si vous avez besoin d’un versioning correct, ou superposez des snapshots NAS pour que les versions existent au niveau stockage.

7) Symptom: “Backups stop mid-transfer, then resume, then corrupt”

Cause racine : Réseau instable, coupures de session SMB, ou NIC/driver instable. Parfois un firewall « utile » réinitialise les sessions.

Correction : Vérifiez la perte et les logs (Tasks 2 et 9). Désactivez les offloads NIC problématiques sur Windows (testez), et retirez les middleboxes stateful du chemin de sauvegarde quand c’est possible.

8) Symptom: “Ransomware encrypted the backups on the NAS too”

Cause racine : Les identifiants de sauvegarde avaient des droits de suppression/modification ; les sauvegardes n’étaient qu’un partage modifiable ; pas de politique de snapshot immuable.

Correction : Superposez : identifiants en moindre privilège, snapshots avec rétention (et immutabilité/verrouillage si disponible), segmentation réseau et au moins une copie hors ligne/hors site. Un partage SMB inscriptible seul n’est pas une protection.

Checklists / plan étape par étape

Phase 1: Build a NAS target that behaves

1. Créez un dataset/volume dédié pour les sauvegardes (séparé des partages utilisateurs).
2. Activez des snapshots réguliers (horaire + quotidien est courant ; adaptez aux besoins métier).
3. Créez un partage SMB dédié (ex. backups) pointant uniquement vers ce dataset.
4. Désactivez SMB1 ; exigez SMB2+.
5. Décidez du signing/chiffrement selon votre baseline sécurité ; mesurez la marge CPU.
6. Créez une identité de sauvegarde dédiée (CORP\backup_svc ou utilisateur NAS local).
7. Réglez les permissions pour que le compte puisse écrire sa cible mais ne puisse pas effacer l’historique sans effort.
8. Configurez quotas/alertes pour que « NAS plein » devienne un ticket avant de devenir une panne.

Phase 2: Build a Windows job that doesn’t lie

1. Choisissez la méthode de sauvegarde par charge :
   • Robocopy pour le niveau fichier (bon choix par défaut).
   • WSB pour l’état système / bare‑metal (cas serveurs).
2. Écrivez un script qui journalise vers un chemin local stable et vers le NAS (si joignable).
3. Faites échouer le job sur codes de sortie non‑zéro / indésirables, pas sur des impressions subjectives.
4. Planifiez avec le Planificateur de tâches sous une identité dédiée.
5. Échelonnez les horaires entre hôtes pour éviter les avalanches NAS à minuit.
6. Effectuez un exercice de restauration sur un hôte non‑production. Chronométrez‑le. Documentez‑le.

Phase 3: Operationalize it (the part people skip)

1. Centralisez les logs (même si c’est juste un autre partage ou un collecteur de logs).
2. Alertez sur les échecs, mais aussi sur « job non exécuté » et « job 2x plus long ».
3. Mensuellement : vérifiez que les snapshots existent et que la rétention est conforme.
4. Trimestriellement : exercice de restauration pour au moins un hôte représentatif.
5. Après toute mise à jour firmware NAS : relancez les tests de débit et d’auth.

Trois mini‑récits d’entreprise tirés du terrain

Incident causé par une mauvaise hypothèse : « C’est un partage de fichiers, donc c’est OK »

Une entreprise moyenne est passée des disques USB à un NAS flambant neuf. Le plan : créer un seul partage, donner « Domain Admins » en plein droit, et pointer tous les serveurs Windows avec Robocopy. Ils ont appelé ça des sauvegardes centralisées. Centralisé, oui.

L’hypothèse erronée était subtile : ils supposaient que la sémantique SMB est uniforme et que « plein droit » empêche les problèmes de permissions. En réalité, plusieurs serveurs avaient des chemins longs et des jonctions vers des caches applicatifs. Robocopy a sauté des chemins, loggé des avertissements, renvoyé un code non nul, et le script wrapper a tout de même envoyé un e‑mail « SUCCESS » parce qu’il vérifiait seulement l’existence d’un fichier log.

La panne est apparue lors d’une demande de restauration : la « sauvegarde » d’un serveur n’incluait pas le répertoire critique. Pas parce que le NAS était down, mais parce que la copie était incomplète en silence depuis des mois.

La correction n’était pas exotique. Ils ont écrit une vraie barrière sur le code de sortie, rendu la gestion des jonctions explicite (/XJ là où il faut, inclure ailleurs), activé les chemins longs quand pertinent, et ajouté un test de restauration hebdomadaire. Le NAS n’a pas changé. La véracité de leur processus, oui.

Optimisation qui a échoué : « Activons toutes les fonctions de vitesse »

Une autre organisation avait des plaintes de performance : les sauvegardes débordaient sur les heures ouvrées. Quelqu’un a activé les jumbo frames sur les NIC du NAS et activé le chiffrement SMB « pour conformité », en se disant que le hardware moderne pourrait gérer.

Ça a marché pour un test rapide : un gros fichier copié vite depuis un hôte. Puis les sauvegardes nocturnes ont commencé. Sous concurrence, le CPU du NAS a explosé à cause du chiffrement et du signing, et un switch intermédiaire avait les jumbo mal configurés. Certains clients stagnaient, se reconnectaient, puis continuaient—sauf que le comportement de reconnexion n’était pas cohérent entre versions Windows et drivers NIC.

Le résultat avait l’air aléatoire : certains hôtes réussissaient, d’autres échouaient, d’autres prenaient 8 heures au lieu de 2. Le volume de tickets a monté. On a commencé à débattre des phases de la lune propices aux sauvegardes.

La solution finale était ennuyeuse : revenir à MTU 1500 partout (jusqu’à garantir le jumbo bout en bout), garder le signing selon la politique, désactiver sélectivement le chiffrement sur le VLAN de sauvegarde de confiance, et limiter la concurrence. Les sauvegardes ont de nouveau fini avant l’aube. La performance est venue de la cohérence, pas des réglages héroïques.

Pratique ennuyeuse mais correcte qui a sauvé la mise : snapshots + moindre privilège

Un troisième environnement avait fait deux choses « pas sexy » dès le départ : le partage de sauvegarde vivait sur son propre dataset avec snapshots horaires, et le compte de sauvegarde pouvait écrire mais n’avait pas de larges droits de suppression. Ce n’était pas une immutabilité parfaite, mais c’était nettement plus difficile de détruire l’historique.

Ils ont tout de même été frappés par un ransomware sur une station de travail qui avait accès à certains partages. Le malware a tenté de traverser le réseau et d’encrypter tout ce qui était accessible en écriture. Il a atteint le NAS, trouvé le partage de sauvegarde et a fait des dégâts—limit és.

Ce qui les a sauvés n’était pas un produit endpoint magique. C’était le snapshot de la nuit précédente qui était intact et que le malware ne pouvait pas facilement effacer. Le chemin de restauration était clair : revenir le dataset affecté à un snapshot connu bon, puis restaurer les clients.

Le post‑mortem fut presque ennuyeux, ce qui est le compliment suprême en exploitation. Leur snapshot et leur travail de permissions ont transformé une catastrophe potentielle en un week‑end long de procédures routinières et documentées.

FAQ

1) Should I use Windows built-in “Backup and Restore (Windows 7)” to a NAS?

Vous pouvez, mais c’est legacy et capricieux. Pour des configurations modernes, préférez Robocopy pour le niveau fichier, et Windows Server Backup pour l’imagerie/état système si vous avez spécifiquement besoin de ce workflow.

2) Is SMB signing required, and will it slow backups?

Beaucoup de baselines corporate l’exigent. Oui, cela peut réduire le débit sur des CPU NAS faibles ou avec de nombreux streams parallèles. Mesurez avant/après et surveillez le CPU NAS pendant les transferts.

3) Should I enable SMB encryption?

Si le trafic de sauvegarde traverse des réseaux non fiables ou des infrastructures partagées que vous ne contrôlez pas, le chiffrement est judicieux. Sur un VLAN de sauvegarde dédié et de confiance en DC, il peut être optionnel. Si vous l’activez, re‑testez le débit et la marge CPU.

4) Do I need VSS if I’m just copying files?

Si vous copiez des bases de données, des PST ou tout fichier ouvert et modifié pendant la sauvegarde, vous avez besoin d’une approche aware‑VSS. Robocopy seul peut copier des versions incohérentes de fichiers vivants. Utilisez des outils aware‑VSS ou les méthodes natives applicatives pour ces charges.

5) Should backups use /MIR in Robocopy?

Seulement si vous êtes absolument sûr du chemin cible et que vous avez une protection snapshot sur le NAS. /MIR supprimera les fichiers sur la destination qui ne sont pas sur la source. Une erreur de ciblage et vous saurez ce qu’est l’adrénaline.

6) How do I keep multiple versions if Robocopy mirrors changes?

Utilisez des snapshots NAS pour la versioning, ou implémentez une rotation en dossiers (jeu par date) et purgez selon une politique. Les snapshots sont généralement la couche de versions la plus propre pour un NAS.

7) How do I know backups are restorable?

En restaurant. Au minimum : choisissez un hôte par trimestre, restaurez un dataset représentatif dans un emplacement isolé, et vérifiez le démarrage de l’application ou l’intégrité des fichiers. Les logs ne prouvent pas restaurabilité ; les restaurations, oui.

8) What’s the best way to protect NAS backups from ransomware?

Superposez les protections : identifiants de moindre privilège, snapshots avec rétention (et immutabilité/verrouillage si supporté), segmentation réseau et au moins une copie hors‑ligne/hors‑site. Un partage SMB écrivable seul n’est pas une protection.

9) My backups are slow only on small files. Why?

Les petits fichiers sont gourmands en métadonnées : beaucoup de lookups de répertoire, vérifications ACL et allers‑retours SMB. Améliorez avec des disques/SSDs plus rapides pour les métadonnées, plus de RAM, moins de jobs concurrents et des attentes réalistes. Excluez aussi les caches et outputs de build non pertinents.

10) Can I use a single share for all servers?

Vous pouvez, mais ne devriez pas sauf si vous avez des permissions de sous‑dossiers strictes et des quotas. Un seul partage devient rapidement un tiroir à bazar avec des combats de rétention et des suppressions accidentelles. Séparez par hôte ou par environnement au minimum.

Étapes suivantes pour que ça tienne dans le temps

1. Choisissez la méthode par charge : Robocopy pour le niveau fichier, WSB pour l’état système/bare‑metal.
2. Construisez correctement la cible NAS : dataset dédié, snapshots, SMB2/3 seulement, permissions sensées.
3. Standardisez l’identité : un compte service de sauvegarde testé dans le même contexte que Task Scheduler utilise.
4. Instrumentez et alertez : codes de sortie, parsing des logs, « job non exécuté » et « durée excessive ».
5. Faites un exercice de restauration et notez les étapes pendant que c’est encore frais et un peu embarrassant.

Si vous ne faites qu’une seule chose cette semaine : implémentez des snapshots et vérifiez une restauration. Tout le reste est optimisation ; ces deux éléments sont vitaux.