Come eseguire il backup dei dati con Windows Server Backup

Quando Windows Server Backup ha senso e quando no

Windows Server Backup è una soluzione semplice per proteggere server Windows senza introdurre software terzo, soprattutto quando serve un backup locale, su disco dedicato o su volume esterno, con una gestione abbastanza lineare da console o da PowerShell. Non sostituisce una strategia completa di protezione dati, ma copre bene scenari pratici come il salvataggio di volumi, stato del sistema, file critici e, in alcuni casi, il ripristino bare metal.

Il punto da chiarire subito è questo: il backup funziona davvero solo se il ripristino è stato provato. Molti ambienti hanno job schedulati e report “verdi”, ma nessuna prova di restore. In produzione questo è un buco serio, perché il valore del backup non è la copia in sé, ma la capacità di tornare operativi entro il RTO previsto e con perdita dati compatibile con il RPO.

Se il server ospita database, applicazioni con stato o file condivisi ad alta frequenza di modifica, va deciso in anticipo cosa è coerente salvare con Windows Server Backup e cosa invece richiede un livello applicativo o uno storage snapshot coordinato. Il backup a livello volume non conosce la semantica del servizio; per questo la verifica del risultato è parte del progetto, non un controllo opzionale.

Prerequisiti operativi prima di attivare il job

Prima di creare la pianificazione, conviene controllare tre aspetti: spazio disponibile, destinazione del backup e ruolo del server. Windows Server Backup può scrivere su disco dedicato, volume locale o share di rete in alcuni scenari, ma le opzioni cambiano in base alla versione di Windows Server e al tipo di backup scelto. Se la destinazione è un disco dedicato, quel disco viene gestito in modo specifico dal motore di backup e non va trattato come un normale volume dati condiviso.

Per verificare che il componente sia installato, da PowerShell amministrativo puoi usare:

Get-WindowsFeature Windows-Server-Backup

Se il ruolo non è presente, l’abilitazione è semplice:

Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools

Il controllo minimo da fare dopo l’installazione è che la console sia disponibile e che i cmdlet rispondano. Se il server è gestito in modo restrittivo, verifica anche che l’utente operativo abbia privilegi amministrativi locali o un delega equivalente, altrimenti la console si apre ma le operazioni falliscono al momento di lanciare il job.

Backup completo, stato del sistema e selezione dei dati

La scelta più comune è tra backup dell’intero server, backup di volumi selezionati e backup dello stato del sistema. Non sono equivalenti. Il backup del sistema conserva componenti critici di avvio, registry, servizi, database di AD DS se il server è domain controller, e altri elementi necessari a un ripristino coerente del sistema operativo. Il backup di volume è più ampio ma meno “intelligente” rispetto a una procedura di recovery applicativa. Il backup file-level è utile quando vuoi escludere dati temporanei o grandi directory non rilevanti.

In ambienti misti, l’errore classico è includere troppo. Un backup troppo grande peggiora durata, finestra operativa e probabilità di fallimento, e spesso non migliora il recovery reale. Meglio definire i dati in base alla funzione del server: configurazioni, dati applicativi, share utente, stato del sistema, e solo dopo eventuali esclusioni mirate.

Se vuoi vedere come Windows Server Backup interpreta i volumi disponibili, la console grafica mostra direttamente i dischi e i percorsi selezionabili. In PowerShell, invece, puoi ispezionare la configurazione con:

wbadmin get versions

e, per verificare lo stato del catalogo backup, con:

wbadmin get items

Se questi comandi non restituiscono versioni o elementi, non è detto che il job sia fallito: può semplicemente significare che non esiste ancora una catena di backup valida su quella macchina. In quel caso il primo obiettivo è creare una baseline e verificare la produzione di una versione ripristinabile.

Configurazione da interfaccia: percorso più sicuro per chi opera a mano

Quando si lavora su pochi server o si vuole ridurre il rischio operativo, la console grafica resta la via più pulita. Apri Windows Server Backup dal menu Strumenti di Server Manager o da esecuzione diretta del tool. Da lì puoi avviare il backup una tantum o la pianificazione.

1. Apri la console di Windows Server Backup.
2. Seleziona Local Backup e poi Backup Schedule per una pianificazione ricorrente, oppure Backup Once per un test manuale.
3. Scegli il tipo di configurazione: Full server oppure Custom se vuoi selezionare volumi e stato del sistema.
4. Indica la destinazione: disco dedicato o percorso di rete, in base alla politica del server.
5. Definisci orario e frequenza, tenendo conto della finestra di carico dell’applicazione.
6. Conferma il riepilogo e annota i dettagli del job, soprattutto il nome del server, la destinazione e gli oggetti inclusi.

Il vantaggio della console è che rende visibili alcune scelte che in PowerShell possono passare inosservate, come l’inclusione automatica di componenti legati allo stato del sistema. Il limite è evidente: se devi replicare la stessa policy su più server, la GUI diventa fragile e poco auditabile. In quel caso conviene passare a script e documentare il delta di configurazione.

Configurazione da PowerShell: più ripetibile, più controllabile

Per chi gestisce più host o vuole tracciare esattamente cosa viene configurato, la strada migliore è PowerShell. Non serve “automatizzare tutto” a prescindere: basta usare script chiari, versionati e con output verificabile. Il punto non è fare DevOps teatrale, ma evitare click ripetibili solo a memoria.

Un esempio minimo per avviare un backup del volume C: verso una destinazione supportata è questo:

wbadmin start backup -backupTarget:E: -include:C: -quiet

Il parametro -quiet evita richieste interattive. È comodo in schedulazione, ma usalo solo quando la configurazione è già stata validata, perché elimina il punto di arresto che ti farebbe notare un errore di input. Se la destinazione è un disco dedicato, controlla prima che sia montato e che abbia spazio sufficiente. Se è una share di rete, verifica autenticazione, permessi e reachability.

Per un backup dello stato del sistema, il comando cambia in modo sostanziale:

wbadmin start systemstatebackup -backupTarget:E: -quiet

Questo è utile su domain controller, server di infrastruttura o host con configurazioni critiche. Non confondere però il sistema state backup con il backup completo del server: il primo aiuta a recuperare la macchina, il secondo protegge anche i dati applicativi presenti sui volumi inclusi.

Pianificazione: frequenza, finestra e retention

La schedulazione va definita partendo dal dato, non dal tool. Se il server ospita file condivisi o database, il backup notturno potrebbe essere insufficiente. Se invece si tratta di un server di servizi con poca variazione, una finestra giornaliera può bastare. La regola pratica è allineare frequenza e retention al costo della perdita di dati, non alla comodità della finestra di backup.

Per impostare una pianificazione in modo consistente, Windows Server Backup usa un wizard che arriva alla scelta dell’orario e della destinazione. Se preferisci la via scriptabile, puoi generare una configurazione standard e poi documentare il risultato. In ambienti dove la compliance conta, è utile associare alla schedulazione un file di note con: oggetto salvato, destinazione, orario, durata media e ultimo test di restore.

La retention, se la destinazione è un disco dedicato, è spesso gestita dal motore di backup con rotazione automatica delle versioni. Questo semplifica l’operatività, ma non elimina la necessità di controllare il consumo di spazio. Se il volume di dati cresce più velocemente del previsto, il backup può restare formalmente “attivo” ma perdere storico utile o, peggio, fallire quando tenta di creare nuove versioni.

Verifica del backup: il controllo che evita le sorprese

Un backup non verificato è solo un’ipotesi. Dopo il primo run, controlla sempre tre cose: esito del job, presenza della versione e capacità di avviare un ripristino di prova. Il primo controllo è tecnico, il secondo è amministrativo, il terzo è quello che ti salva quando il problema è reale.

1. Apri Event Viewer e controlla i log applicativi e di sistema relativi al backup, cercando errori e warning nel periodo del run.
2. Verifica con wbadmin get versions che la versione sia stata registrata correttamente.
3. Se possibile, avvia un restore di prova su percorso alternativo o in ambiente isolato, senza sovrascrivere i dati di produzione.
4. Controlla che i file ripristinati abbiano dimensione, timestamp e integrità coerenti con l’origine.

La verifica dei log è spesso più utile del solo codice di uscita. I messaggi di errore possono indicare servizi bloccati, spazio insufficiente, accesso negato o snapshot non riuscite. Se hai un problema ricorrente, annota il timestamp e confrontalo con gli eventi del filesystem, del VSS e del servizio di backup. Nei casi più sporchi, la causa non è il tool ma un volume instabile, un antivirus troppo aggressivo o una policy di retention incompatibile con la capacità reale del disco.

Ripristino: come provarlo senza rompere la produzione

