Configurare il log shipping in SharePoint Server

SI APPLICA A:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

Con il log shipping, si esegue il backup dei log delle transazioni da un database primario a un database secondario in un'istanza separata di SQL Server. Nello scenario descritto in questo documento il log shipping di SQL Server viene usato insieme al servizio Replica DFS (Distributed File System) per copiare i database e i log delle transazioni nella farm di ripristino in Microsoft Azure come illustrato in questo documento.

In questo scenario di ripristino di emergenza la farm di produzione di SharePoint Server è contenuta in locale, mentre la farm di ripristino è contenuta in Azure. È anche possibile adattare le istruzioni contenute in questo documento per altri tipi di scenari di ripristino di emergenza.

Elementi di una soluzione con warm standby in Azure

Elementi di una soluzione con warm standby in Azure

Nella figura:

  • Sono illustrati due ambienti affiancati: la farm di SharePoint locale e la farm di ripristino (standby) in Azure.

  • Ogni ambiente include una condivisione di file.

  • Il log shipping viene usato per copiare i log dal server di database secondario dell'ambiente locale nella condivisione di file locale.

  • Replica DFS copia i file dalla condivisione di file dell'ambiente locale nella condivisione di file dell'ambiente Azure. In uno scenario WAN è più efficiente usare Replica DFS anziché inviare i log direttamente nel server secondario in Azure.

  • Il log shipping riproduce i log dalla condivisione file nell'ambiente Azure alla replica primaria nel gruppo di disponibilità Always On di SQL Server nell'ambiente di ripristino.

  • I database con log shipping vengono collegati alla farm di SharePoint Server solo dopo l'esecuzione di un ripristino.

Il seguente diagramma mostra le sette fasi previste dalla soluzione completa del ripristino di emergenza di SharePoint Server in Azure. La "Fase 6: configurare il log shipping nella farm di ripristino" evidenziata nel diagramma è descritta nelle sezioni seguenti.

Guida di orientamento alla soluzione per il ripristino di emergenza

Uso del log shipping per il ripristino di emergenza

Il log shipping permette di inviare automaticamente file di log delle transazioni per i database da un'istanza di server di database primario a un'istanza di server di database secondario. Nell'ambiente di test locale vengono usati gruppi di disponibilità Always On con due repliche per la disponibilità elevata. Il log shipping è stato configurato in entrambe le repliche. Ogni replica deve essere in grado di inviare log delle transazioni. Solo la replica attiva e proprietaria del database può inviare i log. Se però si verifica un evento di failover e diventa attiva la replica secondaria, sarà questa a inviare i log delle transazioni anziché la replica in cui si è verificato l'errore.

Dopo essere stati ricevuti nell'ambiente Azure, i log delle transazioni vengono ripristinati uno per volta in ciascun database di SharePoint nel server di database secondario. Per altre informazioni sull'ambiente di testing, vedere l'ambiente del modello di prova Microsoft.

Nota

[!NOTA] Alcune organizzazioni usano un terzo server di database come server di monitoraggio per registrare la cronologia e lo stato delle operazioni di backup e ripristino. Questo server di monitoraggio facoltativo crea avvisi quando si verificano errori delle operazioni di backup.

Per informazioni dettagliate sul log shipping, fare riferimento agli articoli elencati nella seguente tabella.

Tabella: articoli di riferimento per il log shipping

URL Descrizione
Informazioni sul log shipping (SQL Server)
Descrive i backup dei log delle transazioni del log shipping e le opzioni disponibili.
Configurazione del log shipping (SQL Server)
Descrive come configurare il log shipping in SQL Server 2012 usando SQL Server Management Studio o Transact-SQL.
Visualizzare il report di log shipping (SQL Server Management Studio)
Spiega come visualizzare il report Stato log shipping delle transazioni in SQL Server Management Studio. È possibile eseguire un report sullo stato in un server di monitoraggio, in un server primario o in un server secondario.

Considerazioni sulle prestazioni

Il log shipping è costituito da tre processi. Ogni processo esegue una delle operazioni seguenti:

  1. Esegue il backup del log delle transazioni nell'istanza del server primario.

  2. Copia il file di log delle transazioni nell'istanza del server secondario.

  3. Ripristina il backup dei log nell'istanza del server secondario.

Ogni processo funziona in base a una pianificazione e viene eseguito per un intervallo di tempo. Questo può avere un impatto significativo sul server di database e, per impostazione predefinita, sulle prestazioni della farm di SharePoint.

Per impostare correttamente gli intervalli del processo di backup, copia e ripristino per il log shipping, è necessario analizzare la quantità di dati inviati dal log. La quantità di dati di log spediti è influenzata dalla quantità giornaliera di modifiche nei database del contenuto. La percentuale di modifiche può variare notevolmente a seconda del contenuto, delle modifiche di manutenzione e dei picchi di utilizzo.

Per ottenere una percentuale di modifiche accurata, calcolare la somma delle modifiche nei backup dei log delle transazioni per ogni database del contenuto per cui viene eseguito il log shipping in un determinato intervallo di tempo. Usare questi dati per calcolare la percentuale di modifiche rispetto al database primario.

Le seguenti indicazioni derivano dall'esperienza di log shipping maturata sul campo da personale Microsoft con diverse versioni di SharePoint Server.

  • Evitare una riduzione delle prestazioni dovuta all'avvio contemporaneo di tutti i processi, facendo in modo di distanziare di almeno un minuto ogni processo di log shipping dal processo precedente.

  • È consigliabile eseguire il backup e la copia di più log delle transazioni di piccole dimensioni anziché di un numero inferiore di log delle transazioni più estesi.

  • Pianificare i backup e la copia dei log con intervalli di tempo frequenti. È possibile ripristinare i log delle transazioni a intervalli meno frequenti. Iniziare ad esempio usando intervalli di backup e copia di cinque minuti e un intervallo di ripristino di 15 minuti.

Prerequisiti per la configurazione del log shipping

Verificare che vengano soddisfatti i seguenti prerequisiti per l'uso del log shipping per la soluzione di ripristino di emergenza.

  • Gli accessi di SQL Server sono account di dominio che hanno i livelli di autorizzazione necessari per il log shipping. Le stored procedure di log shipping richiedono l'appartenenza al ruolo predefinito del server sysadmin.

  • Il database primario deve usare il modello di recupero con registrazione completa o con registrazione minima delle operazioni bulk.

    Attenzione

    Se per il database viene impostato il recupero con registrazione minima, il log shipping smette di funzionare.

  • Prima di configurare il log shipping, è necessario creare una condivisione in modo che i backup dei log delle transazioni siano disponibili nel server secondario. Questa è una condivisione della directory in cui vengono generati i backup dei log delle transazioni.

Oltre agli obiettivi in termini di punto di ripristino (RPO, Recovery Point Objective), verificare che i dati della farm ripristinati siano il più completi e integri possibile. Per raggiungere questi risultati, è necessario pianificare attentamente ogni aspetto del log shipping.

Infrastruttura di log shipping

L'infrastruttura di log shipping usata per l'ambiente della soluzione di ripristino di emergenza è illustrata nel seguente diagramma.

Infrastruttura di log shipping e flusso di dati

Infrastruttura di log shipping e flusso direzionale tra le farm locali e di Azure.

Il diagramma precedente mostra l'infrastruttura di log shipping e il flusso di dati. Vengono illustrati i server di database di SQL Server e i file server della farm di produzione e della farm di ripristino di Azure. Queste farm sono quasi identiche e ognuna contiene una replica primaria e secondaria per ogni gruppo di disponibilità Always On. I file server FIL1 e AZ-FIL1 sono configurati nello stesso modo, inclusi il numero di dischi rigidi e le dimensioni dei dischi. Non sono visibili server aggiuntivi della farm.

Per garantire la disponibilità elevata, ogni replica di un gruppo di disponibilità archivia un backup (completo, differenziale e log delle transazioni) dell'altra replica.

Le repliche primarie e secondarie (rispettivamente SQL-HA1 e SQL-HA2) creano backup archiviati nel relativo partner nel gruppo di disponibilità.

Il log shipping delle transazioni è configurato nella replica secondaria per ridurre al minimo l'impatto dei backup sui database di produzione. Questi log delle transazioni vengono scritti in una cartella condivisa nel file server locale (FIL1). Il servizio Replica DFS (Distributed File System) di Windows Server copia i log delle transazioni da FIL1 ad AZ-FIL1. I log delle transazioni di AZ-FIL1 vengono ripristinati in AZ-SQL-HA1, la replica primaria del gruppo di disponibilità nella farm di ripristino.

Passaggi necessari per configurare e convalidare il log shipping

I passaggi necessari per configurare, eseguire e convalidare il log shipping sono condensati e riepilogati nel seguente elenco:

  1. Eseguire il backup del database.

  2. Configurare i backup completi e differenziali in una cartella locale e anche in una cartella condivisa nel file server.

  3. Verificare che i backup siano stati effettuati sia nella cartella locale sia nella cartella condivisa.

  4. Configurare e testare il servizio Replica DFS (Distributed File System).

  5. Creare lo spazio dei nomi e la replica per trasferire i log delle transazioni e i file di backup tra le farm locale e di Azure nella cartella condivisa nel file server.

  6. Verificare tutti i trasferimenti dopo le esecuzioni del log shipping.

  7. Configurare e testare il log shipping.

  8. Configurare il log shipping nel server di database primario usando il seguente script: Primary-Logshippingsetupparameter. Questo script crea processi di backup, li pianifica per il log shipping e quindi li avvia.

SET NOCOUNT ON
USE MSDB
GO
--@PrimServer : Primary Server name
--@SecServer  : DR/Secondary Server Name
--@SecInstance : DR/Secondary FQDN
--@Domain  : Domain Name
--@BkpDrive : Production Backup server Name
--@DBName : DatabaseName
DECLARE @LS_BackupJobIdAS uniqueidentifier,  @LS_PrimaryIdAS uniqueidentifier , @SP_Add_RetCode As int 
DECLARE @Time as nvarchar(10),@SecInstance as nvarchar(250), @PrimServer as nvarchar(50),@SecServer as nvarchar(50),
@Domain as nvarchar(50),@DBName as nvarchar(max),@BkpDrive as nvarchar(250),@CMD as nvarchar(max),@Counter int
----------------------------------------------------------------------------
IF OBJECT_ID ('tempdb.DBO.#LogShipping','U') IS NOT NULL DROP TABLE #LogShipping
Create table #LogShipping ( LSDBs nvarchar(max))
Set @PrimServer ='SQL1'
Set @SecServer ='SQL2'
Set @SecInstance ='SQL2.corp.adventureworks.com'
Set @Domain ='corp.adventureworks.com'
Set @BkpDrive ='FS1.corp.adventureworks.com'
Set @DBName = 'Social_DB'
Set @Time = '0130'
SET @DBName = UPPER(REPLACE(@DBName, ' ', ''))
SET @DBName = '''' + REPLACE(@DBName, ',', ''', ''') + ''''
Set @CMD =   ' Select ' +
'''DECLARE  @SP_Add_RetCode As int, @LS_BackupJobIdAS uniqueidentifier,  @LS_PrimaryIdAS uniqueidentifier
EXEC @SP_Add_RetCode = master.dbo.sp_add_log_shipping_primary_database ' + CHAR(10) +
'@database = ''''''  + db.Name + ''''''' + CHAR(10) +
',@backup_directory = ''''\\' + @BkpDrive + '\LS\' + ''' + db.Name + ''''' + '''' + CHAR(10) +
',@backup_share = ' + '''''\\' + @BkpDrive + '\LS\' + ''' + db.Name + ''''' + ''''  + CHAR(10) +
',@backup_job_name = ''''' + 'LSBackup_' + ''' + db.Name + ''''' + '''' + CHAR(10) +
',@backup_retention_period = 4320
,@backup_compression = 1
,@backup_threshold = 180 
,@threshold_alert_enabled = 1
,@history_retention_period = 5760 
,@backup_job_id = @LS_BackupJobId OUTPUT 
,@primary_id = @LS_PrimaryId OUTPUT 
,@overwrite = 1 ' +
'IF (@@ERROR = 0 AND @SP_Add_RetCode = 0) 
BEGIN 
DECLARE @LS_BackUpScheduleUIDAs uniqueidentifier ,@LS_BackUpScheduleIDAS int 
EXEC msdb.dbo.sp_add_schedule 
@schedule_name = ''''' + 'LSBackupSchedule_'+ @PrimServer + '_' + ''' + db.Name + ''''' + ''''  + CHAR(10) +
',@enabled = 1 
,@freq_type = 4 
,@freq_interval = 1 
,@freq_subday_type = 4 
,@freq_subday_interval = 13 
,@freq_recurrence_factor = 0 
,@active_start_date = 20090506 
,@active_end_date = 99991231 
,@active_start_time = ' + @Time  + CHAR(10) +
',@active_end_time = 235900 
,@schedule_uid = @LS_BackUpScheduleUID OUTPUT 
,@schedule_id = @LS_BackUpScheduleID OUTPUT 
EXEC msdb.dbo.sp_attach_schedule @job_id = @LS_BackupJobId ,@schedule_id = @LS_BackUpScheduleID  
EXEC msdb.dbo.sp_update_job @job_id = @LS_BackupJobId ,@enabled = 1 
END 
EXEC master.dbo.sp_add_log_shipping_alert_job 
EXEC master.dbo.sp_add_log_shipping_primary_secondary 
@primary_database = '''  + ''''' + db.Name + ''''' + ''''  + CHAR(10) + 
',@secondary_server = ''''' + @SecInstance + ''''''  + CHAR(10) +
',@secondary_database = ''' + ''''' + db.Name + ''''' + ''''  + CHAR(10) +
',@overwrite = 1 ''' +
' [LSDBs] FROM sys.databases db  where name in (' + @DBName + ')' +
'and    db.name  not in (''master'',''model'',''msdb'',''tempdb'',''metricsops'',''periscope'' )
and   Not (exists (select lss.Secondary_database from msdb.dbo.log_shipping_Secondary_databases lss where  db.Name = lss.Secondary_database)
or exists (select lsp.primary_database from msdb.dbo.log_shipping_primary_databases lsp where  db.Name = lsp.primary_database)
   )'
