Pianificazione del backup e del ripristino in SharePoint Server

Articolo
03/08/2023

SI APPLICA A: yes-img-13 2013 yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

In genere, è consigliabile disporre di un piano di backup e ripristino prima di distribuire l'ambiente SharePoint Server. Il piano deve essere mantenuto e aggiornato man mano che SharePoint Server cambia per proteggere i dati.

Le fasi della pianificazione del backup e del ripristino prevedono l'individuazione delle strategie di backup e ripristino per un ambiente SharePoint Server e la scelta degli strumenti da utilizzare. Le diverse fasi non devono necessariamente essere eseguite nell'ordine in cui sono descritte e il processo può essere iterativo.

Quando si pianificano il backup e il ripristino per i casi di ripristino di emergenza, tenere conto di eventi, errori e problemi comuni nonché di emergenze ambientali e locali. Nelle sezioni di questo articolo vengono illustrate le fasi in cui occorre articolare il piano di backup e ripristino. Ogni fase rappresenta un passo verso l'obiettivo finale, ovvero ottenere un backup valido da usare per ripristinare la farm di SharePoint Server. È possibile personalizzare le fasi a seconda di specifiche esigenze. Tenere presente che il piano di backup e ripristino complessivo è dinamico e deve essere rispondente alle caratteristiche dell'ambiente SharePoint Server corrente.

Per ulteriori informazioni sul backup e il ripristino di SharePoint Server, vedere Panoramica del backup e del ripristino in SharePoint Server.

Definire i requisiti aziendali per farm e servizi di SharePoint

Per definire i requisiti aziendali, stabilire quanto segue per ogni farm e servizio dell'ambiente:

L'obiettivo in termini di punto di ripristino (RPO, Recovery Point Objective) è l'obiettivo relativo al periodo di tempo massimo che può trascorrere tra l'ultimo backup disponibile e qualsiasi punto di errore potenziale. Dipende dalla quantità di dati che l'azienda può permettersi di perdere in caso di errore.
L'obiettivo in termini di tempo di ripristino (RTO, Recovery Time Objective) è l'obiettivo relativo alla durata massima che un processo di ripristino dati può avere. Dipende da quanto tempo l'azienda può permettersi di restare con il sito o il servizio non disponibile.
Per obiettivo relativo al livello di ripristino (RLO, Recovery Level Objective) si intende l'obiettivo che definisce il livello di dettaglio con cui deve essere possibile ripristinare i dati, ad esempio l'intera farm, l'applicazione Web, la raccolta siti, il sito, l'elenco o la raccolta oppure l'elemento.

Più sono brevi l'obiettivo del punto di ripristino e l'obiettivo del tempo di ripristino e più è alto il livello di dettaglio dell'obiettivo del livello di ripristino, maggiore in genere sarà il costo per l'azienda.

Scegliere gli elementi da proteggere e ripristinare nell'ambiente SharePoint

I requisiti aziendali costituiranno un utile riferimento per scegliere i componenti dell'ambiente da proteggere e il livello di dettaglio con cui poterli ripristinare.

Nelle tabelle seguenti sono riportati i componenti di un ambiente di SharePoint che è possibile scegliere di proteggere e gli strumenti che è possibile utilizzare per eseguire il backup e il ripristino di ogni componente. Come si noterà, le tabelle sono simili, ma vengono visualizzati componenti di backup specifici per ogni edizione di SharePoint Server.

Componenti di SharePoint Server 2016 per backup e ripristino

