Ripristino di emergenza e ripristino di un ambito in Workflow Manager 1.0

 

In questo argomento viene fornita una panoramica delle opzioni e delle procedure relative al ripristino di emergenza per Progettazione flussi di lavoro 1.0. Vengono illustrate le procedure per la gestione degli errori del server di database e del server applicazioni e le procedure per il ripristino di un ambito danneggiato o eliminato.

• Ripristino di emergenza

• Ripristino dell'ambito

Ripristino di emergenza

In Progettazione flussi di lavoro 1.0 è possibile effettuare alcune operazioni preliminari per la gestione di scenari di emergenza. In questo argomento il termine emergenza viene utilizzato per indicare un evento che ha per effetto la perdita di informazioni importanti, l'eliminazione di dati e altri tipi di problemi gravi. Nel caso di un prodotto server, un'emergenza è un evento che ha come risultato l'interruzione prolungata della disponibilità del server e che può essere accompagnato da vari gradi di perdita del cluster originale configurato per il server o di parte di tale cluster.

Confronto tra ripristino di emergenza e disponibilità elevata

Il concetto di ripristino di emergenza è in genere correlato a quello di disponibilità elevata. La disponibilità elevata consiste nel mantenere il servizio altamente disponibile in circostanze normali, mediante la creazione di una quantità sufficiente di ridondanze nel sistema e l'eliminazione di singoli punti di errore. Il ripristino di emergenza consiste invece nel garantire lo stesso livello di servizio in caso di arresto del servizio principale dovuto a circostanze esterne, ad esempio un disastro naturale.

Modello generale di ripristino di emergenza

La procedura relativa alle operazioni preliminari e alla gestione di un'emergenza può essere suddivisa in varie fasi, come descritto nelle seguenti sezioni. In questo diagramma viene illustrata ciascuna fase e vengono descritti i compiti dell'utente rispetto alle funzionalità fornite da Gestione flusso di lavoro.

Tipi di scenari di emergenza per Workflow Manager

Nel caso di Gestione flusso di lavoro è possibile che si verifichino vari tipi di scenari di emergenza per i quali è opportuno adottare misure preventive.

1. Emergenza che determina la perdita di uno o più database utilizzati da Gestione flusso di lavoro.

   1. Questo scenario può essere causato da un guasto dell'hardware o da un'emergenza a livello di data center.

2. Emergenza che determina la perdita dei server applicazioni in cui sono stati distribuiti i file binari di Gestione flusso di lavoro.

3. Emergenza che determina la perdita dell'intero cluster, in cui vengono persi i dati dei server applicazioni e dei database.

Poiché Gestione flusso di lavoro contiene informazioni correlate ai flussi di lavoro, alle attività e alle istanze dell'utente, una parte fondamentale del ripristino di emergenza di Gestione flusso di lavoro consiste nella capacità di ripristinare i dati di un'installazione di Gestione flusso di lavoro mediante copie di backup. Nella maggior parte di questi scenari, quindi, il ripristino di emergenza consiste principalmente nel ripristinare i dati dalle copie di backup e nell'assicurarsi che tali dati siano coerenti con i vari sottosistemi di Gestione flusso di lavoro.

Operazioni preliminari al ripristino di emergenza

Il ripristino di emergenza implica l'esecuzione di alcune operazioni preliminari alla gestione di un'eventuale emergenza. Per Gestione flusso di lavoro può essere opportuno conservare i dati relativi ad attività, istanze e flussi di lavoro anche nel caso in cui si verifichi un'emergenza.

Gestione flusso di lavoro archivia tutti i dati nei database di SQL Server. Di conseguenza, un prerequisito fondamentale per il ripristino di emergenza è l'impostazione periodica di backup e/o soluzioni di ridondanza dei dati in modo che, nell'eventualità di un'emergenza del data center, sia disponibile una copia recente del database da utilizzare per il ripristino dell'installazione di Gestione flusso di lavoro.

L'installazione di Gestione flusso di lavoro utilizza i database elencati di seguito.

