Configurer la copie des journaux de transaction dans SharePoint Server

Article
02/23/2018

**Sapplique à :**Microsoft Azure, SharePoint Server 2013, SharePoint Server 2016, SQL Server

**Dernière rubrique modifiée :**2018-02-21

**Résumé :**Découvrez comment implémenter la copie des journaux de transaction pour SharePoint Server 2016 et SharePoint Server 2013 dans un scénario de récupération d’urgence.

Grâce à la copie des journaux de transaction, vous sauvegardez les journaux de transaction d’une base de données primaire vers une base de données secondaire sur une instance distincte de SQL Server. Dans le scénario décrit ici, la copie des journaux de transaction de SQL Server est utilisée avec la réplication du système de fichiers (DFSR) pour copier des bases de données et des journaux de transaction sur la batterie de serveurs de récupération dans Microsoft Azure, comme illustré ci-dessous.

Dans ce scénario de récupération d’urgence, la batterie de serveurs de production SharePoint Server est située dans l’environnement local et la batterie de serveurs de récupération se trouve dans Azure. Vous pouvez également adapter les instructions de cette rubrique à d’autres types de scénario de récupération d’urgence.

Éléments d’une solution de secours semi-automatique dans Azure

Elements of a warm standby solution in Azure

Dans cette illustration :

Deux environnements sont illustrés côte à côte : la batterie de serveurs SharePoint locale et la batterie de serveurs de récupération (de secours) dans Azure.
Chaque environnement inclut un partage de fichiers.
La copie des journaux de transaction est utilisée pour copier des journaux depuis le serveur de base de données secondaire dans l’environnement local vers le partage de fichiers local.
La réplication du système de fichiers DFS copie des fichiers depuis le partage de fichiers situé dans l’environnement local vers le partage de fichiers situé dans l’environnement Azure. Dans un scénario de réseau étendu, la réplication du système de fichiers est plus efficace que l’envoi direct des journaux de transaction vers le serveur secondaire situé dans Azure.
La copie des journaux de transaction relit les journaux de transaction depuis le partage de fichiers situé dans l’environnement Azure vers le réplica principal situé dans le groupe de disponibilité AlwaysOn SQL Server dans l’environnement de récupération.
Les bases de données dont les journaux de transaction sont copiés ne sont pas attachées à la batterie de serveurs SharePoint Server tant qu’aucun exercice de récupération n’est effectué.

Le schéma suivant montre les sept phases de la récupération d’urgence SharePoint Server complète dans la solution Azure. Phase 6 : la configuration de la copie des journaux de transaction vers la batterie de serveurs de récupération est mise en évidence dans ce schéma et expliquée dans les sections suivantes.

Disaster recovery solution roadmap

Contenu de cet article :

Utilisation de la copie des journaux de transaction pour la récupération d'urgence
Considérations liées aux performances
Conditions préalables pour la configuration de la copie des journaux de transaction
Infrastructure de la copie des journaux de transaction
Étapes obligatoires pour configurer et valider la copie des journaux de transaction

Utilisation de la copie des journaux de transaction pour la récupération d’urgence

La copie des journaux de transaction vous permet d’envoyer automatiquement des fichiers journaux de transaction pour des bases de données, depuis une instance du serveur de base de données primaire vers une instance du serveur de base de données secondaire. Dans notre environnement de test local, nous utilisons les groupes de disponibilité AlwaysOn avec deux réplicas pour la haute disponibilité. Nous avons configuré la copie des journaux de transaction sur les deux réplicas. Chaque réplica doit être capable de copier des journaux de transaction. Seul le réplica qui est actif et propriétaire de la base de données peut copier des journaux. Toutefois, si un événement de basculement avait lieu et que le deuxième réplica devenait actif, il devrait copier les journaux de transaction à la place du réplica ayant échoué.

Une fois que les journaux de transaction sont reçus dans l’environnement Azure, ils sont restaurés, un par un, dans chaque base de données SharePoint sur le serveur de base de données secondaire. Pour plus d’informations sur notre environnement de test, voir Environnement de validation technique de Microsoft.

Notes