Componente	Backup di SharePoint	SQL Server 2014 Service Pack 1 (SP1)	SQL Server 2016	System Center 2016 - Aggiornamento cumulativo 2 per Data Protection Manager	Backup del file system
Farm	Sì			Sì (6)
Applicazioni di servizio	Sì
Applicazione Web	Sì
Database del contenuto	Sì	Sì	Sì	Sì
Raccolta siti	Sì (1, 2)	Sì (1, 2)	Sì (1, 2)	Sì (1, 2)
Sito	Sì (2)	Sì (2)	Sì (2)	Sì
Raccolta o elenco documenti	Sì (2)	Sì (2)	Sì (2)	Sì
Elemento di elenco o documento				Sì
Contenuto archiviato in archivi BLOB remoti	Sì (3)	Sì (3)	Sì (3)	Sì (3)
Personalizzazioni distribuite come pacchetti delle soluzioni	Sì (7)	Sì (7)	Sì (7)	Sì (6, 7)
Modifiche di Web.config apportate tramite Amministrazione centrale o un'API	Sì	Sì	Sì	Sì (4)
Impostazioni di configurazione di SharePoint	Sì (2, 8)	Sì (2, 8)	Sì (2, 8)	Sì (2, 9)
Personalizzazioni non distribuite come pacchetti delle soluzioni				Sì, i file possono essere ripristinati se protetti come file. (4, 5)	Sì
Modifiche di Web.config non apportate mediante Amministrazione centrale o un'API				Sì (4)	Sì
Configurazioni di IIS non impostate tramite SharePoint Server 2016				Sì (5)	Sì
Database di SQL Server Reporting Services		Sì	Sì	Sì

(1) È possibile utilizzare il backup e il ripristino a livello di farm e di database per ripristinare le raccolte siti se in un database è archiviata una sola raccolta siti.

(2) È possibile utilizzare i backup a livello di farm e di database con il ripristino senza collegamento dei database di SharePoint Server 2016 per ripristinare raccolte siti, siti, elenchi e configurazioni.

(3) Il contenuto presente negli archivi di BLOB remoti non può essere ripristinato tramite System Center Data Protection Manager.

(4) È possibile eseguire il backup delle modifiche apportate a Web.config utilizzando il backup del file system da DPM.

(5) Le configurazioni di IIS possono essere ripristinate mediante un backup bare metal da DPM.

(6) DPM può ripristinare questo elemento utilizzando una combinazione di backup bare metal e backup di SharePoint Server 2016. Non è possibile eseguirne il backup e il ripristino come oggetto.

(7) I pacchetti di soluzioni completamente attendibili sono memorizzati nel database di configurazione e le soluzioni in modalità sandbox sono memorizzate nei database del contenuto. Possono essere ripristinate insieme alla farm o con il ripristino dei database del contenuto.

(8) Le impostazioni di configurazione possono essere ripristinate da backup a livello di farm. Per ulteriori informazioni, vedere Ripristinare le farm in SharePoint Server.

(9) È possibile ripristinare il database del contenuto di Amministrazione centrale e il database di configurazione per una farm di SharePoint Server 2016 solo nell'ambito di un ripristino completo della farm nella stessa farm e con gli stessi computer.

