Punti chiave
- Microsoft non garantisce il ripristino in caso di eliminazione accidentale, ransomware o errori di configurazione: per proteggere i dati servono backup di Microsoft 365 indipendenti e test di ripristino.
- Verifica che esistano backup per Exchange Online, OneDrive, SharePoint e Teams, con credenziali valide, licenze attive e accesso API continuo, così da evitare falsi errori di ripristino.
- Esegui i test di ripristino a livello di carico di lavoro e di singolo elemento, per validare le reali esigenze di recupero e assicurarti di rispettare i requisiti di RTO (recovery time objective) e RPO (recovery point objective).
- Usa l’automazione (PowerShell, API o strumenti di backup) per testare i ripristini con regolarità, monitorare gli esiti e registrare i risultati ai fini della conformità e degli audit.
Un backup vale quanto la sua capacità di essere ripristinato. Questa guida spiega passo dopo passo come testare la capacità di ripristino dei carichi di lavoro Microsoft 365, ovvero Exchange Online, SharePoint, OneDrive e Teams, usando gli strumenti Synology.
Al termine dell’articolo saprai come proteggere i dati critici per il business e garantire che la tua organizzazione possa recuperarli in modo affidabile e rapido durante un incidente.
Preferisci un riepilogo visivo? Guarda il nostro video “Come testare la capacità di ripristino dei dati Microsoft 365 con gli strumenti Synology” per approfondire l’argomento.
Come testare la capacità di ripristino
Metodo 1: validare Synology Active Backup for Microsoft 365
📌 Casi d’uso: ideale per testare i ripristini a livello di utente e di carico di lavoro (Exchange, SharePoint, OneDrive, Teams)
📌 Prerequisiti:
- NAS (Network Attached Storage) Synology con Active Backup for Microsoft 365 (ABM365)
- Attività di backup configurate e completate
- DSM e ABM365 aggiornati all’ultima versione
Passaggi:
- Avvia Synology Active Backup for Microsoft 365 dall’interfaccia del NAS.
- Vai su Task List per verificare lo stato dei backup:
- Controlla i risultati dei processi e l’ora dell’ultima esecuzione.
- Verifica la dimensione del backup e l’esito (riuscito o non riuscito).
- Apri il Restore Portal.
- Accedi usando una di queste opzioni:
- credenziali di amministratore globale
- autorizzazioni di ripristino delegate
- Seleziona un carico di lavoro:
- casella di posta Exchange
- file OneDrive
- sito SharePoint
- messaggio Teams
- Scegli un punto di ripristino e visualizza l’anteprima dell’elemento
- Esegui il ripristino e verifica che:
- l’elemento o il contenuto ripristinato sia quello corretto
- autorizzazioni e struttura siano state mantenute
- non ci siano dati danneggiati o problemi di visibilità
💡 Suggerimento: usa il riquadro di anteprima per verificare la correttezza dei singoli elementi prima del ripristino.
Metodo 2: automatizza i controlli con PowerShell o le API REST
📌 Casi d’uso: questo metodo è utile quando devi pianificare controlli di integrità o un reporting proattivo sui processi di backup non riusciti o inattivi.
📌 Prerequisiti:
- PowerShell 5.1+ installato (Verifica la tua versione di PowerShell)
- Accesso al token API di Synology
- Accesso di rete al DSM Synology
Passaggi:
- Apri PowerShell come amministratore.
- Esegui questo comando:
Connect-VB365
Get-VBOJobSession | Where-Object { $_.Status -ne “Success” } |
Format-Table Name, Status, EndTime
- In alternativa, su Synology esegui questo script bash:
curl -X POST https://yourdiskstation:5001/webapi/entry.cgi \
-d “api=SYNO.Backup.M365.Status&version=1&method=list” \
-H "X-SYNO-TOKEN: your-session-token"
- Aggiungi pianificazione o avvisi tramite:
- Utilità di pianificazione di Windows
- Task Scheduler di Synology
- l’automazione dei flussi di lavoro di NinjaOne
💡 Suggerimento: tra i trigger di avviso rientrano i processi non riusciti, quelli che non vengono eseguiti entro 24-48 ore o che generano oggetti incompleti.
Metodo 3: tracciare i test di ripristino con le chiavi di registro
📌 Casi d’uso: ottimo se vuoi monitorare la frequenza dei ripristini per dispositivo o tenant. Puoi usare questo metodo anche come integrazione per gli audit di conformità rispetto agli SLA interni o agli obblighi normativi.
📌 Prerequisiti:
- Accesso come amministratore locale al Registro di sistema di Windows
- Sistema di backup con record di test accessibili
- Uno strumento per l’esecuzione degli script (come NinjaOne o un’attività PowerShell)
- È vivamente consigliato eseguire il backup del Registro di sistema di Windows. Configurazioni errate possono rendere instabile il sistema.
Passaggi:
- Premi Win + R, digita regedit e premi Invio.
- Vai su: HKEY_LOCAL_MACHINE\SOFTWARE\Org\BackupRestoreValidation
- Crea i valori seguenti:
- LastRestoreTestDate (stringa) = “2025-07-01T18:00:00Z”
- ToolUsed (stringa) = “Synology ABM365”
- Usa l’automazione (ad esempio tramite NinjaOne o PowerShell) per:
- leggere le chiavi e individuare i test scaduti;
- aggiornare i valori quando vengono eseguiti i test;
- generare avvisi quando un test è in ritardo.
💡 Suggerimento: esporta le voci di registro verso un server di log centralizzato o una dashboard di conformità.
Metodo 4: applicare policy di backup degli endpoint tramite Criteri di gruppo (per i client Synology)
📌 Casi d’uso: questo metodo è utile per prevenire eliminazioni accidentali di file, imporre l’uso del Volume Shadow Copy (VSS) o proteggere gli endpoint usati negli scenari di ripristino ibrido.
📌 Prerequisiti:
- Ambiente di dominio Windows con accesso ai Criteri di gruppo
- Agente Synology installato (se esegui il backup anche dei file locali)
Passaggi:
- Premi Win + R, digita gpedit.msc e premi Invio.
- Vai su: Configurazione del computer > Modelli amministrativi > Sistema > Protezione file di Windows
- Abilita i valori seguenti:
- Non consentire agli utenti di rimuovere i file di sistema critici
- Richiedi Volume Shadow Copy per tutti i backup locali
- Applica l’oggetto Criteri di gruppo alle unità organizzative (OU) interessate.
- Usa gpresult o i log di audit per verificare che il criterio sia stato applicato.
💡 Nota: anche se non esegui il backup dei file degli endpoint su Synology, queste impostazioni prevengono la perdita di dati critici in caso di sovrascrittura accidentale o durante il recupero da ransomware.
Metodo 5: verificare l’accessibilità dei file di backup tramite CMD o CLI
📌 Casi d’uso: questo metodo garantisce che i backup non siano soltanto “registrati”, ma anche fisicamente accessibili e utilizzabili. Ti permette inoltre di controllare rapidamente la presenza e la dimensione del file di backup.
📌 Prerequisiti:
- Accesso al file system delle directory di backup
- Accesso di rete o montaggio (SMB, iSCSI) alle condivisioni Synology
Passaggi:
A. Per le condivisioni di backup Synology (tramite SMB)
- Esegui questo comando:
net use Z: \\synology\m365backup
dir Z:\backups\user01
B. Automatizza gli script per:
- controllare data, ora e dimensione dei file;
- confermare la disponibilità degli snapshot recenti;
- registrare o segnalare file mancanti o di dimensioni inferiori al previsto.
💡 Suggerimento: fai attenzione ai file .vbcat incompleti o alle cartelle OneDrive/Teams mancanti, che possono indicare backup non riusciti o credenziali scadute.
Altri aspetti da considerare quando testi la capacità di ripristino
Ambito del ripristino
- Testa sempre sia i ripristini completi sia quelli granulari (ad esempio un’intera casella di posta rispetto a una singola email).
- Simula incidenti reali: una cartella SharePoint danneggiata, una chat di Teams eliminata e così via.
Scadenza delle credenziali
- I token OAuth e Graph API in genere scadono ogni 1-2 anni.
- Pianifica il rinnovo delle credenziali e l’audit delle autorizzazioni API ogni 12 mesi.
Licenze
- Synology Active Backup limita l’accesso ad alcune funzionalità se la licenza non è attivata.
- I processi di backup possono continuare a essere eseguiti, ma i diritti di ripristino possono decadere senza alcun avviso. Verificali spesso.
Gestione multi-tenant (per gli MSP)
- Tieni traccia dei test di ripristino per ogni cliente usando:
- tag di metadati (ad esempio in NinjaOne o nelle note dei processi di ripristino)
- registrazione di data e ora (tramite Registro di sistema)
- dashboard dedicate a ciascun tenant per il reporting
💡 Suggerimento: eseguire un test è utile, ma è sempre meglio automatizzare la verifica della capacità di ripristino per ridurre al minimo i rischi. È anche un elemento fondamentale di qualsiasi piano di backup e ripristino dei dati.
⚠️ Aspetti a cui prestare attenzione
| Rischi | Possibili conseguenze | Rimedi |
| I processi di backup non riescono senza segnalazioni a causa di credenziali scadute | Nessun backup ripristinabile per settimane o mesi | Autentica di nuovo le credenziali dell’app in Synology ed esegui di nuovo i processi di backup completi. |
| Processo contrassegnato come “riuscito” ma con errori a livello di oggetto | Caselle di posta mancanti, file danneggiati o copertura di backup parziale | Esamina i log dei processi e attiva le notifiche via email o gli avvisi tramite PowerShell. |
| Modifica del token OAuth o delle autorizzazioni Graph API | Ripristini parziali o non riusciti, soprattutto per Teams e SharePoint | Rinnova il token e verifica periodicamente le autorizzazioni dell’app (ogni anno o ogni sei mesi). |
| Backup archiviati ma inaccessibili a causa di modifiche alle autorizzazioni | Recupero impossibile in caso di incidente | Verifica gli elenchi di controllo di accesso (ACL) del repository e le autorizzazioni del portale di ripristino. |
| Punto di ripristino troppo vecchio per rispettare RTO/RPO | Mancata conformità o risposta agli incidenti incompleta | Pianifica test di ripristino settimanali e automatizza la registrazione di data e ora tramite il Registro di sistema o NinjaOne. |
| Backup degli endpoint esclusi dai flussi di lavoro cloud | Perdita di dati per gli utenti con flussi di lavoro ibridi o solo locali | Usa i Criteri di gruppo e gli agenti endpoint Synology per definire l’ambito del backup e la conservazione. |
Risoluzione dei problemi di ripristino più comuni
Accesso negato durante il ripristino con Synology
Può dipendere da ambiti Graph API configurati male o da token OAuth scaduti. Per risolvere il problema, autorizza di nuovo il connettore Microsoft 365 da DSM.
Verifica sempre che il token dell’applicazione disponga delle autorizzazioni delegate necessarie (come Mail.ReadWrite, Sites.ReadWrite.All e così via) e che non sia scaduto.
Il portale di ripristino Synology non si carica
Spesso è il segnale di problemi di compatibilità della versione di DSM o di impostazioni SSL/TLS errate. Per risolvere il problema, assicurati che Synology DiskStation Manager (DSM) sia aggiornato a una versione compatibile con il tuo attuale ambiente Microsoft 365.
Inoltre, verifica che il binding HTTPS sia configurato correttamente per un accesso sicuro. Negli ambienti in cui l’accesso HTTP è disabilitato o reindirizzato in modo errato, il portale potrebbe non caricarsi affatto.
Elementi mancanti nella selezione per il ripristino
Può indicare che i dati non sono mai stati indicizzati correttamente o che un processo di backup ha saltato oggetti importanti a causa di una configurazione errata. Succede quando agli utenti è stata assegnata una licenza di recente, sono stati spostati tra gruppi o esclusi tramite filtri.
Per risolvere il problema, esegui di nuovo il backup manualmente e controlla nei log eventuali utenti saltati o messaggi di errore. Verifica inoltre che l’indicizzazione sia abilitata per tutti i carichi di lavoro.
Il ripristino va in timeout o si blocca
Di solito indica problemi di prestazioni del repository di backup o una latenza di rete eccessiva. Prova a isolare l’operazione di ripristino su un disco più veloce oppure a spostare temporaneamente il processo su un volume ad alta disponibilità. Con Synology, assicurati che le schede di rete siano correttamente aggregate o assegnate e che le connessioni iSCSI o SMB siano stabili.
Come NinjaOne aiuta a uniformare la capacità di ripristino tra più tenant
- Distribuzione di script PowerShell: puoi distribuire facilmente script per verificare lo stato dei processi Synology. Puoi anche individuare i backup non riusciti e creare report sulla cronologia dei ripristini su endpoint e tenant.
- Audit del Registro di sistema: NinjaOne può analizzare chiavi di registro personalizzate (ad esempio LastRestoreTestDate) e generare report per confermare se gli amministratori locali o gli agenti hanno completato i test di ripristino negli intervalli previsti.
- Dashboard personalizzate: NinjaOne offre visibilità centralizzata sullo stato dei processi di backup, sull’ultimo ripristino riuscito per tenant o dispositivo e sulle lacune nella frequenza dei test o nella copertura degli oggetti.
- Avvisi tra tenant: la piattaforma genera automaticamente avvisi quando le verifiche di ripristino sono in ritardo e i backup non riescono senza segnalazioni, oppure quando i token OAuth o le licenze stanno per scadere.
- Automazione dei flussi di lavoro: collega i controlli sulla capacità di ripristino a ticket, log o avvisi. Puoi integrare gli eventi di verifica dei ripristini nei flussi di reporting sulla conformità o nella documentazione degli SLA.
Testa la capacità di ripristino con gli strumenti giusti
Sembra ovvio, ma vale la pena ripeterlo: un backup è inutile se non può essere ripristinato. Per questo testare la capacità di ripristino non è un’opzione, ma una necessità. Questa guida ti ha fornito gli strumenti, le tecniche e i percorsi di automazione per garantire che il tuo ambiente Microsoft 365 non sia soltanto sottoposto a backup, ma davvero recuperabile.
Argomenti correlati:
