Recover from catastrophic data loss (Recuperar de uma perda de dados catastrófica)

O Azure Stack Hub executa os serviços do Azure no seu datacenter e pode ser executado em ambientes tão pequenos como quatro nós instalados num único rack. Por outro lado, o Azure é executado em mais de 40 regiões em vários datacenters e várias zonas em cada região. Os recursos do utilizador podem abranger vários servidores, racks, datacenters e regiões. Com o Azure Stack Hub, atualmente só tem a opção de implementar toda a cloud num único rack. Esta limitação expõe a sua cloud ao risco de eventos catastróficos no seu datacenter ou falhas devido a erros importantes do produto. Quando ocorre um desastre, a instância do Azure Stack Hub fica offline. Todos os dados são potencialmente irrecuperáveis.

Consoante a causa principal da perda de dados, poderá ter de reparar um único serviço de infraestrutura ou restaurar toda a instância do Azure Stack Hub. Pode até ter de restaurar para hardware diferente na mesma localização ou numa localização diferente.

Este cenário aborda a recuperação de toda a instalação se ocorrer uma falha e a reimplementação da cloud privada.

Scenario Perda de Dados Considerações
Recuperar de perda catastrófica de dados devido a um desastre ou erro do produto. Todos os dados da infraestrutura, do utilizador e da aplicação. Pode restaurar para um OEM diferente.
Pode restaurar para uma geração diferente de hardware.
Pode restaurar para uma contagem diferente de nós de unidades de escala.
A aplicação do utilizador e os dados são protegidos separadamente dos dados da infraestrutura.

Fluxos de trabalho

O percurso de proteção do Azure Stack Hub começa com a cópia de segurança da infraestrutura e dos dados da aplicação/inquilino separadamente. Este documento aborda como proteger a infraestrutura.

Fluxo de trabalho de recuperação de dados do Azure Stack Hub – Implementação

Nos piores cenários em que todos os dados são perdidos, recuperar o Azure Stack Hub é o processo de restaurar os dados da infraestrutura exclusivos para essa implementação do Azure Stack Hub e todos os dados de utilizador.

Fluxo de trabalho de recuperação de dados do Azure Stack Hub – Reimplementação

Restauro

Se ocorrer uma perda catastrófica de dados, mas o hardware ainda estiver utilizável, é necessária a reimplementação do Azure Stack Hub. Durante a reimplementação, pode especificar a localização de armazenamento e as credenciais necessárias para aceder às cópias de segurança. Neste modo, não é necessário especificar os serviços que precisam de ser restaurados. O Controlador de Cópia de Segurança de Infraestrutura injeta o estado do plano de controlo como parte do fluxo de trabalho de implementação.

Se ocorrer um desastre que torna o hardware inutilizável, a reimplementação só é possível em hardware novo. A reimplementação pode demorar várias semanas enquanto o hardware de substituição é encomendado e chega ao datacenter. O restauro dos dados do plano de controlo é possível em qualquer altura. No entanto, o restauro não é suportado se a versão da instância reimplementada for mais do que uma versão maior do que a versão utilizada na última cópia de segurança.

Modo de Implementação Ponto de partida Ponto final
Instalação limpa Compilação de linha de base O OEM implementa o Azure Stack Hub e atualiza para a versão suportada mais recente.
Modo de recuperação Compilação de linha de base O OEM implementa o Azure Stack Hub no modo de recuperação e processa os requisitos de correspondência de versões com base na cópia de segurança mais recente disponível. O OEM conclui a implementação ao atualizar para a versão suportada mais recente.

Dados em cópias de segurança

O Azure Stack Hub suporta um tipo de implementação chamado modo de recuperação na cloud. Este modo só é utilizado se optar por recuperar o Azure Stack Hub depois de um desastre ou erro do produto ter tornado a solução irrecuperável. Este modo de implementação não recupera nenhum dos dados de utilizador armazenados na solução. O âmbito deste modo de implementação está limitado ao restauro dos seguintes dados:

  • Entradas de implementação
  • Dados internos do serviço de identidade
  • Configuração de identificação federada (implementações do ADFS).
  • Certificados de raiz utilizados pela autoridade de certificação interna.
  • O Azure Resource Manager dados de utilizador de configuração, tais como subscrições, planos, ofertas, grupos de recursos, etiquetas, quotas de armazenamento, quotas de rede e recursos de computação.
  • Key Vault segredos e cofres.
  • Atribuições de políticas RBAC e atribuições de funções.

Nenhum dos recursos de Infraestrutura como Serviço (IaaS) ou Plataforma como Serviço (PaaS) do utilizador é recuperado durante a implementação. Estas perdas incluem VMs IaaS, contas de armazenamento, blobs, tabelas, configuração de rede, etc. O objetivo da recuperação na cloud é garantir que os seus operadores e utilizadores podem voltar a iniciar sessão no portal após a conclusão da implementação. Os utilizadores que iniciarem sessão novamente não verão nenhum dos respetivos recursos. Os utilizadores têm as suas subscrições restauradas e, juntamente com isso, os planos, ofertas e políticas originais definidos pelo administrador. Os utilizadores que iniciam sessão novamente no sistema operam sob as mesmas restrições impostas pela solução original antes do desastre. Após a conclusão da recuperação na cloud, o operador pode restaurar manualmente os RPs de valor acrescentado e de terceiros e os dados associados.

Validar cópias de segurança

Pode utilizar o ASDK para testar uma cópia de segurança para confirmar que os dados são válidos e utilizáveis. Para obter mais informações, veja Utilizar o ASDK para validar uma cópia de segurança do Azure Stack.

Passos seguintes

Saiba mais sobre as melhores práticas para utilizar o Serviço de Cópia de Segurança da Infraestrutura.