Workflow Manager 1.0에서의 재해 복구 및 범위 복원

이 항목에서는 Workflow Manager 1.0의 재해 복구 옵션과 절차에 대해 간략하게 설명합니다. 데이터베이스 서버 오류 및 응용 프로그램 서버 오류를 처리하는 절차를 다루고, 손상되거나 삭제된 범위를 복원하는 절차를 제공합니다.

• 재해 복구

• 범위 복원

재해 복구

Workflow Manager 1.0을 사용하여 재해 시나리오에 대비할 수 있습니다. 이 항목의 범위에서 재해란 심각한 손실, 파손, 고충 등을 일으키는 이벤트를 말합니다. 서버 제품의 경우, 서버 사용에 장기간 장애를 일으키고 서버용으로 설정된 원래 클러스터 또는 그 일부에 대한 다양한 손실을 동반할 수 있는 모든 이벤트가 재해에 해당됩니다.

재해 복구 및 고가용성

일반적으로 재해 복구는 고가용성에 포함됩니다. 고가용성은 시스템에서 충분한 중복성을 구축하고 단일 실패 지점을 제거하는 등 정상적인 환경에서 서비스의 가용성을 높이는 문제입니다. 그러나 재해 복구는 외부 환경(예: 자연 재해)으로 인해 주요 서비스의 작동이 중지되어 동일한 수준의 서비스를 계속 제공해야 하는 문제입니다.

간략한 재해 복구 모델

재해를 대비하고 대응하는 프로세스는 다음 섹션에 표시된 대로 여러 단계로 세분화될 수 있습니다. 이 다이어그램에서는 이러한 각 단계를 보여 주고, 사용자가 Workflow Manager에서 제공하는 기능을 선택해야 하는 책임에 대해 설명합니다.

Workflow Manager에 대한 여러 유형의 재해 시나리오

Workflow Manager의 경우 대비해야 하는 여러 가지 재해 시나리오가 있을 수 있습니다.

1. Workflow Manager에서 사용하는 하나 이상의 데이터베이스를 손실시키는 재해

   1. 이 재해는 하드웨어 오류 또는 데이터 센터 수준의 재해 이벤트로 인해 발생할 수 있습니다.

2. Workflow Manager 바이너리가 배포된 응용 프로그램 서버를 손실시키는 재해

3. 응용 프로그램 서버와 데이터베이스가 모두 손실되는 전체 클러스터의 손실을 일으키는 재해

Workflow Manager에는 사용자의 워크플로, 작업 및 인스턴스와 관련된 정보가 포함되어 있으므로 Workflow Manager 재해 복구에서는 백업 복사본을 사용하여 Workflow Manager 설치 데이터를 복원하는 기능이 중요합니다. 따라서 이러한 시나리오에서는 대부분 재해 복구가 백업에서 데이터를 복원하고 Workflow Manager의 여러 하위 시스템에서 데이터의 일관성을 유지하는 것과 주로 관련이 있습니다.

재해 복구 대비

재해 복구는 긴급한 상황이 발생할 경우를 대비하는 모든 사전 조치입니다.Workflow Manager을 사용하면 재해가 발생한 경우에도 모든 작업, 워크플로 및 인스턴스와 관련된 데이터를 보존할 수 있습니다.

Workflow Manager에서는 모든 데이터를 SQL Server 데이터베이스에 저장합니다. 따라서 재해 복구를 위해서는 데이터 센터에 영향을 주는 재해가 실제로 발생한 경우 데이터베이스의 최근 복사본을 사용하여 Workflow Manager 설치를 복원할 수 있도록 정기적인 백업 및/또는 데이터 중복 솔루션을 설치하는 것이 중요한 사전 요구 사항입니다.

Workflow Manager 설치에서는 다음 데이터베이스를 사용합니다.

Workflow Manager 설치에서 유지하는 워크플로 데이터의 중요성에 따라 여러 가지 재해 복구 준비 옵션에서 선택할 수 있습니다.Workflow Manager의 데이터는 모두 위에 설명된 대로 SQL Server 데이터베이스에 저장되므로 모든 SQL Server 기반 고가용성 및 백업 전략을 Workflow Manager에도 적용해야 합니다.

SQL Server의 고가용성 및 재해 복구를 위한 에 대한 자세한 내용은 구현에 대한 자세한 내용은 고가용성 솔루션 선택과 Microsoft SQL Server에 대한 재해 복구 옵션 설명을 참조하십시오.