Per ulteriori informazioni, vedere Announcement: Protect your Server 2016 workloads with Enhanced Security (Annuncio: protezione avanzata dei carichi di lavoro Server 2016.

Componenti di SharePoint 2013 per backup e ripristino

Componente	Backup di SharePoint	SQL Server 2008 con Service Pack 1 (SP1) e aggiornamento cumulativo 2	SQL Server 2012	System Center 2012 - Data Protection Manager (DPM)	Backup del file system
Farm	Sì			Sì (6)
Applicazioni di servizio	Sì
Applicazione Web	Sì
Database del contenuto	Sì	Sì	Sì	Sì
Raccolta siti	Sì (1, 2)	Sì (1, 2)	Sì (1, 2)	Sì (1, 2)
Sito	Sì (2)	Sì (2)	Sì (2)	Sì
Raccolta o elenco documenti	Sì (2)	Sì (2)	Sì (2)	Sì
Elemento di elenco o documento				Sì
Contenuto archiviato in archivi BLOB remoti	Sì (3)	Sì (3)	Sì (3)	Sì (3)
Personalizzazioni distribuite come pacchetti delle soluzioni	Sì (7)	Sì (7)	Sì (7)	Sì (6, 7)
Modifiche di Web.config apportate tramite Amministrazione centrale o un'API	Sì	Sì	Sì	Sì (4)
Impostazioni di configurazione di SharePoint	Sì (2, 8)	Sì (2, 8)	Sì (2, 8)	Sì (2, 9)
Personalizzazioni non distribuite come pacchetti delle soluzioni				Sì, i file possono essere ripristinati se protetti come file. (4, 5)	Sì
Modifiche di Web.config non apportate mediante Amministrazione centrale o un'API				Sì (4)	Sì
Configurazioni di IIS non impostate tramite SharePoint 2013				Sì (5)	Sì
Database di SQL Server Reporting Services		Sì	Sì	Sì

(1) È possibile utilizzare il backup e il ripristino a livello di farm e di database per ripristinare le raccolte siti se in un database è archiviata una sola raccolta siti.

(2) È possibile utilizzare i backup a livello di farm e di database con il ripristino senza collegamento dei database di SharePoint 2013 per ripristinare raccolte siti, siti, elenchi e configurazioni.

(3) Il contenuto presente negli archivi di BLOB remoti non può essere ripristinato tramite System Center Data Protection Manager.

(4) È possibile eseguire il backup delle modifiche apportate a Web.config utilizzando il backup del file system da DPM.

(5) Le configurazioni di IIS possono essere ripristinate mediante un backup bare metal da DPM.

(6) DPM può ripristinare questo elemento utilizzando una combinazione di backup bare metal e backup di SharePoint 2013. Non è possibile eseguirne il backup e il ripristino come oggetto.

(8) Le impostazioni di configurazione possono essere ripristinate da backup a livello di farm. Per ulteriori informazioni, vedere Ripristinare le farm in SharePoint Server.

(9) È possibile ripristinare il database del contenuto di Amministrazione centrale e il database di configurazione per una farm di SharePoint 2013 solo nell'ambito di un ripristino completo della farm nella stessa farm e con gli stessi computer.

Nota

È possibile registrare SharePoint 2013 con Windows Server Backup usando l'operazione stsadm.exe -o -registerwsswriter per configurare il writer del servizio Copia Shadow del volume per SharePoint 2013. Windows Server Backup include quindi SharePoint 2013 nei backup a livello di server. Quando si esegue il ripristino da un backup di Windows Server, è possibile selezionare SharePoint Foundation (indipendentemente dalla versione di SharePoint 2013 installata) e tutti i componenti segnalati dal writer VSS per SharePoint 2013 in tale server al momento del backup verranno ripristinati. > Windows Server Backup è consigliato solo per l'uso con per distribuzioni a server singolo.

Scegliere gli elementi da ripristinare da database del contenuto di SharePoint

Da un database del contenuto è possibile ripristinare raccolte siti, siti, elenchi e raccolte.

Gli strumenti di backup e ripristino offrono diversi livelli di ripristino per i database del contenuto. Il ripristino di un oggetto da un database del contenuto è sempre più complesso del ripristino dell'intero database del contenuto.

Protezione delle personalizzazioni

Le personalizzazioni dei siti di SharePoint possono includere quanto segue:

Pagine master, layout di pagina e fogli di stile CSS. Questi oggetti vengono archiviati nel database del contenuto per un'applicazione Web.
Web part, definizioni di sito o elenco, colonne personalizzate, nuovi tipi di contenuto, campi personalizzati, azioni personalizzate, flussi di lavoro codificati o condizioni e attività del flusso di lavoro.
Soluzioni di terze parti e relativi file binari associati e chiavi del Registro di sistema, ad esempio IFilter.
Modifiche apportate ai file XML standard.
Definizioni di sito personalizzate (Webtemp.xml).
Modifiche apportate al file Web.config.

Le modalità di distribuzione delle personalizzazioni e di esecuzione delle modifiche relative al file Web.config influiscono in maniera significativa sugli strumenti che è possibile utilizzare per effettuare il backup e il ripristino delle personalizzazioni. Per garantire le massime opportunità di ripristino, è consigliabile usare pacchetti delle soluzioni per distribuire le personalizzazioni e Amministrazione centrale oppure il modello a oggetti e le API di SharePoint per configurare il file Web.config.

Protezione dei flussi di lavoro

I flussi di lavoro costituiscono un caso speciale di personalizzazioni di cui è possibile eseguire il backup e il ripristino. Verificare che nel proprio piano di backup e ripristino siano presi in considerazione gli scenari seguenti in base all'ambiente:

I flussi di lavoro dichiarativi, come quelli creati in SharePoint Designer, vengono archiviati nel database del contenuto per la raccolta siti in cui vengono distribuiti. Il backup del database del contenuto consente di proteggere tali flussi di lavoro.
Le azioni personalizzate dei flussi di lavoro dichiarativi hanno componenti nelle tre posizioni seguenti:
- Gli assembly di Visual Studio per le attività sono archiviati nella Global Assembly Cache (GAC).
- File di definizione XML (. ACTIONS) vengono archiviati nella directory 15\TEMPLATE{LCID}\Workflow.
- Una voce XML per contrassegnare l'attività come tipo autorizzato è archiviata nel file Web.config per le applicazioni Web nelle quali viene utilizzata.
  
  Se nei flussi di lavoro della farm vengono utilizzate azioni personalizzate, è consigliabile utilizzare un sistema di backup dei file per proteggere tali file e voci XML. In modo analogo alle caratteristiche di SharePoint Server, ad esempio Web part e ricevitori di eventi, dopo il ripristino tali file dovranno essere applicati di nuovo alla farm, secondo le esigenze.
I flussi di lavoro che dipendono da codice personalizzato, ad esempio quelli creati tramite Visual Studio, sono archiviati in due percorsi. Gli assembly di Visual Studio per il flusso di lavoro sono archiviati nella Global Assembly Cache (GAC), mentre i file di definizione XML sono archiviati nella directory Features. Si tratta della stessa posizione utilizzata per altre caratteristiche di SharePoint Server, ad esempio Web part e ricevitori di eventi. Se il flusso di lavoro è stato installato come parte di un pacchetto della soluzione, il backup del database del contenuto consentirà di proteggere tali flussi di lavoro.
Se si crea un flusso di lavoro personalizzato che interagisce con una raccolta siti diversa da quella in cui è stato distribuito il flusso di lavoro, sarà necessario eseguire il backup di entrambe le raccolte per proteggere il flusso di lavoro. Sono inclusi i flussi di lavoro che prevedono la scrittura in un elenco della cronologia o in un altro elenco personalizzato di un'altra raccolta siti. L'esecuzione di un backup della farm è sufficiente per ottenere il backup di tutte le raccolte siti della farm e di tutti i flussi di lavoro ad esse associati. Per ulteriori informazioni, vedere "Eseguire il backup dei flussi di lavoro di SharePoint" in Eseguire il backup delle personalizzazioni in SharePoint Server.
Per i flussi di lavoro non ancora distribuiti è necessario eseguire il backup e il ripristino separatamente come qualsiasi altro file di dati. Quando si sviluppa un nuovo flusso di lavoro che non è ancora stato distribuito nella farm di SharePoint Server, accertarsi di includere nel backup la cartella nella quale vengono archiviati i file di progetto del flusso di lavoro utilizzando Windows Server Backup o un'altra applicazione di backup del file system.

Protezione delle applicazioni di servizio

Le applicazioni di servizio presenti in un ambiente SharePoint Server possono essere costituite da impostazioni di servizi e da uno o più database oppure unicamente da impostazioni di servizi. Non è possibile ripristinare un'applicazione di servizio completa ripristinando il solo database. È tuttavia possibile ripristinare i database di un'applicazione di servizio e quindi eseguire il provisioning dell'applicazione di servizio. Per ulteriori informazioni, vedere Ripristinare applicazioni di servizio in SharePoint Server.

Protezione dei database di SQL Server Reporting Services

Il backup e il ripristino di SharePoint Server non includono i database di SQL Server Reporting Services. È necessario utilizzare gli strumenti di SQL Server per SharePoint Server. Per ulteriori informazioni, vedere Operazioni di backup e ripristino per Reporting Services.

Scegliere gli strumenti di backup e ripristino di SharePoint

Per scegliere gli strumenti appropriati per il backup e il ripristino, è necessario stabilire se si è in grado di soddisfare i requisiti di continuità definiti per l'azienda nel budget per tempi e risorse.

Tra i fattori chiave da considerare per la scelta degli strumenti è incluso quanto segue:

Velocità di backup: lo strumento può essere eseguito all'interno della finestra di manutenzione per i database? È consigliabile testare qualsiasi sistema di backup per assicurarsi che soddisfi le proprie esigenze nell'hardware.
Completezza del ripristino.
Granularità degli oggetti che è possibile ripristinare.
Tipo di backup supportato, ovvero completo, differenziale o incrementale.
Difficoltà di gestione dello strumento.

Per informazioni dettagliate sui sistemi di backup e ripristino utilizzabili con SharePoint Server, vedere le risorse seguenti:

Determinare le strategie di backup e ripristino di SharePoint

In base ai requisiti aziendali, alle esigenze di ripristino e agli strumenti scelti, determinare e documentare le strategie di backup e ripristino per l'ambiente.

È usuale che i reparti IT che supportano ambienti SharePoint Server decidano di utilizzare più di uno strumento per proteggere l'ambiente quando determinano le strategie da adottare.

In un ambiente con database gestiti dai relativi amministratori potrebbero ad esempio essere utilizzate le strategie incluse nell'elenco seguente:

Il backup di tutti i database viene eseguito tramite SQL Server per SharePoint Server. L'intervallo di backup impostato si basa su quanto segue:
- L'importanza del contenuto o del servizio.
- L'effetto del backup sull'ambiente in termini di prestazioni.
I database del contenuto di piccole dimensioni, soggetti a molte modifiche e con un forte impatto sull'attività aziendale vengono ulteriormente protetti con snapshot di database di SQL Server che vengono archiviati in un disco fisico distinto. Viene archiviato un solo snapshot per database e gli snapshot vengono eliminati con regolarità, in modo da ridurre al minimo gli effetti sulle prestazioni. L'intervallo tra gli snapshot viene impostato per ogni database in base ai fattori seguenti:
- L'importanza del contenuto o del servizio.
- La frequenza di modifica standard per il database.
- L'effetto dello snapshot sull'ambiente in termini di prestazioni.
- La quantità di spazio necessario per archiviare lo snapshot.
  
  Il ripristino da uno snapshot è più veloce rispetto al ripristino standard, perché uno snapshot e il database sottostante possono essere gestiti da SharePoint Server come un database non collegato. La creazione degli snapshot tuttavia può ridurre le prestazioni del database sottostante. È consigliabile verificare l'effetto degli snapshot sulle prestazioni del sistema prima di implementare gli snapshot ed eliminare con regolarità gli snapshot per ridurre lo spazio occupato.
  
  Nota
  
  [!NOTA] Se si utilizza Archiviazione BLOB remoti e il provider di Archiviazione BLOB remoti utilizzato non supporta gli snapshot, non sarà possibile utilizzarli per il backup. Il provider FILESTREAM ad esempio non supporta gli snapshot.
Per proteggere le applicazioni di servizio si utilizza il backup di SharePoint Server. L'intervallo di backup viene definito in base agli elementi seguenti:
- L'importanza del servizio.
- La frequenza di modifica standard per il database.
- L'effetto del backup sul database in termini di prestazioni.
Tutte le operazioni di ripristino vengono eseguite tramite SharePoint Server. La scelta del sistema di ripristino da utilizzare dipende dal tipo di backup disponibile e dall'oggetto da ripristinare.

È consigliabile includere altri strumenti nella strategia di continuità aziendale. Considerare con quali modalità verranno utilizzati i cestini e il controllo delle versioni nelle raccolte siti dell'ambiente. Per ulteriori informazioni, vedere Pianificare il ripristino di emergenza e la disponibilità elevata per SharePoint Server.

Pianificare le prestazioni durante la progettazione della strategia di backup e ripristino di SharePoint

Mentre si pianifica la strategia di backup e ripristino, tenere presenti i suggerimenti riportati di seguito per ridurre gli effetti del backup e del ripristino sulle prestazioni del sistema.

Come da progettazione, la maggior parte dei processi di backup utilizza quante più risorse I/O è possibile per completare l'elaborazione nell'intervallo di tempo disponibile per la manutenzione. Si potrebbero pertanto verificare accodamenti sul disco e le richieste I/O potrebbero venire soddisfatte più lentamente del solito. Questa situazione è normale e non deve essere considerata un problema.

Seguire i suggerimenti per la configurazione di SQL Server e dell'archiviazione

Seguire i suggerimenti di carattere generale per configurare SQL Server e l'archiviazione per un ambiente SharePoint Server. Per ulteriori informazioni, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server).

Ridurre al minimo la latenza tra SQL Server e il percorso di backup

In linea generale, per i backup utilizzare un disco locale, anziché un'unità di rete. Se si intende eseguire il backup di più server, è possibile decidere di utilizzare un computer connesso direttamente in cui entrambi i server possano scrivere. Le unità di rete con una latenza massima di 1 millisecondo tra esse e i computer in cui viene eseguito SQL Server. Se nella farm sono inclusi più server, compreso quello in cui viene eseguito SQL Server, sarà necessario utilizzare percorsi di rete UNC come percorso di backup della farm di SharePoint.

Evitare conflitti di elaborazione

Non eseguire processi di backup in orari in cui gli utenti devono accedere al sistema.

Per evitare colli di bottiglia a livello di I/O, eseguire prima il backup principale in un disco separato e quindi effettuare la copia su nastro.

Valutare la possibilità di scaglionare i backup, per evitare di eseguire il backup di tutti i database contemporaneamente.

I backup di SharePoint Server utilizzano i backup di SQL Server. Quando si utilizza la compressione con i backup, fare attenzione a non sovraccaricare SQL Server. Ad esempio, alcuni strumenti di terze parti comprimono i dati durante l'esecuzione del backup e ciò può incidere negativamente sulle prestazioni di SQL Server. Sono disponibili strumenti che consentono di limitare i processi di compressione e di controllarne l'effetto su SQL Server.

Seguire le raccomandazioni per l'ottimizzazione di backup e ripristino di SQL Server

Se si esegue SQL Server Enterprise, è consigliabile utilizzare la compressione del backup. Per ulteriori informazioni, vedere Compressione backup (SQL Server).

Se si utilizzano i backup di SQL Server o SQL Server 2008 R2 Express, per ridurre al minimo i tempi di ripristino, adottare una combinazione di backup completi, differenziali e del log delle transazioni per il modello di recupero con registrazione completa. I backup di database differenziali in genere vengono creati più rapidamente rispetto ai backup di database completi e richiedono una minore attività di registrazione delle transazioni per il ripristino del database.

Se si adotta il modello di recupero con registrazione completa in SQL Server 2008, è consigliabile utilizzare l'opzione truncate durante il backup per evitare problemi di manutenzione.

Per istruzioni dettagliate su come ottimizzare le prestazioni di backup e ripristino di SQL Server, vedere Ottimizzazione delle prestazioni di backup e ripristino in SQL Server.

Assicurare sufficienti prestazioni in scrittura nell'unità di backup

Valutare attentamente se utilizzare RAID (Redundant Array of Independent Disks) nel dispositivo di backup del disco. RAID 5 ad esempio offre prestazioni limitate in scrittura, garantendo approssimativamente la stessa velocità di un singolo disco. Questo avviene perché RAID 5 mantiene le informazioni sulla parità. L'uso di RAID 10 per un dispositivo di backup può offrire backup più veloci. Per altre informazioni su come usare RAID con i backup, vedere Configurare RAID per la velocità effettiva massima di I/O SQL Server.