Importando volumes copiados de sombra transportável

Às vezes, é desejável criar uma cópia de sombra em um sistema, mas usar a cópia de sombra em um segundo sistema.

Considere o caso em que os dados a serem armazenados em backup normalmente são gerenciados por um determinado sistema (systemOne) durante operações normais e que esses dados são armazenados fisicamente em uma matriz de armazenamento ou em um dispositivo.

Para minimizar qualquer interrupção no systemOne (porque as operações de backup podem ser intensivas em recursos), é desejável executar o backup usando systemTwo, um servidor de backup, que tem acesso à mesma matriz de armazenamento que systemOne.

Para garantir uma cópia de sombra adequada, cooperando com os gravadores no systemOne e preservando o estado adequadamente para tarefas em andamento, a cópia de sombra deve ser executada pelo systemOne.

Portanto, systemOne deve criar uma cópia de sombra transportável, que o systemTwo importará em seguida.

Windows Server 2003, Edição Standard, Windows Server 2003, Web Edition e Windows XP: não há suporte para conjuntos de cópia de sombra transportável. Todas as edições do Windows Server 2003 com Service Pack 1 (SP1) dão suporte a conjuntos de cópias de sombra transportáveis.

Um exemplo típico de importação de uma cópia de sombra transportável pode continuar da seguinte maneira:

1. Inicialmente, a LUN (unidade lógica) fornecida pela matriz de armazenamento é montada como um volume no systemOne (por exemplo, F:).

2. Um solicitante que está em execução no systemOne instancia uma instância de IVssBackupComponents e prossegue como se estivesse se preparando para um backup. (Confira a visão geral de inicialização Backup, visão geral da fase de descoberta de Backup e visão geral das tarefas de pré-Backup para obter mais informações.)

3. O solicitante no systemOne modifica o contexto de cópia de sombra que normalmente é usado para a operação de backup local (VSS_CTX_APP_BACKUP) para indicar que uma cópia de sombra transportável será criada (VSS_VOLSNAP_ATTR_TRANSPORTABLE). O atributo transportável também pode ser adicionado a outros contextos de cópia de sombra.

4. Com um contexto de cópia de sombra de VSS_CTX_APP_BACKUP | VSS_VOLSNAP_ATTR_TRANSPORTABLE, o solicitante que está no systemOne cria uma cópia de sombra chamando IVssBackupComponents::D oSnapshotSet.

5. O SystemOne usa IVssBackupComponents::SaveAsXML para salvar o estado atual do documento de componentes Backup e IVssExamineWriterMetadata::SaveAsXML para salvar os documentos de metadados do gravador de cada gravador. As cadeias de caracteres XML que contêm esses documentos são disponibilizadas para um solicitante em execução no systemTwo.

   O solicitante transfere o documento Backup Components para systemTwo.

   Observe que o solicitante no systemOne não libera sua instância de IVssBackupComponents neste momento se a finalidade da cópia de sombra for para backup. A interface deve permanecer aberta até que o systemTwo conclua com êxito suas operações de backup. Somente o solicitante deve emitir um evento BackupComplete , pois alguns gravadores truncarão logs e farão outro trabalho após um backup bem-sucedido. Se o objetivo da cópia de sombra for a mineração de dados ou outras finalidades, a interface poderá ser fechada nesta etapa.

6. O solicitante no systemTwo então chama IVssBackupComponents::ImportSnapshots para obter acesso à cópia de sombra criada pelo solicitante no systemOne.

   Observação

   O solicitante é responsável por serializar a operação de importação de cópia de sombra. Além disso, se a chamada para IVssBackupComponents::ImportSnapshots falhar, o VSS não limpará LUNs por conta própria. O solicitante precisa iniciar a limpeza de LUNs.

    

7. O solicitante no systemTwo prossegue com o backup do material copiado de sombra exatamente como se estivesse fazendo backup de uma cópia de sombra que ele criou por si só (consulte Visão geral da Backup Real dos Arquivos).

   O solicitante no systemTwo obtém o objeto de dispositivo da cópia de sombra usando IVssBackupComponents::GetSnapshotProperties na cópia de sombra importada e acrescenta isso ao início dos caminhos de arquivo originais que foram obtidos dos metadados para acessar arquivos a serem copiados.

8. Depois de usar a cópia de sombra, o solicitante no systemTwo deve excluir a cópia de sombra. Assim como acontece com cópias de sombra não transportáveis, se o contexto de cópia de sombra indicar cópias de sombra de versão automática (por exemplo, VSS_CTX_BACKUP), a liberação dos IVssBackupComponents no systemTwo fará com que o serviço VSS exclua a cópia de sombra. Caso contrário, se o contexto indicar uma cópia de sombra persistente (por exemplo, VSS_CTX_APP_ROLLBACK), o solicitante no systemTwo deverá excluir explicitamente a cópia de sombra.

   Em seguida, o solicitante no systemTwo sinaliza ao solicitante no systemOne que ele terminou com o backup da cópia de sombra transportável.

9. Depois que o solicitante no systemOne receber uma notificação de que o solicitante no sistemaTwo concluiu o backup da cópia de sombra transportável, ele notifica os gravadores em seu sistema gerando um evento BackupComplete com uma chamada para IVssBackupComponents::BackupComplete. Neste ponto, o solicitante no systemOne está livre para liberar sua instância de IVssBackupComponents.

Cópias de sombra transportáveis em um cluster: As cópias de sombra transportáveis devem ser importadas de fora do cluster, desde que o volume original seja montado dentro do cluster. Para obter informações sobre como implementar uma recuperação rápida em um cluster, consulte Recuperação Rápida usando volumes copiados de sombra transportáveis.