Verificare i ripristini M365 di OneDrive, SharePoint e Teams

In un ripristino M365 devono corrispondere l’oggetto corretto, un punto di backup adatto e una destinazione approvata. Un file può essere stato riscritto correttamente ma trovarsi comunque nel posto sbagliato o essere visibile alle persone sbagliate. Questo percorso conduce quindi dall’incarico circoscritto all’accettazione funzionale per OneDrive, SharePoint e Teams.

Questi scenari riguardano Sophos Backup and Recovery M365 nel modello gestito da Rubrik. Prima del ripristino, verificare per il workload e il tenant specifici quali destinazioni, modalità di sovrascrittura e opzioni di recupero siano disponibili.

Configurare Sophos Backup & Recovery M365 e verificare un ripristino descrive configurazione, subscription, assegnazione SLA e test Exchange separato. Il percorso seguente presuppone un backup configurato e non amplia né le autorizzazioni Microsoft né l’ambito di prodotto acquistato.

Delimitare l’incarico di ripristino

Prima di accedere a uno snapshot, registrare tenant sorgente, subscription e responsabile. Specificare utente o sito interessato, percorso esatto dell’oggetto, presunto evento di perdita o modifica con fuso orario e stato desiderato. In un incidente di sicurezza concordare con il responsabile dell’incidente un punto adatto non ancora compromesso. Il backup più recente non è automaticamente quello giusto.

Per un pilota usare esclusivamente account di test approvati e dati innocui. backup-pilot@example.invalid, Restore-Pilot-2026-10-29.txt e Restore-Abnahme sono esempi di utente di test, file e destinazione di verifica desiderata; non sono oggetti tenant esistenti. Prima di un incarico reale sostituirli con valori di test propri e confermati.

Per la destinazione stabilire per iscritto se i dati servono nella posizione originale o separatamente. Non scegliere un altro utente, sito o subscription soltanto perché la procedura guidata lo consente. Autorizzazioni, regione dei dati e responsabilità della destinazione fanno parte della stessa approvazione.

Chiarire i conflitti tra file prima di scrivere

La destinazione può contenere file omonimi, modifiche più recenti o documenti bloccati. Prima della conferma deve quindi essere chiaro se il percorso specifico sovrascrive, rinomina, salta o crea una copia separata. Non dedurre queste varianti dal comportamento di un ripristino Exchange. Per OneDrive, ad esempio, Rubrik distingue risultati completi e parziali e può segnalare oggetti rinominati a causa di conflitti di nome. Non ne deriva una regola generale sui conflitti per tutti i workload.

Se l’effetto della modalità proposta non è chiaro, non avviare ancora il ripristino. Chiarire prima la guida del workload ed eventualmente il caso con il supporto. Un ripristino sul posto apparentemente rapido non deve sostituire senza consenso una modifica corrente.

Aprire lo snapshot corretto e la guida del workload

1. In Sophos Fusion (in precedenza Sophos Central) aprire My Products > Backup and Recovery M365. Dopo il reindirizzamento controllare l’organizzazione Rubrik.
2. Aprire Inventory > SaaS > Microsoft 365. Identificare la subscription confermata per l’incarico; non indovinarla da un nome visualizzato simile.
3. Controllare ambito di protezione, assegnazione SLA e backup disponibili dell’oggetto interessato. Uno stato di integrazione verde non dimostra che esista uno snapshot con la versione di file richiesta.
4. Prima di un incarico di scrittura, aprire l’icona Help e nel Help Center la guida corrispondente al workload. Il titolo documentato per SharePoint è Backup and recovery of SharePoint sites and site collections, per Teams Teams data recovery. Per OneDrive cercare nel Help Center OneDrive e il percorso di ripristino previsto.
5. Confrontare il momento scelto con evento e fuso orario. Verificare l’oggetto selezionato nello snapshot rispetto a sorgente, percorso e contenuto atteso. Ricontrollare sorgente, ambito, destinazione e gestione dei conflitti rispetto all’incarico prima dell’ultimo passaggio di scrittura.

Le verifiche seguenti non sostituiscono la sequenza esatta di clic specifica del workload. Una selezione documentata per Exchange, come Recover to a new folder, non garantisce che lo stesso dialogo esista per OneDrive, SharePoint o Teams. Se la guida non corrisponde al percorso proposto, fermarsi prima del ripristino e chiarire la differenza.

OneDrive: verificare una specifica versione di file

Per uno scenario di test circoscritto, la persona di test approvata crea un file di testo innocuo con nome univoco. Il contenuto riceve inizialmente il valore di controllo Alpha. Dopo uno snapshot confermato, il file viene modificato in Bravo e nuovamente salvato nel backup. Annotare entrambi i momenti e la versione rispettivamente attesa. Questo scenario è un piano di verifica, non un risultato di prodotto già osservato.

