1 25/05/2026 11 min

Il backup di un server SCCM non si riduce a copiare una cartella a fine giornata. Se vuoi un ripristino credibile, devi mettere insieme stato applicativo, database, contenuti distribuiti, certificati, configurazioni di integrazione e una verifica reale del restore. Il punto non è salvare “qualcosa”, ma avere un insieme coerente che ti permetta di ricostruire il sito senza inseguire dipendenze perse per strada.

Su Microsoft Configuration Manager la parte più delicata è la coerenza tra SQL, componenti del sito, content library e oggetti di configurazione. Se uno di questi pezzi manca, il backup esiste ma il ripristino diventa incompleto o richiede interventi manuali pesanti. Per questo conviene separare il lavoro in tre livelli: ciò che è gestito nativamente dal prodotto, ciò che va protetto con backup esterni e ciò che va documentato perché non sempre è esportabile in modo pulito.

Prima decisione: cosa devi davvero poter ripristinare

Un backup SCCM utile deve rispondere a una domanda semplice: vuoi recuperare il server dopo un guasto del sistema operativo, ricostruire il sito dopo corruzione del database o migrare verso un nuovo host? La risposta cambia il perimetro. In un incident recovery serio, almeno questi elementi devono essere coperti: database del sito, cartelle del site server, content library, certificati usati dai ruoli, file di configurazione personalizzati e dati di supporto come report o script di automazione.

Se ti limiti al backup del database, recuperi i metadati ma non i contenuti distribuiti ai DP, i file personalizzati del server e spesso nemmeno la stessa facilità di riallineamento dei ruoli. Se invece salvi solo il file system, perdi la parte transazionale che vive in SQL e rischi inconsistenze difficili da sanare. La regola pratica è questa: il database è il cuore, ma non è il corpo intero.

Componenti da includere nel piano di backup

Per un server SCCM on-prem, l’elenco minimo ragionevole comprende il database del site server, le directory di installazione del sito, la content library del Distribution Point se residente sul server o su storage dedicato, i certificati e le chiavi private associate, oltre a eventuali cartelle di integrazione con PXE, boot image, task sequence personalizzate, script e report SSRS. Se hai integrato il sito con SQL Server Reporting Services, anche la configurazione dei report va trattata come oggetto da preservare.

La parte spesso trascurata è la documentazione del topology. Non basta sapere che esiste un Primary Site: devi sapere dove sono installati Management Point, Distribution Point, SUP/WSUS, endpoint di distribuzione, eventuali tenant attach o cloud management gateway. Senza questa mappa, il restore è tecnicamente possibile ma operativamente lento e fragile.

Backup nativo SCCM: quando usarlo e cosa aspettarti

Configuration Manager include una manutenzione di backup del sito che salva database e alcuni file di configurazione del site server. È la base da cui partire, non la soluzione totale. Va bene per proteggere la struttura logica del sito, ma non sostituisce il backup dell’infrastruttura sottostante. In pratica, il backup nativo copre il “cervello” del sito, mentre il resto lo devi proteggere con strumenti esterni o con snapshot coerenti.

Se stai usando il backup nativo, controlla che il percorso di destinazione sia su storage separato dal volume del sito. Un backup scritto sullo stesso disco del server non ti salva da guasto hardware, saturazione o ransomware. Il target deve stare fuori dal dominio di fallimento del server primario, idealmente su share protetta o repository con retention adeguata.

La verifica minima che vuoi vedere è l’esecuzione regolare del task di backup e la presenza di file recenti nel percorso configurato. Se hai accesso ai log del sito, il riferimento pratico è il file `smsbkup.log`, che racconta se il processo è partito, se ha trovato errori e se il dump è stato completato. Il controllo non è teorico: devi leggere un esito recente, non assumere che il job sia sano solo perché esiste.

Configurare il backup nativo dal console path

Dal console di SCCM, la configurazione del backup del sito si gestisce nell’area di manutenzione del sito. Il percorso preciso può variare leggermente in base alla versione, ma il concetto resta lo stesso: abiliti il task, imposti la destinazione e definisci la finestra di esecuzione. Se il task è già presente, non duplicarlo: modifica quello esistente e tieni traccia del cambio con una nota operativa.