Certaines organisations utilisent un troisième serveur de base de données comme moniteur pour enregistrer l’historique et l’état des opérations de sauvegarde et de restauration. Ce serveur moniteur facultatif crée des alertes en cas d’échec des opérations de sauvegarde.

Pour obtenir des informations détaillées sur la copie des journaux de transaction, reportez-vous aux articles répertoriés dans le tableau suivant.

Tableau : articles de référence pour la copie des journaux de transaction

URL	Description
À propos de la copie des journaux de transaction (SQL Server)	Décrit la copie des journaux de transaction, les sauvegardes des journaux de transaction et les options disponibles.
Configurer la copie des journaux de transaction (SQL Server)	Explique comment configurer la copie des journaux de transaction dans SQL Server 2012 en utilisant SQL Server Management Studio ou Transact-SQL.
Affichers le rapport de la copie des journaux de transaction (SQL Server Management Studio)	Explique comment afficher le rapport d’état de l’envoi des journaux de transaction dans SQL Server Management Studio. Vous pouvez exécuter un rapport d’état sur un serveur moniteur, un serveur principal ou un serveur secondaire.

Considérations liées aux performances

La copie des journaux de transaction est composée de trois travaux. Chaque travail effectue l’une des opérations suivantes :

Sauvegarde du journal des transactions sur l’instance de serveur principal.
Copie du fichier journal des transactions sur l’instance de serveur secondaire.
Restauration de la sauvegarde du journal sur l’instance de serveur secondaire.

Chaque travail est effectué selon un calendrier et dure un certain temps, ce qui peut avoir un impact significatif sur le serveur de base de données et, par conséquent, sur les performances de la batterie de serveurs SharePoint.

Pour définir correctement les intervalles entre les travaux de restauration, de copie et de sauvegarde lors de la copie des journaux de transaction, vous devez analyser le volume de données envoyé. Le volume des modifications quotidiennes apportées aux bases de données de contenu a un impact sur le volume de données envoyé. Le pourcentage de modification peut varier considérablement selon le contenu, les modifications de maintenance et les pics d’utilisation.

Pour obtenir un pourcentage de modification précis, calculez la somme des modifications apportées dans les sauvegardes du journal des transactions de chaque base de données de contenu pour laquelle vous copiez les journaux de transaction pendant un intervalle donné. Utilisez ces données pour calculer le pourcentage de modification par rapport à la base de données primaire.

Les conseils suivants sont tirés de l’expérience de copie des journaux de transaction du personnel de Microsoft sur le terrain, avec plusieurs versions de SharePoint Server.

Pour éviter la dégradation des performances due au démarrage simultané de tous les travaux, assurez-vous que tous les travaux de copie des journaux de transaction s’effectuent au moins à une minute d’intervalle.
Il est préférable de sauvegarder et de copier un grand nombre de journaux de transaction de petite taille plutôt qu’un petit nombre de journaux de transaction de grande taille.
Planifiez des sauvegardes et des copies des journaux à des intervalles réguliers. Vous pouvez restaurer les journaux de transaction à des intervalles moins fréquents. Par exemple, commencez par utiliser des intervalles de sauvegarde et de copie de cinq minutes, et un intervalle de restauration de 15 minutes.

Conditions préalables pour la configuration de la copie des journaux de transaction

Assurez-vous de bien remplir les conditions préalables suivantes pour utiliser la copie des journaux de transaction pour une solution de récupération d’urgence.

Les identifiants de connexion à SQL Server sont des comptes de domaine dotés des niveaux d’autorisation nécessaires à la copie des journaux de transaction. Les procédures stockées de copie des journaux de transaction exigent que vous soyez membre du rôle serveur fixe sysadmin.
La base de données principale doit utiliser le mode de récupération complet ou celui utilisant les journaux de transaction.

Avertissement

Si vous basculez la base de données en mode de récupération simple, la copie des journaux de transaction cessera de fonctionner.
Avant de configurer la copie des journaux de transaction, vous devez créer un partage pour permettre au serveur secondaire d’avoir accès aux sauvegardes des journaux de transaction. Il s’agit d’un partage du répertoire dans lequel les sauvegardes des journaux de transaction sont générées.