다음 다이어그램에는 Workflow Manager 설치의 여러 구성 요소가 나와 있습니다.

서버 팜 관리자의 관점에서 볼 때 재해 시 손상될 수 있는 Workflow Manager 요소에는 포함된 하나 이상의 데이터베이스와 하나 이상의 응용 프로그램 서버 노드의 두 가지가 있습니다. 작동 중단된 응용 프로그램과 데이터베이스 서버의 조합은 여러 가지가 있을 수 있지만 크게 분류하면 데이터 계층과 응용 프로그램 계층이 실패 지점입니다.

• 데이터 계층

• 컴퓨터 계층(워크플로/메시징 계층)

데이터 계층

Workflow Manager 1.0에서는 해당 데이터를 다음 SQL Server 데이터베이스에 저장합니다.

데이터 계층의 경우, 재해 복구와 관련된 세 가지 중요한 작업이 있습니다.

1. 준비 - 데이터베이스와 관련된 재해 발생 시 데이터가 손실되지 않도록 데이터베이스에 대한 올바른 백업/복제 전략을 유지해야 합니다.

   재해 상황에서 복구하려면 재해에 대비해야 합니다. 특히, 데이터베이스 손실과 관련된 재해에서 복구하려면 여러 곳에 데이터 복사본을 저장할 수 있는 방법이 있어야 합니다. 이러한 데이터베이스는 표준 SQL 데이터베이스이므로 다음과 같은 인정된 SQL 기술을 사용하는 것이 좋습니다.

   1. SQL 미러링

   2. SQL 복제

   3. 간단한 백업 및 백업과 로그 전달의 조합

   비즈니스 성격 및 백업과 주 데이터베이스 간에 유지하려는 데이터 품질 수준에 따라 이러한 기술 중 하나를 선택할 수 있습니다.

   기본적으로 Workflow Manager 팜 관리자는 요구에 적합한 백업 전략을 사용하여 이러한 데이터베이스의 백업을 만들어야 합니다.Workflow Manager에서는 이러한 백업 데이터베이스 생성을 지원하는 기능을 제공하지 않습니다.

2. 백업 데이터베이스 복원

   데이터 복제 전략에 따라 적절한 복원 도구/메커니즘을 사용하여 백업 데이터베이스를 복원해야 합니다. SQL 데이터베이스를 복원하는 데 사용할 수 있는 산업 표준 SQL 도구 및 기술이 있습니다.

3. Workflow Manager 팜 복원

   이 단계는 Workflow Manager 팜이 일관된 상태로 복원되고 제대로 작동할 수 있는지 확인하는 프로세스에 해당합니다.Workflow Manager에서는 이 단계를 수행하는 데 필요한 PowerShell 스크립트 및 지침을 제공합니다.

컴퓨터 계층(워크플로/메시징 계층)

재해 복구 시나리오가 발생한 경우 도움이 되도록 보조 위치에 보조 팜을 만들 수 있습니다. 이러한 보조 팜은 재해 이전이나 이후에 만들 수 있습니다. 고려할 모델에는 세 가지가 있습니다.

1. 콜드 대기

   이 모델에서는 재해가 발생한 후 팜을 다시 만들 수 있습니다. 이 경우 새 컴퓨팅 노드를 구축하고 이러한 노드에 Workflow Manager을 새로 설치해야 하므로 팜을 복구하는 데 시간이 더 오래 걸릴 수 있습니다.

2. 웜 대기

   일반적으로 재해가 발생하기 이전에 보조 팜을 만들고 테스트했는지 확인하려는 경우 이 모델을 선택할 수 있습니다. 이 모델에서는 재해가 발생하기 전에 새 팜에 컴퓨팅 노드를 구축합니다. 데이터베이스 쌍의 관계를 설정한 후 이 새 팜을 보조 데이터베이스로 지정할 수 있습니다.

   이 새 팜을 설정한 후에는 기본적으로 컴퓨팅 노드를 해제하여 유휴 상태로 실행되지 않도록 합니다. 재해 복구의 일부로, Workflow Manager에서 제공하는 데이터베이스 일관성 스크립트를 실행해야 합니다.

   참고

   이 모델에서는 초기 설치 후 새 서비스 버스 컨테이너 데이터베이스가 주 서버에 만들어지지 않은 것으로 가정합니다. 새 서비스 버스 컨테이너 데이터베이스가 주 서버에 만들어진 경우에는 복구 중에 추가 단계를 수행해야 합니다.

3. 상시 대기

   이 모델은 컴퓨팅 노드를 설정할 수 있도록 웜 대기를 향상시킨 모델입니다. 따라서 재해에서 신속하게 복구할 수 있습니다.

   경고

   상시 대기는 Workflow Manager에서 지원되지 않습니다.

재해 복구 프로세스

이 섹션에서는 위에 설명된 여러 가지 재해 시나리오에 사용되는 실제 재해 복구 프로세스에 대해 설명합니다. 대략적인 권장 프로세스는 백업(표준 SQL Server 기술을 사용하여 수행한 백업)에서 필요한 데이터베이스를 복원하고 Workflow Manager에서 제공하는 복원 cmdlet을 사용하여 팜을 복원하는 것입니다.

복원 명령을 실행하는 프로세스

1. 개인 키가 있는 서비스 버스 팜 인증서와 개인 키가 있는 서비스 버스 암호화 인증서 모두를 내보냅니다. 새 서버의 Local Computer\Personal 폴더로 둘 모두를 가져옵니다. 또한 새 서버의 Local Computer\Trusted Root Authority 폴더로 루트 인증서를 가져올 수도 있습니다. Get-sbfarm 출력에서 암호화 인증서 및 팜 인증서를 식별할 수 있습니다.

   참고

   가져오기는 이전 WFM/SB 서버의 이전 서비스 버스 암호화 인증서가 다음과 같은 경우에만 작동합니다. 이전 팜을 구성하는 동안 구성 도구를 통해 자동 생성되었습니다. 또는 이전 환경에서 서비스 버스에 대해 사용자 지정 인증서를 사용한 경우 사용자 도메인에 대한 와일드 카드 인증서여야 합니다. 즉, 인증서의 "주체 대체 이름" 필드가 *.mydomainname.com과 같은 값으로 만들어졌습니다. 이전 ServiceBus 인증서 가져오기를 수행하지 않는 경우 다음 단계의 Restore-WFFarm cmdlet은 다음과 비슷한 오류가 발생하며 실패합니다. Token provider returned message: '<Error><Code>400</Code><Detail>The namespace 'WorkflowDefaultNamespace' does not have a valid issuer that can be used to issue tokens. Add a valid issuer with a valid signature to the namespace.

2. 새 컴퓨터에서 관리자 권한 PowerShell(RunAs 관리자) 창을 엽니다.

3. 다음 매개 변수를 전달하는 Restore-SBFarm cmdlet을 호출합니다. 이 cmdlet은 새 서비스 버스 팜 관리 데이터베이스를 만듭니다. 그런 다음 이전 서비스 버스 팜 관리 데이터베이스를 삭제할 수 있습니다.

   Restore-SBFarm -FarmCertificateThumbprint <String> -GatewayDBConnectionString <String> -SBFarmDBConnectionString <String> [-AdminApiCredentials <PSCredential> ] [-AdminGroup <String> ] [-AmqpPort <Int32> ] [-AmqpsPort <Int32> ] [-EncryptionCertificateThumbprint <String> ] [-FarmDns <String> ] [-Force] [-HttpsPort <Int32> ] [-InternalPortRangeStart <Int32> ] [-MessageBrokerPort <Int32> ] [-RPHttpsPort <Int32> ] [-RunAsAccount <String> ] [-TcpPort <Int32> ] [-TenantApiCredentials <PSCredential> ] [-Confirm] [-WhatIf] [ <CommonParameters>]
   

   참고

   이전 ServiceBus 구성에 사용자 지정 와일드 카드 인증서를 사용하고 FarmCertificate 및 EncryptionCertificate에 서로 다른 두 인증서를 사용한 경우 새로운 각 노드에 두 인증서 모두를 가져오고 위에 있는 cmdlet의 FarmCertificateThumbprint 및 EncryptionCertificateThumbprint 매개 변수를 적절하게 제공해야 합니다.

   다음 코드 조각은 Restore-SBFarm 호출의 예를 보여줍니다.

   Restore-SBFarm -RunAsAccount 'farm\test' -FarmCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2 -GatewayDBConnectionString 'Data Source=DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False' -AdminGroup 'BUILTIN\Administrators' -EncryptionCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2
   