Nome database	Descrizione
WFManagementDB	Database di gestione della farm di Gestione flusso di lavoro
SbManagementDB	Database di gestione della farm di Bus di servizio
WFResourceManagementDB	Archivio di gestione delle risorse di Gestione flusso di lavoro
WFInstanceManagementDB	Archivio di gestione dell'istanza di Gestione flusso di lavoro
SbGatewayDatabase	Database del gateway di Bus di servizio
SBMessageContainer01 - n	Database contenitore messaggi di Bus di servizio

A seconda dell'importanza dei dati del flusso di lavoro nell'installazione di Gestione flusso di lavoro, è possibile scegliere tra diverse opzioni di preparazione al ripristino di emergenza. Poiché tutti i dati di Gestione flusso di lavoro vengono archiviati nei database di SQL Server sopra indicati, le strategie di backup e disponibilità elevata basate su SQL Server dovrebbero essere applicate anche a Gestione flusso di lavoro.

Per ulteriori informazioni sull'implementazione della disponibilità elevata e del ripristino di emergenza per SQL Server, vedere Selezione di una soluzione a disponibilità elevata e Descrizione delle opzioni di ripristino di emergenza per Microsoft SQL Server.

Nota

Indipendentemente dall'opzione scelta per il backup di questi database, assicurarsi che i backup non siano stati eseguiti a una distanza di tempo eccessiva. È ad esempio probabile che Gestione flusso di lavoro non venga ripristinato correttamente se i backup dei singoli database sono stati eseguiti a diversi giorni o ore di distanza l'uno dall'altro.

Nel seguente diagramma sono elencati i diversi componenti di un'installazione di Gestione flusso di lavoro.

Dal punto di vista dell'amministratore della server farm, due parti di Gestione flusso di lavoro possono essere danneggiate nel caso si verifichi uno scenario di emergenza: uno o più database oppure uno o più nodi di server applicazioni. Possono essere presenti diverse combinazioni di server di database e server applicazioni inattivi, ma in linea generale è possibile identificare i punti di errore nel livello dati e nel livello applicazione.

• Livello dati

• Livello di calcolo (livello di flusso di lavoro o messaggistica)

Livello dati

Progettazione flussi di lavoro 1.0 archivia i dati nei seguenti database di SQL Server.

Nome database	Descrizione
WFManagementDB	Database di gestione della farm di Gestione flusso di lavoro
SbManagementDB	Database di gestione della farm di Bus di servizio
WFResourceManagementDB	Archivio di gestione delle risorse di Gestione flusso di lavoro
WFInstanceManagementDB	Archivio di gestione dell'istanza di Gestione flusso di lavoro
SbGatewayDatabase	Database del gateway di Bus di servizio
SBMessageContainer01 - n	Database contenitore messaggi di Bus di servizio

Per il livello dati sono previste tre importanti attività associate al ripristino di emergenza:

1. Preparazione: assicurarsi di aver adottato la corretta strategia di backup o di replica per i database, in modo da evitare la perdita di dati nel caso in cui si verifichi un'emergenza che interessa i database.

   Per eseguire il ripristino da una situazione di emergenza, è necessario adottare le opportune misure preventive. In particolare, nel caso di emergenze che determinano la perdita di database, è necessario avere messo in atto una procedura per l'archiviazione di una copia dei dati in una posizione diversa. Poiché si tratta di database SQL standard, si consiglia di utilizzare tecniche di archiviazione SQL consolidate, ad esempio:

   1. Mirroring SQL

   2. Replica SQL

   3. Backup semplici e una combinazione di backup e log shipping

   È possibile scegliere una di queste tecniche a seconda del tipo di azienda e del livello di fedeltà dei dati desiderato tra i database di backup e i database primari.

   L'amministratore della farm di Gestione flusso di lavoro deve quindi creare copie di backup dei database utilizzando la strategia di backup adatta alle proprie esigenze.Gestione flusso di lavoro non fornisce alcun supporto per la creazione dei database di backup.

2. Ripristino dei database di backup

   Per eseguire il ripristino dei database di backup, è necessario utilizzare uno strumento o un meccanismo adatto alla strategia di replica dei dati adottata. Per il ripristino dei database SQL sono disponibili strumenti e tecniche SQL standard.

