A cosa serve questa unit

Windows Server offre tre leve distinte per proteggere e ottimizzare lo storage on-premises e ibrido: Storage Replica per la continuità dei dati fra volumi o siti, la Data Deduplication per ridurre l’occupazione su disco e File Server Resource Manager (FSRM) per governare quanto e cosa gli utenti possono scrivere. In AZ-800 queste aree compaiono in scenari che chiedono di scegliere la tecnologia giusta a fronte di vincoli di latenza, RPO, spazio o compliance. Ricorda che l’esame si ritira il 30 settembre 2026 e che il passing score resta 700/1000.

Storage Replica: sincrona vs asincrona

Storage Replica esegue replica a livello di blocco, indipendente dal file system, in tre topologie: server-to-server, cluster-to-cluster e stretch cluster. Ogni server richiede un volume dati e un log volume dedicato (idealmente su SSD/flash), volumi GPT e appartenenza allo stesso dominio Active Directory; il traffico usa SMB (445) e WS-Management.

La differenza chiave è il momento dell’acknowledgment. Nella replica sincrona la scrittura è confermata all’applicazione solo dopo essere stata persistita anche sul sito di destinazione: RPO = 0 (nessuna perdita di dati), ma serve bassa latenza — indicativamente una latenza media di andata/ritorno intorno ai 5 ms — quindi distanze contenute. Nella replica asincrona la scrittura è confermata subito in locale e propagata dopo: tollera latenza e distanze maggiori (DR geografico) al prezzo di un RPO diverso da zero. Prima di creare la partnership si valida la topologia con Test-SRTopology, che verifica latenza, banda e idoneità dei volumi.

Data Deduplication

La Data Deduplication è un role service del ruolo File Server. Lavora in modalità post-process (non inline): job pianificati (Optimization, Garbage Collection, Integrity Scrubbing) analizzano i file, li spezzano in chunk e memorizzano una sola copia dei chunk duplicati. Si sceglie un usage type in base al carico: Default per file server generici, Hyper-V per VDI, Backup per repository di backup virtualizzati.

Va applicata solo a volumi dati (mai al volume di sistema/boot) su NTFS o ReFS. Non è adatta a file costantemente aperti come database SQL live o VHD/VHDX in esecuzione fuori dagli scenari VDI: lì i chunk cambiano di continuo e il beneficio crolla. È complementare a Storage Replica, ma attenzione ai calcoli di capacità del volume replicato (vedi trappole).

Quote e file screen con FSRM

FSRM raggruppa Quota Management, File Screening, Storage Reports e File Classification. Le quote FSRM si applicano a cartella o volume (non per-utente come le vecchie NTFS disk quota) e si basano su template riutilizzabili con soglie di notifica (email, event log, comando, report) a percentuali di utilizzo.

La distinzione centrale è hard quota vs soft quota:

  • una hard quota è vincolante: al raggiungimento del limite blocca ulteriori scritture;
  • una soft quota non blocca nulla, serve solo a monitorare e notificare il superamento.

Con l’auto apply quota un template viene applicato automaticamente a ogni sottocartella esistente e futura, ognuna con la propria quota. Il file screening controlla invece i tipi di file tramite file group: in modalità active impedisce il salvataggio delle estensioni vietate, in modalità passive consente ma registra/notifica.

Trappole tipiche d’esame

  • RPO zero fra due datacenter vicini → replica sincrona: solo la sincrona garantisce nessuna perdita di dati, ma richiede bassa latenza; su lunga distanza non è supportabile e va scelta l’asincrona.
  • Volume dati protetto ma la replica non parte → manca il log volume GPT dedicato: Storage Replica esige un log volume separato e volumi GPT nello stesso dominio; un disco MBR o condiviso col sistema fa fallire la partnership.
  • Serve solo avvisare senza bloccare → soft quota: se lo scenario dice “consentire il superamento ma notificare”, la risposta è soft quota (o passive screening); la hard quota bloccherebbe l’utente.
  • Bloccare il salvataggio di .mp3/.exe → file screening active, non una quota: le quote limitano lo spazio, non i tipi di file; per vietare estensioni serve il file screening in modalità active.
  • Dedup su database SQL live o VHD in esecuzione → non supportata/inefficace: la dedup è post-process e adatta a file “a riposo”; per carichi sempre aperti scegli l’usage type corretto (Hyper-V per VDI) invece di applicarla indiscriminatamente.
  • Dimensionamento del volume replicato → il target deve essere grande almeno quanto il source: Storage Replica pretende un volume di destinazione di dimensione pari o superiore all’origine; il risparmio della dedup non riduce questo requisito, perché conta la dimensione del volume, non lo spazio libero.