4. 다음 매개 변수를 사용하여 팜 노드 중 하나에서 Restore-SBGateway cmdlet을 호출합니다.

   매개 변수	설명
   SBFarmDBConnectionString	이전 단계에서 만든 Service Bus 팜 데이터베이스의 연결 문자열입니다.
   GatewayDBConnectionString	복원된 게이트웨이 데이터베이스의 연결 문자열입니다.

   다음 코드 조각은 Restore-SBGateway 호출의 예를 보여줍니다.

   Restore-SBGateway -GatewayDBConnectionString 'Data Source= DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'
   

5. 각 컨테이너 데이터베이스에 대해 다음 매개 변수를 사용하여 Restore-SBMessageContainer cmdlet을 호출합니다. 팜 컴퓨터 중 하나에서 이 cmdlet을 실행합니다.

   매개 변수	설명
   SBFarmDBConnectionString	이전 단계에서 만든 Service Bus 팜 데이터베이스의 연결 문자열입니다.
   ContainerDBConnectionString	컨테이너 데이터베이스의 연결 문자열입니다.
   Id	복원된 메시지 컨테이너의 ID입니다. 모든 메시지 컨테이너의 ID, 연결 문자열, 데이터베이스 서버 이름 및 데이터베이스 이름이 포함된 게이트웨이 데이터베이스의 [dbo].[ContainersTable] 테이블에서 복원된 메시지 컨테이너의 ID를 가져옵니다. 데이터베이스 이름이 원래 컨테이너 데이터베이스 이름과 일치하는 컨테이너의 ID를 선택합니다.

   다음 코드 조각은 Restore-SBMessageContainer cmdlet을 호출하는 예입니다.

   Restore-SBMessageContainer -ContainerDBConnectionString "Data Source=localhost;Initial Catalog=SBMessageContainer01;Integrated Security=SSPI;Asynchronous Processing=True" -SBFarmDBConnectionString "Data Source=localhost;Initial Catalog= SBManagementDB;Integrated Security=SSPI;Asynchronous Processing=True" –id 1
   

6. Add-SBHost cmdlet을 호출하고 다음 매개 변수를 전달합니다.

   매개 변수	설명
   SBFarmDBConnectionString	이전 단계에서 만든 Service Bus 팜 데이터베이스의 연결 문자열입니다.
   CertificateAutoGenerationKey	이 매개 변수는 SB 인증서 자동 생성에 사용되는 키입니다.
   RunAsPassword	Service Bus 프로세스를 실행하는 계정의 암호가 포함된 보안 문자열입니다.
   EnableFirewallRules	Service Bus 데이터가 방화벽을 통과하도록 허용하기 위해 호스트의 방화벽 규칙을 업데이트해야 하는 경우에는 True이고, 그렇지 않으면 False입니다.

   다음 예에서는 cmdlet을 호출하는 방법을 보여 줍니다.

   $myPassword=convertto-securestring 'ereee' -asplaintext -force Add-SBHost -EnableFirewallRules $TRUE -RunAsPassword $myPassword -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'
   

7. Restore-WFFarm cmdlet을 호출하고 ResourceManagement 및 Instance Database 연결 문자열을 사용합니다.

   다음 예에서는 cmdlet을 호출하는 방법을 보여 줍니다.

   $mykey=convertto-securestring 'etwegff' -asplaintext -force Restore-WFFarm  -RunAsAccount 'farm\test' -InstanceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -ResourceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False' -InstanceStateSyncTime 'Sunday, May 11, 2014 12:30:00 PM' -ConsistencyVerifierLogPath 'c:\log.txt' -CertificateAutoGenerationKey $myKey
   

   참고

   InstanceStateSyncTime은 위 예에 지정된 형식을 그대로 따라야 합니다. ConsistencyVerifierLogPath는 이 cmdlet에서 복원 프로세스와 관련된 로그를 기록하는 폴더의 경로여야 합니다.

8. Add-WFHost cmdlet을 호출합니다.

   다음 예에서는 cmdlet을 호출하는 방법을 보여 줍니다.

   Add-WFHost -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -RunAsPassword $myPassword -EnableFirewallRules $TRUE -CertificateAutoGenerationKey $myKey
   