La scelta della finestra è importante. Il backup del sito può generare carico su SQL e I/O sul file system, quindi è meglio collocarlo in orari di bassa attività. In ambienti grandi, soprattutto con molti oggetti, policy e distribuzioni, il backup può durare più di quanto sembri. Se lo lanci troppo vicino alle finestre di manutenzione o ai cicli di maintenance SQL, rischi sovrapposizioni inutili.

La verifica operativa da fare dopo l’attivazione è semplice: controlla che il task risulti abilitato, che il percorso di output esista e che il log `smsbkup.log` riporti un ciclo completato senza errori. Se il task non scrive nulla per giorni, non considerarlo sano. In quel caso la priorità è capire se il servizio, la share di destinazione o i permessi del computer account hanno rotto il flusso.

Database SQL: backup coerente, non solo file .bak

Il database del sito è il componente più sensibile. Se fai backup SQL, devi distinguere tra full backup, differential e transaction log. In un ambiente SCCM, il full backup periodico è il minimo; i log servono se vuoi un punto di ripristino più stretto. La frequenza dipende dal RPO reale, non da una regola astratta. Se perdi un’ora di dati di configurazione è accettabile, i log ogni 15 minuti hanno senso; se il rischio è basso, puoi semplificare.

Il backup SQL va eseguito con un’attenzione speciale alla coerenza. Se usi strumenti enterprise o job SQL Server Agent, assicurati che il database SCCM sia incluso e che la retention non cancelli il set utile prima che il backup nativo del sito abbia completato il suo ciclo. Se usi snapshot a livello storage, verifica che siano application-consistent. Uno snapshot crash-consistent di un database attivo non è il tipo di base da cui vorresti partire durante un incidente.

Per la verifica, cerca l’ultimo file `.bak` o il log del job SQL e controlla dimensione, timestamp e assenza di errori. Un comando utile, lato SQL o dal sistema che ospita il file, è questo:

dir D:\SQLBackups\CM_*.bak

Se il timestamp non cambia o il file è anomalo per dimensione, il problema non è il restore ma il backup stesso. Prima di andare oltre, va chiusa la causa a monte.

Content Library e Distribution Point: il pezzo che molti perdono

La content library contiene il materiale distribuito ai client: package, application content, boot image, aggiornamenti e altro. Se il Distribution Point è sullo stesso server o su storage locale, devi proteggerlo come parte integrante del recovery. Se non lo fai, al ripristino avrai un sito vivo ma incapace di servire contenuti correttamente fino a nuova redistribuzione.

Qui la strategia dipende dall’architettura. In ambienti piccoli spesso basta il backup del volume o della share che contiene la library. In ambienti più complessi è meglio documentare il percorso esatto e prevedere una procedura di ricostruzione del DP. Il punto pratico è sapere dove si trova la content library e come rigenerarla senza inventare il layout durante il disastro.

Il controllo che conta è banale ma efficace: su un client di test, verifica che un package noto sia scaricabile dal DP dopo il restore. Non fermarti alla console che mostra gli oggetti distribuiti; la prova vera è il download effettivo. Se il contenuto non parte, il problema è nel repository o nella registrazione del DP, non nella sola console.

Certificati, chiavi e segreti: non lasciarli fuori dal piano

Molte installazioni SCCM usano certificati per HTTPS, communication with clients, PXE o integrazioni esterne. I certificati con chiave privata vanno esportati e custoditi secondo policy, non copiati in modo approssimativo. Se il server usa certificati per ruoli esposti o per canali sicuri verso componenti esterni, il restore senza quei materiali ti costringe a rigenerare fiducia e riconfigurare i ruoli.

Non salvare segreti in chiaro dentro script o note operative. Se hai parametri sensibili, documenta il meccanismo di recupero e il vault usato, non il valore. In un piano di backup serio, il riferimento è il percorso del vault o del repository sicuro, insieme alla procedura per autorizzare il restore. Se oggi non hai un vault, il gap va chiuso prima di basare il recovery su password sparse in file condivisi.

