Resilienza dei dati di SharePoint e OneDrive in Microsoft 365

All'interno di Microsoft 365, OneDrive è basato sulla piattaforma di file di SharePoint. In questo articolo viene usato solo SharePoint per fare riferimento a entrambi i prodotti. Questo articolo si applica anche a qualsiasi altro prodotto che archivia dati in SharePoint, ad esempio allegati cloud, file condivisi in Teams, registrazioni e trascrizioni delle riunioni di Teams, componenti loop e lavagne.

Esistono due asset primari che costituiscono l'archiviazione del contenuto principale di SharePoint:

• Archiviazione BLOB: il contenuto utente caricato in SharePoint viene archiviato in Archiviazione di Azure. SharePoint ha creato un piano di resilienza personalizzato su Archiviazione di Azure per garantire la duplicazione quasi in tempo reale del contenuto utente e un sistema veramente attivo/attivo.
• Metadati: i metadati relativi a ogni file vengono archiviati nel database SQL di Azure. Azure SQL offre una storia di continuità aziendale completa usata da SharePoint e i dettagli sono trattati più avanti in questo articolo.

Il set completo di controlli per garantire la resilienza dei dati è illustrato in altre sezioni.

Resilienza dell'archiviazione BLOB

SharePoint ha una soluzione personalizzata per l'archiviazione dei dati dei clienti in Archiviazione di Azure. Ogni file viene scritto simultaneamente in un'area del data center primaria e secondaria. Se le operazioni di scrittura in un'area di Azure hanno esito negativo, il salvataggio del file ha esito negativo. Dopo aver scritto il contenuto in Archiviazione di Azure, i checksum vengono archiviati separatamente con i metadati e vengono usati per garantire che la scrittura di cui è stato eseguito il commit sia identica al file originale durante tutte le letture future. Questa stessa tecnica viene usata in tutti i flussi di lavoro per evitare la propagazione di eventuali danneggiamenti. All'interno di ogni area, Archiviazione con ridondanza locale di Azure offre un livello elevato di affidabilità.

SharePoint usa Append-Only archiviazione, il che significa che Microsoft può aggiungere solo nuovi BLOB e non può mai cambiare quelli precedenti fino a quando non vengono eliminati definitivamente. Questo processo garantisce che i file non possano essere modificati o danneggiati dopo un salvataggio iniziale, proteggendo dagli utenti malintenzionati che tentano di danneggiare le versioni precedenti. Poiché la protezione dell'integrità della versione è integrata nell'architettura di SharePoint, è possibile recuperare le versioni precedenti del contenuto del file, a seconda delle impostazioni dei singoli amministratori.

Gli ambienti SharePoint in entrambi i data center possono accedere ai contenitori di archiviazione in entrambe le aree di Azure. Per motivi di prestazioni, il contenitore di archiviazione nello stesso data center locale è sempre preferibile, tuttavia, le richieste di lettura che non vedono i risultati all'interno di una soglia desiderata hanno lo stesso contenuto richiesto dal data center remoto per garantire che i dati siano sempre disponibili.

Resilienza dei metadati

I metadati di SharePoint sono inoltre fondamentali per accedere al contenuto utente in quanto archivia la posizione e le chiavi di accesso al contenuto archiviato in Archiviazione di Azure. Questi database vengono archiviati in Azure SQL, che ha un piano di continuità aziendale completo.

SharePoint usa il modello di replica fornito da SQL di Azure e ha creato una tecnologia di automazione proprietaria per determinare se è necessario un failover e per avviare l'operazione, se necessario. Di conseguenza, rientra nella categoria "Failover manuale del database" dal punto di vista di AZURE SQL. Le metriche più recenti per il ripristino del database SQL di Azure sono disponibili qui.

SharePoint usa il sistema di backup di Azure SQL per abilitare i ripristini temporizzato (PITR) per un massimo di 14 giorni.

Failover automatizzato

SharePoint usa un failover automatizzato personalizzato per ridurre al minimo l'impatto sull'esperienza del cliente quando si verifica un evento specifico della posizione. L'automazione guidata dal monitoraggio che rileva un errore singolo o multicomponente oltre determinate soglie comporta il reindirizzamento automatizzato dell'attività di tutti gli utenti all'esterno dell'ambiente problematico e verso un database secondario caldo. Un failover comporta la gestione completa dei metadati e dell'archiviazione di calcolo al di fuori del nuovo data center. Poiché l'archiviazione BLOB viene sempre eseguita interamente attiva/attiva, non è necessaria alcuna modifica per un failover. Il livello di calcolo preferisce il contenitore BLOB più vicino, ma usa sia i percorsi di archiviazione BLOB locali che remoti in qualsiasi momento per garantire la disponibilità.

SharePoint usa il servizio Frontdoor di Azure per fornire il routing interno alla rete Microsoft. Questa configurazione consente il reindirizzamento del failover indipendentemente da DNS e riduce l'effetto della memorizzazione nella cache del computer locale. La maggior parte delle operazioni di failover è trasparente per gli utenti finali. In caso di failover, i clienti non devono apportare modifiche per mantenere l'accesso al servizio.

Controllo delle versioni e ripristino dei file

Per le raccolte documenti appena create, SharePoint usa per impostazione predefinita 500 versioni in ogni file e può essere configurato per conservare altre versioni, se necessario. L'interfaccia utente non consente l'impostazione di un valore inferiore a 100 versioni, ma è possibile impostare il sistema per archiviare meno versioni usando API pubbliche. Per l'affidabilità, qualsiasi valore minore di 100 non è consigliato e può causare una perdita accidentale di dati da parte dell'utente.

Per altre informazioni sul controllo delle versioni, vedere Controllo delle versioni in SharePoint.

Ripristino file è la possibilità di tornare indietro nel tempo in qualsiasi raccolta documenti in SharePoint a un secondo di tempo negli ultimi 30 giorni. Questo processo può essere usato per recuperare da ransomware, eliminazioni di massa, danneggiamento o qualsiasi altro evento. Questa funzionalità usa le versioni di file in modo da ridurre le versioni predefinite può ridurre l'efficacia di questo ripristino.

La funzionalità Ripristino file è documentata sia per OneDrive che per SharePoint.

Eliminazione, backup e ripristino temporizzato

Il contenuto utente eliminato da SharePoint passa attraverso il flusso di eliminazione seguente.

Gli elementi eliminati vengono conservati nei Cestino per un determinato periodo di tempo. Per SharePoint, il tempo di conservazione è di 93 giorni. Inizia quando si elimina l'elemento dalla posizione originale. Quando si elimina l'elemento dal Cestino del sito, l'elemento viene inserito nel Cestino della raccolta siti. Rimane lì per il resto dei 93 giorni e quindi viene eliminato definitivamente. Per altre informazioni su come usare il Cestino, vedere i collegamenti seguenti:

• Ripristinare gli elementi nel Cestino
• Ripristinare gli elementi eliminati dal Cestino della raccolta siti.

Questo processo è il flusso di eliminazione predefinito e non tiene conto dei criteri o delle etichette di conservazione. Per altre informazioni, vedere Informazioni sulla conservazione per SharePoint e OneDrive.

Al termine della pipeline di riciclo di 93 giorni, l'eliminazione viene eseguita in modo indipendente per i metadati e per l'archiviazione BLOB. I metadati vengono rimossi immediatamente dal database, il che rende il contenuto illeggibile a meno che i metadati non vengano ripristinati dal backup. SharePoint mantiene 14 giorni di backup dei metadati. Questi backup vengono eseguiti localmente quasi in tempo reale e quindi sottoposti a push nell'archiviazione in contenitori ridondanti di Archiviazione di Azure in base alla documentazione al momento della pubblicazione, una pianificazione di 5-10 minuti.

Inoltre, i clienti hanno anche la possibilità di usare Backup di Microsoft 365 per il ripristino dei dati. Il backup di Microsoft 365 offre un tempo di protezione più lungo e offre un ripristino univoco e rapido da scenari comuni di continuità aziendale e ripristino di emergenza (BCDR) come ransomware o sovrascrittura/eliminazione di contenuti accidentali/dannosi dei dipendenti. Anche altre protezioni dello scenario BCDR sono integrate direttamente nel servizio, offrendo un livello avanzato di protezione dei dati.

Quando il contenuto dell'archiviazione BLOB viene eliminato, SharePoint usa la funzionalità di eliminazione temporanea per Archiviazione BLOB di Azure per proteggere dall'eliminazione accidentale o dannosa. Con questa funzionalità, ci sono un totale di 14 giorni in cui ripristinare il contenuto prima che venga eliminato definitivamente. Inoltre, poiché i BLOB non sono modificabili, Microsoft può sempre ripristinare lo stato di un file per un periodo di 14 giorni.

Nota

Mentre le applicazioni Microsoft invieranno contenuto al Cestino per il processo standard, SharePoint fornisce API che consentono di ignorare il Cestino e forzare un'eliminazione immediata. Esaminare le applicazioni per assicurarsi che questa operazione venga eseguita solo quando necessario per motivi di conformità.

Controlli di integrità

SharePoint usa vari metodi per garantire l'integrità dei BLOB e dei metadati in tutte le fasi del ciclo di vita dei dati:

• Hash file archiviato nei metadati: l'hash dell'intero file viene archiviato con i metadati del file per garantire che l'integrità dei dati a livello di documento venga mantenuta durante tutte le operazioni
• Hash BLOB archiviato nei metadati: ogni elemento BLOB archivia un hash del contenuto crittografato per proteggersi dal danneggiamento nell'archiviazione di Azure sottostante.
• Processo di integrità dei dati: ogni 14 giorni, ogni sito viene analizzato per l'integrità elencando gli elementi nel database e associandoli ai BLOB elencati nell'archiviazione di Azure. Il processo segnala eventuali riferimenti a BLOB mancanti di blob di archiviazione e può recuperare tali BLOB tramite la funzionalità di eliminazione temporanea dell'archiviazione di Azure , se necessario.