3. Ripristino della farm di Gestione flusso di lavoro

   Questo passaggio consiste nel verificare l'avvenuto ripristino di uno stato corrente di Gestione flusso di lavoro e il relativo funzionamento.Gestione flusso di lavoro fornisce gli script PowerShell necessari e le istruzioni per l'esecuzione di questo passaggio.

Livello di calcolo (livello di flusso di lavoro o messaggistica)

In caso di scenari di ripristino di emergenza è possibile creare una farm secondaria in una posizione diversa, prima o dopo il caso di emergenza. È possibile prendere in considerazione tre modelli.

1. Cold Standby

   In questo modello è possibile ricreare la farm dopo che si è verificata l'emergenza. Questo modello prevede tempi di ripristino della farm più lunghi poiché è necessario eseguire il provisioning di nuovi nodi di calcolo e nuove installazioni di Gestione flusso di lavoro in tali nodi.

2. Warm Standby

   È in genere opportuno scegliere questo modello se si desidera accertarsi che la farm secondaria venga creata e testata anche prima di un'eventuale emergenza. In questo modello viene eseguito il provisioning dei nodi di calcolo nella nuova farm prima che si verifichi l'emergenza. Una volta stabilita l'associazione del database, la nuova farm viene puntata ai database secondari.

   Dopo aver configurato la nuova farm, si disattivano i nodi di calcolo per evitare che rimangano inattivi. Come parte del ripristino di emergenza, è necessario eseguire gli script di coerenza dei database forniti da Workflow Manager.

   Nota

   In questo modello si presuppone che i nuovi database contenitori di Bus di servizio non vengano creati nel database primario dopo la configurazione iniziale. Se viene creato un nuovo database contenitore di Bus di servizio nel database primario, durante il ripristino è necessario eseguire ulteriori passaggi.

3. Hot Standby

   Questo modello offre una soluzione più efficace rispetto al modello Warm Standby poiché i nodi di calcolo possono essere attivi. Questo consente infatti di ridurre i tempi di ripristino dalla situazione di emergenza.

   Avviso

   Il modello Hot Standby non è supportato da Gestione flusso di lavoro.

Procedura di ripristino di emergenza

In questa sezione viene illustrata la procedura effettiva per l'esecuzione del ripristino di emergenza per i vari scenari di emergenza descritti in precedenza. A livello generale, per ripristinare la farm è consigliabile eseguire il ripristino dei database necessari da una copia di backup, ottenuta mediante una delle tecniche standard di SQL Server, e utilizzare i cmdlet di ripristino forniti da Gestione flusso di lavoro.

Nota

Nei seguenti passaggi viene descritta la procedura per l'eliminazione dei database di gestione della farm precedenti e per la creazione di nuovi database.

Procedura per l'esecuzione dei comandi di ripristino

1. Esportare sia il certificato farm di Service Bus con chiave privata sia il certificato di crittografia di Service Bus con chiave privata. Importarli entrambi nella cartella Computer locale\Personale del nuovo server. Importare anche il certificato (o i certificati) radice nella cartella Computer locale\Autorità radice attendibile del nuovo server. È possibile identificare il certificato farm e il certificato di crittografia dall'output di Get-SBFarm.

   Nota

   L'importazione funziona solo se i certificati di crittografia ServiceBus precedenti sul vecchio server WFM/SB erano: Generati automaticamente durante la configurazione della farm obsoleta con lo strumento di configurazione. In alternativa, nel caso in cui sia stato usato un certificato personalizzato per ServiceBus nel vecchio ambiente, è necessario avere certificati con caratteri jolly per il proprio dominio; in altre parole, il campo "Nome alternativo soggetto" nel certificato è stato creato con un valore come *.nomedominio.com. Se non viene eseguita l'importazione del certificato ServiceBus precedente, il cmdlet Restore-WFFarm nei passaggi seguenti non riuscirà, producendo un errore simile al seguente. 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. Nel nuovo computer aprire una finestra di PowerShell con privilegi elevati (come amministratore RunAs).