Insert #LogShipping (LSDBs)
Exec ( @CMD)
Set @Counter = @@rowcount
While (@counter > 0)
  Begin
  select top 1  @CMD = LSDBs from #LogShipping
  exec sp_executesql @CMD
  set @counter = @counter - 1
  delete top (1) from #LogShipping
  End
IF OBJECT_ID ('tempdb.DBO.#LogShipping','U') IS NOT NULL DROP TABLE #LogShipping
-- ****** End: Script to be run at Primary: [DB1-PSMSQL-01] ******
  1. Configurare il log shipping in un server di database secondario usando il seguente script: Secondary-Logshippingsetupparameter scripts. Nell'ambiente lab il server di database secondario è contenuto nella farm di ripristino in Azure.
-- ****** Begin: Script to be run at Secondary:  9.3 BUILD******
SET NOCOUNT ON
USE MSDB
GO
--@PrimServer : Primary Server name
--@SecServer  : DR/Secondary Server Name
--@SecInstance : DR/Secondary FQDN
--@Domain  : Domain Name
--@PrimaryBkpDrive : Production Backup server Name
--@BkpDrive : Secondary Backup server Name
--@DBName : DatabaseName
DECLARE @LS_BackupJobIdAS uniqueidentifier,  @LS_PrimaryIdAS uniqueidentifier , @SP_Add_RetCode As int 
DECLARE @Time as nvarchar(10),@SecInstance as nvarchar(250), @PrimServer as nvarchar(50),@SecServer as nvarchar(50),
@Domain as nvarchar(50),@DBName as nvarchar(max),@PrimaryBkpDrive as nvarchar(250),@BkpDrive as nvarchar(250),@CMD as nvarchar(max),@CMD2 as nvarchar(max),@Counter int
DECLARE  @Delimeter char(1),@DB nvarchar(200), @StartPos int, @Length int
IF OBJECT_ID ('tempdb.DBO.#LogShipping','U') IS NOT NULL DROP TABLE #LogShipping
Create table #LogShipping ( LSDBs nvarchar(max))
IF OBJECT_ID ('tempdb.DBO.#DBs','U') IS NOT NULL DROP TABLE #DBs
Create TABLE #DBs (Name nvarchar(200))
Set @PrimServer ='az-sql-ha1'
Set @SecServer =' az-sql-ha2'
Set @SecInstance ='SQL1.corp.adventureworks.com'
Set @Domain =' corp.adventureworks.com '
SET @PrimaryBkpDrive = 'fs1.corp.adventureworks.com'
Set @BkpDrive =' az-sp-fs.corp.adventureworks.com '
Set @DBName = 'Social_DB'
Set @Time = '0130'
--Parsing Function
SET @Delimeter = ','
WHILE LEN(@DBName) > 0
  BEGIN
    SET @StartPos = CHARINDEX(@Delimeter, @DBName)
    IF @StartPos < 0 SET @StartPos = 0
    SET @Length = LEN(@DBName) - @StartPos - 1
    IF @Length < 0 SET @Length = 0
    IF @StartPos > 0
      BEGIN
        SET @DB = Rtrim(Ltrim(SUBSTRING(@DBName, 1, @StartPos - 1)))
        SET @DBName = SUBSTRING(@DBName, @StartPos + 1, LEN(@DBName) - @StartPos)
      END
    ELSE
      BEGIN
        SET @DB = Rtrim(Ltrim(@DBName))
        SET @DBName = ''
      END
    INSERT #DBs (Name) VALUES(@DB)