시나리오 1 - 재해가 전체 클러스터에 영향을 주는 경우

이 시나리오에서는 전체 클러스터가 재해로 인한 영향을 받습니다. 이 재해 시나리오에서 복구하려면 가장 최근 데이터베이스 백업을 사용하여 전체 클러스터를 다시 구축해야 합니다.

1. 새 컴퓨터에 Workflow Manager 1.0을 설치합니다.

   참고

   설치 관리자를 사용하여 Workflow Manager 1.0을 설치하되, 팜 구성은 아직 시작하지 않습니다.

2. SQL Server 복원 기능을 사용하여 백업된 주 데이터베이스를 복원합니다. 이 단계는 선택한 백업 솔루션에 따라 달라집니다.

   다음 데이터베이스만 복원해야 합니다.

   • WFResourceManagementDB

   • WFInstanceManagementDB

   • SbGatewayDatabase

   • SBMessageContainer*

   중요
   WFManagementDB 및 SbManagementDb 데이터베이스는 복원 작업의 일부로 다시 만들어지므로 복원하지 마십시오.

3. 복원 명령을 실행하는 프로세스에 설명된 단계를 따릅니다.

시나리오 2 - 재해가 SQL Server 데이터베이스에만 영향을 주는 경우

이 경우 Workflow Manager에서 사용하는 하나 이상의 데이터베이스가 손실되거나 액세스할 수 없게 됩니다. 이 문제는 하드웨어 오류 또는 기타 SQL Server에 한정된 재해로 인해 발생할 수 있습니다.

1. 기존 응용 프로그램 서버 노드 중 하나에서 Workflow Manager 1.0을 제거합니다.

2. 이전 단계에 따라 Workflow Manager 1.0을 서버에 다시 설치합니다.

   참고

   설치 관리자를 사용하여 Workflow Manager을 설치하되, 팜 구성은 아직 시작하지 않습니다.

3. SQL Server 복원 기능을 사용하여 백업된 주 데이터베이스를 복원합니다. 이 단계는 선택한 백업 솔루션에 따라 달라집니다. 재해의 성격에 따라 기존 SQL Server 또는 다른 SQL Server에 복원할 수 있습니다.

4. 복원 명령을 실행하는 프로세스에 설명된 단계를 따릅니다.

이러한 단계를 완료하면 기존 데이터베이스를 사용하는 하나의 노드가 있는 팜이 생성됩니다. 이 팜은 원본 데이터베이스의 백업 복사본을 사용하여 복원되었으며 완전한 기능으로 작동하도록 일관된 상태로 가져왔습니다.

주 팜의 일부인 각 노드에 대해 다음 단계를 수행하십시오.

1. Workflow Manager 1.0을 제거합니다.

2. Workflow Manager 1.0를 다시 설치합니다.

3. 복원 명령을 실행하는 프로세스에 설명된 대로 Add-SBHost와 Add-WFHost cmdlet을 실행합니다.

시나리오 3 - 재해가 응용 프로그램 서버에만 영향을 주는 경우

국지적인 재해로 인해 응용 프로그램 서버만 충돌하거나 손실되고 데이터베이스 서버는 상호 작용하는 경우가 있을 수 있습니다. 이는 데이터 센터에서 드물게 발생하는 시나리오이지만 이러한 재해의 경우 매우 쉽게 복구할 수 있습니다. 데이터베이스가 손실되지 않았으므로 주 위치를 계속 사용하고 이 기존 팜에 새 노드를 추가할 수 있습니다. 이유에 관계없이 보조 위치로 이동하려는 경우 보조 위치에 데이터베이스를 복사하고, 복구 단계를 수행할 때 새 데이터베이스를 참조할 수 있습니다.

응용 프로그램 서버 재해 시나리오에서 복구하려면 다음 단계를 수행하십시오.

1. 새 컴퓨터에 Workflow Manager 1.0을 설치합니다.

2. 다음 데이터베이스를 삭제합니다.

   • WFManagementDB

   • SbManagementDB

3. 복원 명령을 실행하는 프로세스에 설명된 절차를 따릅니다.

   참고

   이러한 단계를 수행할 때 데이터베이스를 이동한 경우 새 데이터베이스를 참조하고, 그렇지 않은 경우 원래 데이터베이스를 참조합니다.