3. Chiamare il cmdlet Restore-SBFarm passando i parametri seguenti. Questo cmdlet crea un nuovo database di gestione della farm di Bus di servizio. Il database di gestione della farm di Bus di servizio precedente può quindi essere eliminato.

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

   Nota

   Se sono stati usati certificati con caratteri jolly personalizzati nella vecchia configurazione di ServiceBus e due certificati differenti per FarmCertificate ed EncryptionCertificate, sarà necessario importarli entrambi su ciascun nuovo nodo, fornendo di conseguenza i parametri FarmCertificateThumbprint e EncryptionCertificateThumbprint nel cmdlet sopra citato.

   Di seguito è riportato un frammento di esempio relativo alla chiamata di 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. Chiamare il cmdlet Restore-SBGateway su uno dei nodi della farm con i parametri seguenti.

   Parametro	Descrizione
   SBFarmDBConnectionString	Stringa di connessione del database della farm del bus di servizio creato nel passaggio precedente.
   GatewayDBConnectionString	Stringa di connessione del database gateway ripristinato.

   Di seguito è riportato un frammento di esempio relativo alla chiamata di 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. Per ciascun database contenitore, chiamare il cmdlet Restore-SBMessageContainer con i parametri seguenti. Eseguire questo cmdlet su uno dei computer della farm.

   Parametro	Descrizione
   SBFarmDBConnectionString	Stringa di connessione del database della farm del bus di servizio creato nel passaggio precedente.
   ContainerDBConnectionString	Stringa di connessione del database contenitore.
   Id	ID del contenitore di messaggi ripristinato. Ottenere l'ID del contenitore di messaggi ripristinato dalla tabella [dbo].[ContainersTable] del database del gateway, che contiene gli ID, le stringhe di connessione, i nomi di server di database e i nomi di database di tutti i contenitori di messaggi. Selezionare l'ID del contenitore il cui nome di database corrisponde a quello del contenitore originale.

   Il frammento di esempio seguente illustra la chiamata del cmdlet Restore-SBMessageContainer.

   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. Chiamare il cmdlet Add-SBHost e passare i parametri seguenti.

   Parametro	Descrizione
   SBFarmDBConnectionString	Stringa di connessione del database della farm del bus di servizio creato nel passaggio precedente.
   CertificateAutoGenerationKey	Chiave utilizzata per la generazione automatica dei certificati di Service Bus.
   RunAsPassword	SecureString che contiene la password dell'account con cui vengono eseguiti i processi di Service Bus.
   EnableFirewallRules	True se è necessario aggiornare le regole firewall dell'host per consentire ai dati di Service Bus di attraversare il firewall. In caso contrario False.

   Nell'esempio riportato di seguito viene illustrato come richiamare il 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. Chiamare il cmdlet Restore-WFFarm usando le stringhe di connessione del database di gestione delle risorse e delle istanze.

   Nell'esempio riportato di seguito viene illustrato come richiamare il 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
   

   Nota

   InstanceStateSyncTime deve rispettare il formato esatto specificato nell'esempio precedente. ConsistencyVerifierLogPath deve corrispondere al percorso di una cartella in cui il cmdlet registra i log relativi al processo di ripristino.

8. Chiamare il cmdlet Add-WFHost.

   Nell'esempio riportato di seguito viene illustrato come richiamare il cmdlet.

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

Scenario 1 - L'emergenza interessa l'intero cluster

In questo scenario l'intero cluster è interessato da uno scenario di emergenza. Per eseguire il ripristino, è necessario rigenerare l'intero cluster utilizzando i backup più recenti.

1. Installare Progettazione flussi di lavoro 1.0 in un nuovo computer.

   Nota

   Installare Progettazione flussi di lavoro 1.0 mediante il programma di installazione, ma non iniziare la configurazione della farm.

2. Ripristinare le copie di backup dei database primari mediante le funzionalità di ripristino di SQL Server. Questo passaggio può variare in base alla soluzione di backup adottata.

   È necessario ripristinare solo i seguenti database.

   • WFResourceManagementDB

   • WFInstanceManagementDB

   • SbGatewayDatabase

   • SBMessageContainer*

   Importante
   Non ripristinare i database WFManagementDB e SbManagementDb perché verranno rigenerati automaticamente in fase di ripristino.

3. Seguire i passaggi descritti in Procedura per l'esecuzione dei comandi di ripristino.