Il ripristino va progettato prima, non quando il server è già in emergenza. Se devi recuperare solo alcuni file, il test può essere fatto su una cartella temporanea o su un host di laboratorio. Se devi recuperare un volume o lo stato del sistema, il test deve essere ancora più cauto, perché il blast radius cresce rapidamente. In questi casi è preferibile una macchina di test identica, o almeno compatibile, con snapshot e rollback disponibili.

Per un restore file-level puoi usare la console, selezionare la versione e indicare il percorso di destinazione. In alternativa, da CLI, puoi usare un comando di ripristino mirato. Un esempio concettuale è:

wbadmin start recovery -version:MM/DD/YYYY-HH:MM -itemType:File -items:C:	emp	est.txt -recoveryTarget:D:
estore-test -quiet

La sintassi precisa dipende dal tipo di oggetto e dalla versione di Windows Server, quindi qui il punto non è copiare un comando alla cieca ma verificare i parametri disponibili con wbadmin start recovery /? prima di eseguirlo. Se il server è in produzione e il restore è sensibile, documenta sempre il target, il percorso di destinazione e il piano di rollback.

Errori tipici che si vedono in campo

Il primo errore è usare la stessa destinazione per backup e dati applicativi. È una falsa sicurezza: se il disco si corrompe o viene cifrato da ransomware, perdi sia l’origine sia la copia. Il backup deve vivere su supporto separato e con permessi più stretti del normale storage operativo.

Il secondo errore è ignorare il VSS. Molti file sono copiabili, ma i servizi che scrivono in modo continuo richiedono snapshot coerenti. Se VSS fallisce, il backup può risultare parziale o incoerente. In quel caso i log da controllare sono quelli del servizio Volume Shadow Copy e, se presente, dell’applicazione coinvolta.

Il terzo errore è non misurare la durata. Se il job impiega sempre di più, non è solo un problema di tempo: può essere il segnale di saturazione I/O, crescita dati, frammentazione del target o conflitti con altri processi notturni. Qui la metrica utile è la durata del job, insieme al tasso di completamento e agli errori per esecuzione.

Controlli di sicurezza da non saltare

Un backup contiene spesso dati sensibili, quindi va trattato come un asset di sicurezza. La destinazione deve avere permessi minimi, il server di backup non deve esporre servizi inutili e le credenziali usate per connettersi a eventuali share di rete non vanno salvate in chiaro in script o note operative. Se devi memorizzare credenziali, usa i meccanismi previsti dalla piattaforma e ruotale con cadenza definita.

Se i backup vengono copiati fuori sito, verifica anche cifratura, accesso amministrativo e audit. Non basta che il dato sia “in un altro posto”: deve essere recuperabile solo da chi è autorizzato e deve essere possibile sapere chi ha toccato cosa. Un backup integro ma leggibile da chiunque è un problema, non una protezione.

Una procedura pratica che regge in produzione

Se vuoi una sequenza robusta, la logica è questa: installa il componente, scegli la destinazione, definisci il perimetro, esegui un backup di prova, verifica la presenza della versione, prova un restore non distruttivo e solo dopo metti in schedulazione. Questa progressione evita il classico errore di attivare il job direttamente su tutti i server e accorgersi dei problemi solo al primo incidente vero.

1. Installa Windows Server Backup con Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools.
2. Decidi se proteggere volume, stato del sistema o server completo.
3. Configura la destinazione separata dai dati di produzione.
4. Lancia un backup manuale di test.
5. Controlla log ed elenco versioni con wbadmin get versions.
6. Esegui un restore di prova su percorso isolato.
7. Solo dopo, abilita la pianificazione ricorrente.

Questa sequenza è volutamente conservativa. In pratica, riduce il rischio di scoprire tardi che il target è sbagliato, che la finestra è troppo corta o che il dato selezionato non è quello giusto. Il costo di un test iniziale è basso; il costo di un recovery fallito in emergenza è molto più alto.

Conclusione operativa: cosa guardare sempre

Se devi portarti via un solo criterio, è questo: il backup va giudicato dalla prova di ripristino, non dal fatto che il job sia partito. Con Windows Server Backup puoi coprire bene scenari standard, ma devi tenere sotto controllo destinazione, coerenza dei dati, log, retention e sicurezza della copia. Quando questi elementi sono chiari, il tool fa il suo lavoro senza complicazioni inutili.

Assunzione: i server sono in dominio o comunque amministrati con privilegi locali controllati, e la destinazione del backup è separata dal volume dati principale.