END
--SET @DBName = UPPER(REPLACE(@DBName, ' ', ''))
--SET @DBName = '''' + REPLACE(@DBName, ',', ''', ''') + ''''
Set @CMD = 'Select ' +
''' DECLARE @LS_Secondary__CopyJobId AS uniqueidentifier, @LS_Secondary__RestoreJobId AS uniqueidentifier ,@LS_Secondary__SecondaryId AS uniqueidentifier , @LS_Add_RetCode As int ,@LS_Add_RetCode2 As int 
  DECLARE @LS_SecondaryCopyJobScheduleUIDAs uniqueidentifier ,@LS_SecondaryCopyJobScheduleIDAS int, @LS_SecondaryRestoreJobScheduleUIDAs uniqueidentifier ,@LS_SecondaryRestoreJobScheduleIDAS int 
  EXEC @LS_Add_RetCode = master.dbo.sp_add_log_shipping_secondary_primary 
@primary_server = ''''' + @PrimServer + ''''''+  CHAR(10) +
',@primary_database = '' + ' +  ''''''''' + db.Name + ''''''''' +  CHAR(10) +
' + '',@backup_source_directory = ' + '''''\\' + @PrimaryBkpDrive + '\LS\'' + db.Name + ''''''' +  CHAR(10) +
' ,@backup_destination_directory =  ' + '''''\\' + @BkpDrive + '\LS\'' + db.Name + ''''''' +  CHAR(10) +
',@copy_job_name = ''''LSCopy_DB1-PSMSQL-01_'' + db.Name + ''''''' +  CHAR(10) +
',@restore_job_name = ''''LSRestore_'+ @PrimServer + '_'' + db.Name + ''''''' +  CHAR(10) +
',@file_retention_period = 4320 
,@overwrite = 1 
,@copy_job_id = @LS_Secondary__CopyJobId OUTPUT 
,@restore_job_id = @LS_Secondary__RestoreJobId OUTPUT 
,@secondary_id = @LS_Secondary__SecondaryId OUTPUT 
IF (@@ERROR = 0 AND @LS_Add_RetCode = 0) 
BEGIN 
EXEC msdb.dbo.sp_add_schedule 
@schedule_name =''''DefaultCopyJobSchedule'''' 
,@enabled = 1 
,@freq_type = 4 
,@freq_interval = 1 
,@freq_subday_type = 4 
,@freq_subday_interval = 15 
,@freq_recurrence_factor = 0 
,@active_start_date = 20090506 
,@active_end_date = 99991231 
,@active_start_time = ' + @Time + ' 
,@active_end_time = 235900 
,@schedule_uid = @LS_SecondaryCopyJobScheduleUID OUTPUT 
,@schedule_id = @LS_SecondaryCopyJobScheduleID OUTPUT 
EXEC msdb.dbo.sp_attach_schedule 
@job_id = @LS_Secondary__CopyJobId 
,@schedule_id = @LS_SecondaryCopyJobScheduleID  
EXEC msdb.dbo.sp_add_schedule 
@schedule_name =''''DefaultRestoreJobSchedule'''' 
,@enabled = 1 
,@freq_type = 4 
,@freq_interval = 1 
,@freq_subday_type = 4 
,@freq_subday_interval = 15 
,@freq_recurrence_factor = 0 
,@active_start_date = 20090506 
,@active_end_date = 99991231 
,@active_start_time = ' + @Time + '
,@active_end_time = 235900 
,@schedule_uid = @LS_SecondaryRestoreJobScheduleUID OUTPUT 
,@schedule_id = @LS_SecondaryRestoreJobScheduleID OUTPUT 
EXEC msdb.dbo.sp_attach_schedule 
@job_id = @LS_Secondary__RestoreJobId 
,@schedule_id = @LS_SecondaryRestoreJobScheduleID  
END 
IF (@@ERROR = 0 AND @LS_Add_RetCode = 0) 
BEGIN 
EXEC @LS_Add_RetCode2 = master.dbo.sp_add_log_shipping_secondary_database 
@secondary_database = ' +  ''''''' + db.Name + ''''''' +  CHAR(10) + '
,@primary_server = ''''' + @PrimServer + '''''
,@primary_database = '+  ''''''' + db.Name + ''''''' +  CHAR(10) +
',@restore_delay = 0 
,@restore_mode = 1 
,@disconnect_users= 1 
,@restore_threshold = 180   
,@threshold_alert_enabled = 1 
,@history_retention_period= 5760 
,@overwrite = 1 
END 
IF (@@error = 0 AND @LS_Add_RetCode = 0) 
BEGIN 
EXEC msdb.dbo.sp_update_job @job_id = @LS_Secondary__CopyJobId ,@enabled = 0 
EXEC msdb.dbo.sp_update_job @job_id = @LS_Secondary__RestoreJobId ,@enabled = 1 
END '''  + '[LSDBs] FROM #DBs db'
--Print @CMD
Insert #LogShipping (LSDBs)
Exec ( @CMD)
Set @Counter = @@rowcount
While (@counter > 0)
  Begin
  select top 1  @CMD = LSDBs from #LogShipping
  exec sp_executesql @CMD
  set @counter = @counter - 1
  delete top (1) from #LogShipping
  End
IF OBJECT_ID ('tempdb.DBO.#LogShipping','U') IS NOT NULL DROP TABLE #LogShipping
IF OBJECT_ID ('tempdb.DBO.#DBs','U') IS NOT NULL DROP TABLE #DBs
-- ****** End: Script to be run at Secondary:  9.3 Build ******
  1. Verificare che i log delle transazioni vengano inviati alla condivisione e che DFS replichi tali log nella condivisione nel file server di Azure. Aprire Monitoraggio attività processi in SQL Server per verificare che i log delle transazioni siano stati inviati correttamente. Aprire le cartelle condivise in entrambi i file server nelle farm di produzione e di Azure per verificare che DFS stia trasferendo i log delle transazioni.

Vedere anche

Concetti

Configurare i gruppi di disponibilità AlwaysOn di SQL Server per SharePoint Server

Ulteriori risorse

Informazioni sul Log Shipping (SQL Server)

Esercitazioni sulla replica