Scenario 2 - L'emergenza interessa solo i database di SQL Server

In questo caso, uno o più database utilizzati da Gestione flusso di lavoro risultano persi o inaccessibili. Questo scenario può essere causato da un guasto dell'hardware o da qualsiasi altro tipo di emergenza localizzata nei computer con SQL Server.

Nota

È possibile seguire i passaggi descritti in questo scenario anche per effettuare la migrazione da un data center a un altro mediante il trasferimento della copia di backup più recente del database al nuovo data center.

1. Disinstallare Progettazione flussi di lavoro 1.0 da uno dei nodi di server applicazioni esistente.

2. Installare nuovamente Progettazione flussi di lavoro 1.0 nel server seguendo il passaggio precedente.

   Nota

   Installare Gestione flusso di lavoro mediante il programma di installazione, ma non iniziare la configurazione della farm.

3. Ripristinare le copie di backup dei database primari mediante le funzionalità di ripristino di SQL Server. Questo passaggio può variare in base alla soluzione di backup adottata. A seconda del tipo di situazione di emergenza, è possibile eseguire il ripristino nel computer con SQL Server esistente o in uno differente.

4. Seguire i passaggi descritti in Procedura per l'esecuzione dei comandi di ripristino.

Dopo aver completato questi passaggi, sarà disponibile una farm con un solo nodo che utilizza i database esistenti. Questa farm è stata ripristinata con le copie di backup dei database originali ed è stata portata a uno stato coerente per consentirne il corretto funzionamento.

Per ciascun nodo della farm primaria effettuare i seguenti passaggi.

1. Disinstallare Progettazione flussi di lavoro 1.0.

2. Reinstallare Progettazione flussi di lavoro 1.0.

3. Eseguire i cmdlet Add-SBHost e Add-WFHost come descritto in Procedura per l'esecuzione dei comandi di ripristino.

Scenario 3 - L'emergenza interessa solo i server applicazioni

È talvolta possibile che, a causa di un'emergenza localizzata, l'arresto e la perdita di dati interessino solo i server applicazioni, lasciando intatti i server di database. Anche se si tratta di uno scenario di emergenza insolito per un data center, è relativamente semplice eseguire il ripristino. Poiché l'emergenza non ha causato la perdita dei database, è possibile continuare a utilizzare la posizione primaria e aggiungere nuovi nodi alla farm esistente. Se per qualsiasi motivo si preferisce passare alla posizione secondaria, è possibile eseguire una copia dei database in tale posizione e fare riferimento ai nuovi database durante l'esecuzione dei passaggi di ripristino.

Per eseguire il ripristino da scenari di emergenza relativi ai server applicazioni, effettuare i seguenti passaggi.

1. Installare Progettazione flussi di lavoro 1.0 in un nuovo computer.

2. Rimuovere i seguenti database.

   • WFManagementDB

   • SbManagementDB

3. Seguire la procedura descritta in Procedura per l'esecuzione dei comandi di ripristino.

   Nota

   Se i database sono stati spostati, fare riferimento ai nuovi database durante l'esecuzione di questi passaggi, altrimenti fare riferimento ai database originali.

Dopo aver completato questi passaggi, sarà disponibile una farm con un solo nodo che utilizza i database esistenti (o spostati). È inoltre possibile aggiungere altri nodi alla farm seguendo la stessa procedura utilizzata per l'aggiunta di nodi a una farm di Workflow Manager.

Ripristino dell'ambito

Talvolta possono verificarsi situazioni in cui un ambito è stato accidentalmente eliminato o il contenuto di un ambito risulta danneggiato. Se si dispone di una copia di backup dei database di Gestione flusso di lavoro creata quando il contenuto dell'ambito era intatto, è possibile ripristinare il contenuto dell'ambito specifico in base a tale copia.

Se si esegue il ripristino di un ambito, vengono ripristinati i contenuti elencati di seguito.

• Ambiti e ambiti figlio con le relative configurazioni

• Attività incluse nella gerarchia dell'ambito ripristinata

• Flussi di lavoro inclusi nella gerarchia dell'ambito con le relative configurazioni

