Pianificare il backup e il ripristino in SharePoint Server 2010

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo vengono illustrate le fasi della pianificazione del backup e del ripristino, tra cui la fase di individuazione delle strategie di backup e ripristino per un ambiente Microsoft SharePoint Server e la fase di 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 pianifica il modo in cui il backup e il ripristino verranno utilizzati per il ripristino di emergenza, è consigliabile prevedere eventi, errori e problemi comuni, emergenze locali ed emergenze regionali.

Per informazioni dettagliate sul backup e il ripristino di Microsoft SharePoint Server, vedere Panoramica del backup e del ripristino (SharePoint Server 2010).

Contenuto dell'articolo:

• Definire i requisiti aziendali per farm e servizi di SharePoint

• Scegliere gli elementi da proteggere e ripristinare nell'ambiente SharePoint

• Scegliere gli strumenti di backup e ripristino di SharePoint

• Determinare le strategie di backup e ripristino di SharePoint

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

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.

È disponibile un foglio di lavoro utile per pianificare le strategie di backup e ripristino per l'ambiente SharePoint Server 2010, scaricabile dalla pagina Cartella di lavoro per la pianificazione del backup e del ripristino dei prodotti SharePoint 2010 (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=184385&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

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.

Nella tabella seguente 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.

1È possibile utilizzare il backup e il ripristino a livello di farm e di database per ripristinare una raccolta 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 di database non collegati di SharePoint Server per ripristinare raccolte siti, siti, elenchi e configurazioni.

3Il contenuto archiviato negli archivi BLOB remoti non può essere ripristinato tramite DPM.

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

5Le configurazioni di IIS possono essere ripristinate utilizzando un backup bare metal da DPM 2010.

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

7I 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.

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

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

Scegliere gli elementi da ripristinare dai 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 il contenuto di un 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 file binari associati, nonché chiavi del Registro di sistema, ad esempio IFilters.

• 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 distribuire le personalizzazioni utilizzando pacchetti delle soluzioni e configurare il file Web.config utilizzando Amministrazione centrale oppure il modello a oggetti e le API di SharePoint.

Protezione dei flussi di lavoro

I flussi di lavoro sono un caso speciale di personalizzazioni di cui è possibile effettuare il backup e il ripristino. Verificare che nel piano di backup e ripristino sia incluso uno degli scenari seguenti, a seconda dell'ambiente applicabile:

• I flussi di lavoro dichiarativi, come quelli creati in Microsoft SharePoint Designer 2010, 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.

• Per le azioni dei flussi di lavoro dichiarativi personalizzati sono presenti componenti nei tre percorsi seguenti:

  1. Gli assembly di Visual Studio per le attività sono archiviati nella Global Assembly Cache (GAC).

  2. I file di definizione XML (file con estensione ACTIONS) sono archiviati nella directory 14\TEMPLATE\{LCID}\Workflow.

  3. 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 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 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 Restore a service application in SharePoint 2010 Products.

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 ulteriori informazioni, vedere Operazioni di backup e ripristino per un'installazione di Reporting Services (https://go.microsoft.com/fwlink/?linkid=186642&clcid=0x410).

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, ovvero la capacità dello strumento di eseguire il backup entro la finestra di manutenzione prevista per i database.

• Completezza del ripristino.

• Granularità degli oggetti che è possibile ripristinare.

• Tipo di backup supportato, ovvero completo, differenziale o incrementale.

• Difficoltà di gestione dello strumento.

Nella tabella seguente vengono messi a confronto il tipo di backup e la dimensione della farm di cui è possibile eseguire il backup in una finestra di sei ore per i diversi strumenti di backup e ripristino offerti da Microsoft.

1La dimensione di backup è stata determinata eseguendo il backup di un sistema che in totale raggiunge la dimensione specificata per i componenti hardware di testing riportati nella sezione seguente.

Hardware di testing

Nella tabella seguente sono riportati i componenti hardware utilizzati nei test per determinare la dimensione di backup che è stato possibile completare in una finestra di sei ore.

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

• Panoramica del backup e del ripristino (SharePoint Server 2010)

• Backup e ripristino di database in SQL Server (https://go.microsoft.com/fwlink/?linkid=186643&clcid=0x410)

• Panoramica di Data Protection Manager 2010 (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=186655&clcid=0x410) (le informazioni potrebbero essere in lingua inglese)

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. L'intervallo di backup viene impostato in base agli elementi seguenti:

  • 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

  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. Tenere in considerazione la modalità di utilizzo dei Cestini e del controllo delle versioni nelle raccolte siti dell'ambiente. Per ulteriori informazioni, vedere Pianificare la gestione della continuità aziendale (SharePoint Server 2010).

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 2010).

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

In linea generale, per i backup è preferibile 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 garantiscono buone prestazioni. 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 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.

Per i backup di SharePoint Server vengono utilizzati i backup di SQL Server. Quando si utilizza la compressione con i backup, fare attenzione a non sovraccaricare SQL Server. Alcuni strumenti di backup di terze parti, ad esempio, comprimono i dati durante l'esecuzione del backup e tale attività può incidere negativamente sulle prestazioni di SQL Server. Sono disponibili strumenti che consentono di limitare i processi di compressione e di controllare l'effetto su SQL Server.

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

Se si esegue SQL Server 2008 Enterprise, è consigliabile utilizzare la compressione del backup. Per ulteriori informazioni, vedere Compressione del backup (SQL Server) (https://go.microsoft.com/fwlink/?linkid=179525&clcid=0x410).

Se si utilizzano i backup di SQL Server, per ridurre al minimo i tempi di ripristino, adottare una combinazione di backup completi, differenziali e del registro 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 informazioni dettagliate su come ottimizzare le prestazioni di backup e ripristino di SQL Server, vedere Ottimizzazione delle prestazioni di backup e ripristino in SQL Server (https://go.microsoft.com/fwlink/?linkid=126630&clcid=0x410).

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. Ciò è dovuto al fatto che RAID 5 mantiene le informazioni di parità. L'utilizzo di RAID 10 per un dispositivo di backup può consentire backup più rapidi. Per ulteriori informazioni su come utilizzare RAID con i backup, vedere Configurare RAID per la massima velocità effettiva di I/O per SQL Server (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=126632&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Contenuto correlato

See Also

Other Resources

Centro Risorse - Struttura dell'architettura per SharePoint Server 2010 (le informazioni potrebbero essere in lingua inglese)