Procedura pratica di backup: sequenza consigliata

La sequenza più pulita è questa: prima congeli la vista logica del sito con il backup nativo o con un checkpoint coerente, poi proteggi il database, poi i file del site server e infine i contenuti e i certificati. Così riduci la possibilità di avere un DB più recente dei file o viceversa. La coerenza temporale conta più della quantità di copie sparse.

  1. Verifica che il backup nativo del sito sia abilitato e punti a una destinazione esterna al server.
  2. Esegui o verifica il backup full del database SCCM con retention adeguata.
  3. Proteggi le directory del site server, i percorsi custom e i file di integrazione.
  4. Salva content library e dati del Distribution Point se risiedono su storage locale o dedicato.
  5. Esporta e archivia certificati e chiavi private secondo policy aziendale.
  6. Documenta versioni, ruoli, percorsi e dipendenze esterne prima di chiudere il ciclo.

Un esempio di controllo lato filesystem, utile per capire se il backup nativo sta producendo output, è verificare la presenza di file recenti nella share di destinazione. Il comando cambia in base all’ambiente, ma il concetto è questo:

dir \\backupserver\SCCMBackup\ /O:-D

Se il file più recente non coincide con l’ultima esecuzione attesa, il ciclo è da considerare sospetto fino a prova contraria.

Verifica del restore: il test che separa il backup dalla speranza

Un backup non testato è una promessa, non una protezione. Il test minimo consiste nel ripristinare il database in un ambiente isolato o in un lab, avviare i servizi necessari e verificare che la console si connetta, che i ruoli principali risultino coerenti e che almeno un client di test riceva policy e contenuti. Se il tuo processo non prevede questo passaggio, il rischio operativo resta alto anche con backup apparentemente regolari.

Durante il test controlla i log di setup e del sito, in particolare quelli relativi al restore e al bootstrap dei componenti. Se il restore fallisce, devi capire se il problema è nel database, nei permessi del service account, nella versione del build o nella mancata corrispondenza fra file e DB. Non cercare di correggere tutto insieme: isola il punto di rottura e rifai il test dopo una singola correzione.

Per un check rapido post-restore, questi segnali sono utili: console raggiungibile, servizi del sito in stato attivo, policy distribuite, contenuti accessibili e nessun errore evidente nei log principali. Se uno solo di questi manca, il restore va considerato incompleto. In un contesto SCCM, “si apre la console” non equivale a “il sito è recuperato”.

Retention, frequenza e blast radius

La retention deve coprire almeno il tempo realistico in cui potresti accorgerti di una corruzione o di un errore umano. Se scopri un problema dopo dieci giorni, un backup che conserva solo tre giorni di storia è inutile. La frequenza va tarata sul valore del cambiamento: in un sito molto dinamico, con molte distribuzioni e modifiche, il ciclo va stretto; in ambienti stabili può essere più largo.

Il blast radius di un errore di backup SCCM è ampio: puoi perdere capacità di distribuzione, policy, aggiornamenti, compliance, task sequence e continuità operativa dei client. Per questo il rollback non è solo “ripristino del file backup”, ma ritorno a uno stato coerente del sito, con validazione dei ruoli e dei contenuti. Se la procedura tocca configurazioni o dati, tieni sempre una copia precedente e una finestra chiara di ritorno indietro.

Checklist finale da tenere vicino alla console

  • Il backup nativo del sito è attivo e scrive su destinazione esterna.
  • Il database SCCM ha un backup SQL verificato, con file recenti e leggibili.
  • La content library e i DP sono protetti secondo l’architettura reale.
  • I certificati con chiave privata sono esportati e custoditi correttamente.
  • Esiste un test di restore eseguito, documentato e ripetibile.
  • La documentazione dei ruoli e dei percorsi è aggiornata dopo ogni change.

Se vuoi ridurre i tempi di ripristino, il vero investimento non è fare più backup, ma rendere prevedibile il restore. In SCCM questo significa sapere dove sono i dati, come si ricompone il sito e quale componente va validato per primo. Quando il disastro arriva, la differenza la fa chi ha già trasformato il backup in procedura, non in archivio.