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