이러한 단계를 완료하면 기존(또는 이동된) 데이터베이스를 사용하는 하나의 노드가 있는 팜이 생성됩니다. 필요한 경우 Workflow Manager 팜에 노드를 추가할 때와 동일한 방법으로 팜에 노드를 추가할 수 있습니다.

범위 복원

특정 범위를 실수로 삭제하거나 특정 범위의 콘텐츠가 손상되는 경우가 있을 수 있습니다. 범위의 콘텐츠가 순서대로 유지된 경우에는 Workflow Manager 데이터베이스의 백업이 보존되므로 이 범위의 콘텐츠를 백업 복사본에서만 복원할 수도 있습니다.

범위를 복원하면 다음 콘텐츠가 복원됩니다.

• 범위와 하위 범위(해당 구성 포함)

• 복원되는 범위 계층 내의 작업

• 범위 계층 내의 워크플로(해당 구성 포함)

• 범위 계층 내의 워크플로 인스턴스

  • 인스턴스는 마지막 지속성 지점에서 실행이 계속됩니다.

• 이러한 인스턴스에 해당하는 추적 기록

• 이 범위 계층 내의 워크플로에 대한 배달되지 않은 모든 메시지

다음 표에서는 범위 복원 작업에서 사용되는 주요 용어에 대해 설명합니다.

Workflow Manager에서는 이 시나리오를 지원하는 기능을 제공합니다. 다음은 범위 복원을 수행하기 위해 따라야 하는 단계입니다.

• 범위 복원 프로세스

• 범위 복원 고려 사항

범위 복원 프로세스

복원하려는 범위가 라이브 데이터베이스에 있어서는 안 됩니다. 따라서 백업에서 범위를 복원할 경우 라이브 데이터베이스에 이 범위의 손상된 복사본이 있으므로 이 손상된 범위를 라이브 데이터베이스에서 삭제해야 합니다.

1. SQL 데이터베이스 복원: 먼저 데이터베이스 백업 복원(SQL Server Management Studio)에 설명된 대로 백업을 사용하여 SQL 데이터베이스를 복원해야 합니다.

   중요
   백업 데이터베이스는 다른 서버에 복원해야 합니다. 라이브 데이터베이스를 덮어쓰지 마십시오.

2. 다음 매개 변수를 전달하여 Restore-WFScope PowerShell 명령을 실행합니다.

   • 복원할 범위의 경로

   • 백업 리소스 DB의 연결 문자열

   • 백업 인스턴스 DB의 연결 문자열

   • 백업이 만들어진 시간을 제공합니다. 대략적인 시간도 괜찮습니다. 데이터베이스가 여러 시점에서 백업된 경우 타임스탬프가 가장 오래된 백업을 이 단계의 입력으로 제공해야 합니다.

   • 게이트웨이 DB의 연결 문자열

   • 하나 이상의 컨테이너 데이터베이스의 연결 문자열. 일반적으로 컨테이너 데이터베이스는 하나만 유지됩니다. 서버에 여러 컨테이너 데이터베이스가 있는 경우 각 데이터베이스의 모든 연결 문자열을 이 cmdlet에 제공해야 합니다.

   이제 범위 및 콘텐츠가 라이브 데이터베이스에 복원되고 새로 복원된 백업 데이터베이스를 제거할 수 있게 됩니다.

범위 복원 고려 사항

범위 복원에서는 백업 및 복원된 데이터베이스에서 범위를 복원하지만 전체 복원 프로세스에 대해 다음 사항을 유의해야 합니다.

• 현재 라이브 데이터베이스의 이전 백업 복사본에서만 범위를 복원할 수 있습니다. 즉, Workflow Manager 팜 간에 특정 범위를 이동할 수 없습니다.

• 범위 복원에서는 범위와 해당 하위 범위에 속한 콘텐츠만 복원합니다. 이 범위의 하위 계층 외부에 있는 콘텐츠는 복원되지 않습니다.

• 작업 또는 워크플로에서 이 범위 계층 외부에 있는 다른 작업을 참조하는 경우, 즉 참조된 작업이 복원할 범위의 상위 범위에 속한 경우 참조된 작업은 이 작업의 일부로 복원되지 않습니다. 따라서 이러한 워크플로는 유효하지 않으며 이러한 워크플로의 인스턴스를 만들려고 하면 오류가 발생합니다.