• Istanze dei flussi di lavoro nella gerarchia dell'ambito

  • L'esecuzione delle istanze verrà ripresa a partire dall'ultimo punto di persistenza.

• Record di rilevamento corrispondenti a istanze

• Messaggi non recapitati per i flussi di lavoro nella gerarchia dell'ambito corrente

Nota

Quando si elimina un ambito, in pochi minuti vengono rimossi anche i relativi contenuti, tra cui le istanze e i record di rilevamento. Il processo è asincrono.

Nella seguente tabella vengono illustrati i termini chiave utilizzati durante un'operazione di ripristino di un ambito.

Termine	Descrizione
Database di backup	Si presuppone che l'utente abbia eseguito un backup di tutti i database utilizzati da Gestione flusso di lavoro e che l'ambito da ripristinare sia disponibile in questa copia di backup. In altri termini, questo database ha la funzione di database di origine per l'esecuzione della copia del contenuto dell'ambito.
Database attivi	Questo termine fa riferimento ai database attualmente attivi nella farm di Gestione flusso di lavoro. In altri termini, questo è il database di destinazione della procedura di ripristino dell'ambito.
Ambito da ripristinare	All'interno della gerarchia è possibile specificare qualsiasi ambito da ripristinare a partire da un database di backup.

In Gestione flusso di lavoro sono disponibili funzionalità per l'abilitazione di questo scenario. Di seguito vengono illustrati i passaggi da seguire per effettuare il ripristino dell'ambito.

• Procedura per il ripristino dell'ambito

• Considerazioni relative all'esecuzione del ripristino dell'ambito

Procedura per il ripristino dell'ambito

È necessario che l'ambito da ripristinare non sia presente tra i database attivi. Di conseguenza, se si esegue il ripristino di un ambito da una copia di backup perché nel database attivo è presente una copia danneggiata di tale ambito, è necessario eliminare quest'ultima dal database attivo.

1. Ripristinare i database di SQL Il primo passaggio consiste nel ripristinare i database SQL usando le copie di backup, come descritto in Ripristino di un backup del database (SQL Server Management Studio).

   Importante
   È necessario ripristinare i database di backup in un server differente. Non sovrascrivere i database attivi.

2. Eseguire il comando Restore-WFScope di PowerShell passando i parametri seguenti:

   • Percorso dell'ambito da ripristinare

   • Stringa di connessione del database delle risorse di backup

   • Stringa di connessione database delle istanze di backup

   • Specificare una data approssimativa di creazione dei backup. Se i backup dei database sono stati eseguiti in momenti diversi, assicurarsi che il timestamp meno recente venga specificato come input in questo passaggio.

   • Stringa di connessione del database del gateway

   • Stringa di connessione di uno o più database contenitori. È in genere presente un singolo database contenitore. Se nel server sono presenti più database contenitori, assicurarsi di fornire al cmdlet tutte queste stringhe di connessione.

   A questo punto è necessario ripristinare l'ambito e il contenuto nel database attivo, quindi rimuovere i nuovi database di backup ripristinati.

Considerazioni relative all'esecuzione del ripristino dell'ambito

La procedura di ripristino di un ambito consiste nel ripristinare la copia di backup di uno o più database, ma è necessario tenere presenti le seguenti considerazioni relative al processo globale di ripristino.

• È possibile ripristinare solo un ambito da una copia di backup precedente del database attivo corrente. In altri termini, non è possibile spostare un ambito specifico da una farm di Gestione flusso di lavoro a un'altra.

• Con il ripristino dell'ambito viene ripristinato solo il contenuto dell'ambito e dei relativi elementi figlio. Non viene, invece, eseguito il ripristino del contenuto esterno alla gerarchia degli elementi figlio dell'ambito.

• Se un'attività o un flusso di lavoro fa riferimento a un'attività esterna alla gerarchia dell'ambito, ossia l'attività a cui viene fatto riferimento si trova in un ambito padre superiore a quello ripristinato, l'attività a cui viene fatto riferimento non viene ripristinata nel corso di questa operazione. Di conseguenza, i flussi di lavoro non saranno più validi e gli eventuali tentativi di creazione di istanze di tali flussi di lavoro restituiranno errori.