Per il ripristino scegliere consapevolmente lo snapshot con Alpha. Prima di iniziare controllare utente di destinazione confermato, percorso completo e gestione del file Bravo ormai presente. Se il percorso scelto supporta una copia separata ed essa è approvata, questa facilita il confronto. Non si presuppone tale modalità; non procedere se la sovrascrittura non è chiarita.

Dopo l’incarico verificare prima messaggio del job e numero di oggetti, comprese avvertenze, errori parziali e rinominazioni. Poi la persona di test apre il file effettivamente creato nella destinazione documentata. Deve contenere il valore di controllo atteso. Se è stata usata una cartella aggiuntiva o un altro nome, registrare esattamente quel percorso. Un file invariato nella vecchia posizione non è una prova sostitutiva.

Controllare inoltre accessi e condivisioni: la persona di test prevista deve poter aprire il file; un account di test non autorizzato non deve ottenere un nuovo accesso. Un file di testo verificato nel pilota non conferma ancora un ripristino completo dell’utente né il mantenimento di tutti i link di condivisione o delle proprietà del file.

SharePoint: accettare separatamente contenuto, destinazione e proprietà

Per SharePoint l’incarico parte dall’URL esatto del sito. Si stabilisce poi se occorre un singolo file, una cartella, una raccolta, un elenco o una struttura più ampia. Una raccolta omonima in un altro sito è una destinazione diversa.

Per il pilota è adatta una raccolta di test approvata con un piccolo file e un valore di controllo annotato prima. Se rilevanti per l’uso successivo, documentare anche un campo di metadati e il gruppo di autorizzazioni atteso. Lo snapshot deve contenere proprio questi dati iniziali. Cronologia delle versioni, struttura degli elenchi o autorizzazioni individuali vengono confermate come ripristinate soltanto se fanno parte dell’ambito selezionato e sono state verificate separatamente.

Prima dell’ultimo passaggio di scrittura controllare sito di destinazione, ambito degli oggetti e possibili collisioni con i contenuti correnti. Se serve solo un file, non ripristinare preventivamente un intero sito. Dopo il job, il responsabile verifica contenuto nella destinazione corretta, proprietà previste e accesso. Un job completato nel portale Rubrik non dimostra ancora che un’applicazione aziendale possa utilizzare la struttura ripristinata.

Se la struttura del sito differisce tra snapshot e presente, verificare esplicitamente percorso sorgente e associazione della destinazione. Con una destinazione mancante o autorizzazioni non chiarite, non creare account, siti o ruoli aggiuntivi per tentativi. L’incarico deve prima stabilire il percorso di destinazione supportato e le responsabilità necessarie.

Teams: distinguere file e collaborazione

Un incarico «ripristinare Teams» è troppo generico. Deve indicare se servono messaggi, un canale, file o altri contenuti. Microsoft documenta che i file dei canali standard si trovano nel sito SharePoint del team; i canali privati e condivisi hanno siti propri. Il solo nome del canale non basta quindi a stabilire lo snapshot corretto dei file.

Per un pilota circoscritto concordare un team di test approvato, il tipo di canale e un contenuto innocuo. Per un file del canale, registrare sito SharePoint effettivo, raccolta e file e verificarli secondo il piano di accettazione SharePoint. Un file recuperato non conferma né il ripristino di messaggi del canale né di appartenenze, schede o dell’intera configurazione Teams.

Se servono messaggi o strutture di canale, chiarire prima del ripristino in Teams data recovery quali tipi di oggetti e destinazioni sono supportati dallo specifico stato di erogazione. Documentare separatamente team sorgente, canale, snapshot e destinazione. Dopo l’incarico un membro di test autorizzato verifica il contenuto richiesto in Teams; per i file rimane necessaria un’ulteriore verifica della posizione effettiva. Senza ambito confermato e snapshot adatto non promettere un ripristino completo e generico di Teams.

Registrare il risultato e terminare il test

Il verbale di accettazione registra oggetto sorgente, ora dello snapshot con fuso orario, destinazione, modalità scelta e riferimento tracciabile del job. Include numero di oggetti, avvertenze, rinominazioni, campione di contenuti verificati, accesso e durata misurata. Risultato atteso e risultato effettivamente osservato restano distinti.

Se un incarico restituisce un errore o un completamento incerto, non avviare subito lo stesso ripristino. Chiarire prima nel portale e nella destinazione se siano già stati scritti dati. Anche un risultato parziale può avere creato o modificato oggetti. In un’escalation indicare sorgente esatta, momento, destinazione e messaggio depurato; non copiare contenuti di file, credenziali o export completi in ticket pubblici.

Un ripristino non ha un comando universale per annullarlo. Rimuovere copie di test aggiuntive soltanto dopo l’accettazione e nel solo ambito di test concordato. File produttivi, contenuti aziendali ripristinati o backup non sono un «rollback» indiscriminato. Finché un contenuto necessario o un’autorizzazione non è confermato, l’incarico resta aperto anche se il job tecnico appare riuscito.