En plus de vos objectifs de point de récupération (RPO), assurez-vous que les données de batterie récupérées sont aussi complètes et intactes que possible. Pour atteindre ces objectifs, vous devez planifier soigneusement tous les aspects de la copie des journaux de transaction.

Infrastructure de la copie des journaux de transaction

L’infrastructure de la copie des journaux de transaction utilisée pour notre environnement de solution de récupération d’urgence est illustrée dans le schéma suivant.

Infrastructure de la copie des journaux de transaction et flux de données

Shows the log shipping infrastructure and directional flow between the on-premise and Azure farms.

Le schéma précédent illustre l’infrastructure de la copie des journaux de transaction et le flux de données. Le schéma montre les serveurs de base de données SQL Server et les serveurs de fichiers dans la batterie de serveurs de production et la batterie de serveurs de récupération Azure. Ces batteries de serveurs sont presque identiques, et chacune contient un réplica principal et secondaire pour chaque groupe de disponibilité AlwaysOn. Les serveurs de fichiers FIL1 et AZ-FIL1 sont configurés de la même façon ; ils comprennent le même nombre de disques durs et la taille des disques est également identique. Les serveurs supplémentaires de la batterie de serveurs ne sont pas affichés.

Pour assurer une haute disponibilité, chaque réplica stocke, dans un groupe de disponibilité, une sauvegarde (complète, différentielle, ainsi que des journaux de transaction) de l’autre réplica.

Les réplicas principal et secondaire (SQL-HA1 et SQL-HA2, respectivement) procèdent à des sauvegardes qui sont stockées sur leur partenaire dans le groupe de disponibilité.

La copie des journaux de transaction est configurée sur le réplica secondaire pour minimiser l’impact des sauvegardes sur les bases de données de production. Ces journaux des transactions sont écrits dans un dossier partagé sur le serveur de fichiers local (FIL1). Le service de réplication du système de fichiers distribués DFS Windows Server copie les journaux de transaction depuis FIL1 vers AZ-FIL1. Les journaux de transaction sur AZ-FIL1 sont restaurés sur AZ-SQL-HA1, réplica principal du groupe de disponibilité de la batterie de serveurs de récupération.

Étapes obligatoires pour configurer et valider la copie des journaux de transaction

Les étapes obligatoires pour configurer, exécuter et valider la copie des journaux de transaction sont rassemblées et résumées dans la liste suivante :

Sauvegardez la base de données.
1. Configurez les sauvegardes complètes et différentielles afin qu’elles s’effectuent dans un dossier local et également dans un dossier partagé sur le serveur de fichiers.
2. Vérifiez que les sauvegardes ont été effectuées à la fois dans le dossier local et le dossier partagé.
Configurez et testez la réplication de système de fichiers DFS.
1. Créez un espace de noms et une réplication pour transférer les journaux de transaction et les fichiers de sauvegarde entre les batteries de serveurs locales et Azure dans le dossier partagé dans le serveur de fichiers.
2. Vérifiez tous les transferts après l’exécution de la copie des journaux de transaction.

Configurez et testez la copie des journaux de transaction.

Configurez la copie des journaux de transaction sur le serveur de base de données primaire à l’aide du script suivant : Primary-Logshippingsetupparameter. Ce script crée des travaux de sauvegarde, les programme pour la copie des journaux de transaction, puis lance les travaux.

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]  ******

Configurez la copie des journaux de transaction sur un serveur de base de données secondaire à l’aide du script suivant : Secondary-Logshippingsetupparameter scripts. Dans notre environnement lab, le serveur de base de données secondaire se trouve dans la batterie de serveurs de récupération située dans 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 ******

Vérifiez que les journaux de transaction sont copiés vers le partage et que le système de fichiers DFS réplique ces journaux vers le partage sur le serveur de fichiers Azure. Ouvrez le moniteur d’activité des travaux dans SQL Server pour vérifier que les journaux de transaction ont été copiés. Ouvrez les dossiers partagés sur les deux serveurs de fichiers dans les batteries de serveurs de production et Azure pour vérifier que le système de fichiers DFS transfère les journaux de transaction.