Recuperar arquivos de um backup de máquina virtual do Azure
Cuidado
Este artigo faz referência ao CentOS, uma distribuição Linux que está em status de fim do serviço (EOL). Considere seu uso e planejamento adequadamente. Para obter mais informações, confira as Diretrizes de Fim do Suporte do CentOS.
O Backup do Azure fornece a capacidade de restaurar máquinas virtuais (VMs) do Azure e discos de backups de máquina virtual do Azure, também conhecido como pontos de recuperação. Este artigo explica como recuperar arquivos e pastas de um backup de VM do Azure. A restauração de arquivos e pastas está disponível somente para VMs do Azure implantadas usando o modelo Gerenciador de Recursos e protegidas para um cofre de Serviços de Recuperação.
Observação
Esse recurso está disponível para máquinas virtuais do Azure implantadas usando o modelo do Resource Manager e protegidas em um cofre dos Serviços de Recuperação. Não há suporte para a recuperação de arquivos de backup criptografado de VM.
Etapa 1: gerar e fazer o download do script para navegar e recuperar arquivos
Para restaurar arquivos ou pastas no ponto de recuperação, acesse a máquina virtual e execute as seguintes etapas:
Entre no portal do Azure e no painel esquerdo, selecione Máquinas virtuais. Na lista de máquinas virtuais, selecione a máquina virtual para abrir o painel da máquina virtual.
No menu da máquina virtual, selecione Backup para abrir o painel de Backup.
No menu do painel de Backup, selecione Recuperação de Arquivo.
32O menu Recuperação de Arquivo é aberto.
Importante
Os usuários devem observar as limitações de desempenho desse recurso. Conforme indicado na seção de notas de rodapé da folha acima, esse recurso deve ser usado quando o tamanho total da recuperação é de 10 GB ou menos. As velocidades de transferência de dados esperadas são de cerca de 1 GB por hora.
No menu suspenso Selecionar ponto de recuperação, selecione o ponto de recuperação que contém os arquivos desejados. Por padrão, o ponto de recuperação mais recente já está selecionado.
Selecione Baixar Executável (para VMs do Microsoft Azure) ou Fazer Download do Script (para VMs Linux do Azure, um script Python é gerado) e faça o download do software usado para copiar os arquivos do ponto de recuperação.
O Azure baixa o arquivo executável ou o script para o computador local.
Para executar o arquivo executável ou o script como um administrador, recomendamos salvar o arquivo baixado no seu computador.
O arquivo executável ou o script é protegido por senha e requer uma senha. No menu Recuperação de Arquivo, selecione o botão copiar para carregar a senha na memória.
Etapa 2: certifique-se de que o computador atende aos requisitos antes de executar o script
Depois de fazer o download do script com sucesso, certifique-se de que você tem o computador certo para executá-lo. A VM na qual você vai executar o script não deve ter nenhuma das configurações sem suporte a seguir. Se tiver, escolha um computador alternativo que atenda aos requisitos.
Discos dinâmicos
Você não pode executar o script em uma VM com qualquer uma das seguintes características: escolha outro computador
- Volumes que abrangem vários discos (volumes distribuídos e estendidos).
- Volumes tolerantes a falhas (volumes RAID-5 e espelhados) em discos dinâmicos.
Espaços de Armazenamento do Windows
Você não pode executar o arquivo executável baixado na mesma VM com backup se ela tiver Espaços de Armazenamento do Windows. Escolha outro computador.
Backups de máquinas virtuais com discos grandes
Se o computador com backup tiver um grande número de discos (>16) ou discos grandes (> 4 TB cada), não é recomendável executar o script no mesmo computador para restauração, pois ele terá um impacto significativo na VM. Em vez disso, é recomendável ter uma VM separada somente para recuperação de arquivos (VMs D2v3 de VM do Azure) e desligá-la quando não for necessário.
Consulte os requisitos para restaurar arquivos de VMs com backup com disco grande:
Sistema operacional Windows
Sistema operacional Linux
Depois de escolher o computador correto para executar o script de ILR, certifique-se de que ele atende aos requisitos de sistema operacional e aos requisitos de acesso.
Etapa 3: requisitos do sistema operacional para executar o script com sucesso
A VM na qual você deseja executar o script baixado deve atender aos requisitos a seguir.
Para Windows 10
A tabela a seguir mostra a compatibilidade entre os sistemas operacionais de computador e servidor. Ao recuperar arquivos, você não poderá restaurar arquivos para uma versão anterior ou uma versão futura do sistema operacional. Por exemplo, você não pode restaurar um arquivo de uma VM do Windows Server 2016 para um computador Windows Server 2012 ou Windows 8. É possível restaurar arquivos de uma VM para o mesmo sistema operacional do servidor ou para o sistema operacional compatível do cliente.
| Sistema operacional de servidor | Sistema operacional de cliente compatível |
|---|---|
| Windows Server 2022 | Windows 11 e Windows 10 |
| Windows Server 2019 | Windows 10 |
| Windows Server 2016 | Windows 10 |
| Windows Server 2012 R2 | Windows 8.1 |
| Windows Server 2012 | Windows 8 |
| Windows Server 2008 R2 | Windows 7 |
Para Sistema operacional Linux
No Linux, o SO do computador utilizado para restaurar arquivos deve fornecer suporte para o sistema de arquivos da máquina virtual protegida. Ao selecionar um computador para executar o script, certifique-se de que o computador possui um SO compatível e usa uma das versões identificadas na tabela a seguir:
| Sistema operacional Linux | Versões |
|---|---|
| Ubuntu | 12.04 e acima |
| CentOS | 6.5 e acima |
| RHEL | 6.7 e acima |
| Debian | 7 e acima |
| Oracle Linux | 6.4 e acima |
| SLES | 12 e acima |
| openSUSE | 42.2 e acima |
Componentes adicionais
O script também exige componentes Python e bash para executar e se conectar com segurança ao ponto de recuperação.
| Componente | Versão | Tipo do SO |
|---|---|---|
| bash | 4 e acima | Linux |
| Python | 2.6.6 e acima | Linux |
| .NET | 4.6.2 e posterior | Windows |
| TLS | 1.2 deve ser compatível | Linux/ Windows |
Além disso, certifique-se de que você tem o computador certo para executar o script ILR e se ele atende aos requisitos de acesso.
Etapa 4: requisitos de acesso para executar o script com sucesso
Se você executar o script em um computador com acesso restrito, certifique-se de que há acesso para:
- Marca de serviço
download.microsoft.comouAzureFrontDoor.FirstPartyno NSG na porta 443 (saída) - URLs do Serviço de Recuperação (GEO-NAME refere-se à região onde o cofre dos Serviços de Recuperação reside) na porta 3260 (saída)
https://pod01-rec2.GEO-NAME.backup.windowsazure.com(Para regiões públicas do Azure) ou a marca de serviçoAzureBackupno NSGhttps://pod01-rec2.GEO-NAME.backup.windowsazure.cn(Para o Microsoft Azure operado pela 21Vianet) ouAzureBackupmarca de serviço no NSGhttps://pod01-rec2.GEO-NAME.backup.windowsazure.us(Para o Governo dos EUA para Azure) ou a marca de serviçoAzureBackupno NSGhttps://pod01-rec2.GEO-NAME.backup.windowsazure.de(Para o Azure Alemanha) ou a marca de serviçoAzureBackupno NSG
- Resolução de DNS público na porta 53 (saída)
Observação
Os proxies podem não dar suporte ao protocolo iSCSI ou conceder acesso à porta 3260. Portanto, é altamente recomendável executar esse script nos computadores que têm acesso direto, conforme exigido acima, e não nos computadores que serão redirecionados para o proxy.
Observação
No caso, a VM com backup é o Windows. Portanto, o nome geográfico será mencionado na senha gerada.
Por exemplo, se a senha gerada for ContosoVM_wcus_GUID, o nome geográfico será wcus e a URL será: <https://pod01-rec2.wcus.backup.windowsazure.com>
Se a VM com backup for Linux, então o arquivo de script que você baixou na etapa 1 acima vai ter o nome geográfico no nome do arquivo. Use o nome geográfico para preencher a URL. O nome do script baixado começará: com:'VMname'_'geoname'_'GUID'.
Por exemplo, se o nome de arquivo do script for ontosoVM_wcus_12345678, o nome geográfico vai ser wcus e a URL vai ser: <https://pod01-rec2.wcus.backup.windowsazure.com>
Para o Linux, o script exige os componentes 'open-iscsi' e 'lshw' para se conectar ao ponto de recuperação. Se os componentes não existem no computador onde o script é executado, o script solicita a permissão para instalar os componentes. Conceda para instalar os componentes necessários.
É necessário ter acesso a download.microsoft.com para fazer download dos componentes usados para criar um canal seguro entre o computador em que o script é executado e os dados no ponto de recuperação.
Além disso, certifique-se de que você tem o computador certo para executar o script ILR e se ele atende aos requisitos de sistema operacional.
Etapa 5: executar o script e identificar os volumes
Observação
O script é gerado somente em inglês e não está localizado. Portanto, pode ser necessário que a localidade do sistema esteja em inglês para que o script seja executado corretamente
Para Windows
Depois de atender a todos os requisitos listados na Etapa 2, na Etapa 3 e na Etapa 4, copie o script do local baixado (geralmente é a pasta Downloads) e consulte a Etapa 1 para saber como gerar e fazer o download do script. Clique com o botão direito do mouse no arquivo executável e execute-o com credenciais de Administrador. Quando solicitado, digite a senha ou cole a senha a partir da memória e pressione Enter. Quando a senha válida é inserida, o script conecta-se ao ponto de recuperação.
Quando você executa o arquivo executável, o sistema operacional monta os novos volumes e atribui letras de unidade. Você pode usar o Windows Explorer ou o Explorador de arquivos para procurar essas unidades. As letras de unidade atribuídas aos volumes podem não ser as mesmas letras da máquina virtual original. No entanto, o nome do volume é preservado. Por exemplo, se o volume na máquina virtual original fosse “Disco de Dados (E:\)”, esse volume poderia ser anexado no computador local como “Disco de Dados (“Qualquer letra”:\). Busque em todos os volumes mencionados na saída do script até encontrar seus arquivos ou suas pastas.
Para VMs com backup com discos grandes (Windows)
Se o processo de recuperação de arquivo parar depois de executar o script de restauração de arquivo (por exemplo, se os discos nunca montarem, ou se estiverem montados mas os volumes não aparecerem), execute as seguintes etapas:
Verifique se o sistema operacional é WS 2012 ou superior.
Verifique se as chaves do Registro estão definidas conforme sugerido abaixo no servidor de restauração e reinicialize o servidor. O número ao lado do GUID pode variar de 0001 a 0005. No exemplo a seguir, é 0004. Navegue pelo caminho da chave do registro até a seção de parâmetros.
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\TimeOutValue – change this from 60 to 2400 secs.
- HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e97b-e325-11ce-bfc1-08002be10318}\0003\Parameters\SrbTimeoutDelta – change this from 15 to 2400 secs.
- HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e97b-e325-11ce-bfc1-08002be10318}\0003\Parameters\EnableNOPOut – change this from 0 to 1
- HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e97b-e325-11ce-bfc1-08002be10318}\0003\Parameters\MaxRequestHoldTime - change this from 60 to 2400 secs.
Para Linux
Depois de atender a todos os requisitos listados na Etapa 2, na Etapa 3 e na Etapa 4, gere um script Python para computadores Linux. Consulte a Etapa 1 para saber como gerar e fazer o download do script. Faça o download do script e o copie para o servidor Linux relevante/compatível. Talvez seja necessário modificar as permissões para executá-lo com chmod +x <python file name>. Em seguida, execute o arquivo Python com ./<python file name>.
No Linux, os volumes do ponto de recuperação são montados para a pasta onde o script é executado. Os discos anexados, volumes e os caminhos de montagem correspondente são mostrados adequadamente. Esses caminhos de montagem ficam visíveis aos usuários que têm acesso ao nível raiz. Percorra os volumes mencionados na saída do script.
Para VMs com backup e discos grandes (Linux)**
Se o processo de recuperação de arquivo parar depois de executar o script de restauração de arquivo (por exemplo, se os discos nunca montarem, ou se estiverem montados mas os volumes não aparecerem), execute as seguintes etapas:
- No arquivo /etc/iSCSI/iscsid.conf, altere a configuração de:
node.conn[0].timeo.noop_out_timeout = 5emnode.conn[0].timeo.noop_out_timeout = 120
- Depois de fazer as alterações acima, execute o script novamente. Se houver falhas transitórias, certifique-se de que há um intervalo de 20 a 30 minutos entre as execuções para evitar que a intermitência de solicitações afete a preparação de destino. Esse intervalo entre as execuções vai garantir que o destino esteja pronto para conexão do script.
- Após a recuperação dos arquivos, certifique-se de voltar ao portal e selecionar Desmontar discos para os pontos de recuperação nos quais você não conseguiu montar volumes. Essencialmente, essa etapa limpará todos os processos/sessões existentes e aumentará a chance de recuperação.
Matrizes LVM/RAID (para VMs Linux)
No Linux, o LVM (Gerenciador de Volumes Lógicos) e/ou as Matrizes RAID de software são usados para gerenciar volumes lógicos em vários discos. Se a VM do Linux protegida utilizar LVM e/ou Matrizes RAID, não será possível executar o script na mesma VM.
Em vez disso, execute o script em qualquer outra máquina com um SO compatível e que forneça suporte ao sistema de arquivos da VM protegida.
A saída de script seguinte exibe os discos de Matrizes RAID e/ou LVM e os volumes com o tipo de partição.
Para colocar essas partições online, execute os comandos nas seções a seguir.
Para partições LVM
Depois que o script é executado, as partições LVM são montadas nos volumes ou discos físicos especificados na saída do script. O processo é
- Obter a lista exclusiva de nomes de grupos de volume dos volumes ou discos físicos
- Listar os volumes lógicos nesses grupos de volume
- Montar os volumes lógicos no caminho desejado.
Listar nomes de grupos de volume de volumes físicos
Para listar os nomes de grupos de volume:
sudo pvs -o +vguuid
Esse comando vai listar todos os volumes físicos (incluindo os presentes antes de executar o script), seus nomes de grupos de volume correspondentes e os UUIDs (IDs de usuário exclusivos do grupo de volume). Uma saída de exemplo do comando é exibida abaixo.
PV VG Fmt Attr PSize PFree VG UUID
/dev/sda4 rootvg lvm2 a-- 138.71g 113.71g EtBn0y-RlXA-pK8g-de2S-mq9K-9syx-B29OL6
/dev/sdc APPvg_new lvm2 a-- <75.00g <7.50g njdUWm-6ytR-8oAm-8eN1-jiss-eQ3p-HRIhq5
/dev/sde APPvg_new lvm2 a-- <75.00g <7.50g njdUWm-6ytR-8oAm-8eN1-jiss-eQ3p-HRIhq5
/dev/sdf datavg_db lvm2 a-- <1.50t <396.50g dhWL1i-lcZS-KPLI-o7qP-AN2n-y2f8-A1fWqN
/dev/sdd datavg_db lvm2 a-- <1.50t <396.50g dhWL1i-lcZS-KPLI-o7qP-AN2n-y2f8-A1fWqN
A primeira coluna (VP) mostra o volume físico e as colunas subsequentes mostram o nome do grupo de volume relevante, o formato, os atributos, o tamanho, o espaço livre e a ID exclusiva do grupo de volume. A saída do comando exibe todos os volumes físicos. Consulte a saída do script e identifique os volumes relacionados ao backup. No exemplo acima, a saída do script teria mostrado/dev/sdf e /dev/sdd. Portanto, o grupo de volume datavg_db pertence ao script e o grupo de volume Appvg_new pertence ao computador. A ideia final é assegurar que um nome de grupo de volume exclusivo deve ter uma ID exclusiva.
Grupos de volume duplicados
Há cenários em que os nomes de grupos de volume podem ter dois UUIDs após a execução do script. Isso significa que os nomes do grupo de volume no computador em que o script é executado e na VM com backup são os mesmos. Nesses casos, é necessário renomear os grupos de volume das VMs com backup. Veja o exemplo abaixo.
PV VG Fmt Attr PSize PFree VG UUID
/dev/sda4 rootvg lvm2 a-- 138.71g 113.71g EtBn0y-RlXA-pK8g-de2S-mq9K-9syx-B29OL6
/dev/sdc APPvg_new lvm2 a-- <75.00g <7.50g njdUWm-6ytR-8oAm-8eN1-jiss-eQ3p-HRIhq5
/dev/sde APPvg_new lvm2 a-- <75.00g <7.50g njdUWm-6ytR-8oAm-8eN1-jiss-eQ3p-HRIhq5
/dev/sdg APPvg_new lvm2 a-- <75.00g 508.00m lCAisz-wTeJ-eqdj-S4HY-108f-b8Xh-607IuC
/dev/sdh APPvg_new lvm2 a-- <75.00g 508.00m lCAisz-wTeJ-eqdj-S4HY-108f-b8Xh-607IuC
/dev/sdm2 rootvg lvm2 a-- 194.57g 127.57g efohjX-KUGB-ETaH-4JKB-MieG-EGOc-XcfLCt
A saída do script teria mostrado /dev/sdg, /dev/sdh e /dev/sdm2 como anexados. Assim, os nomes de VG correspondentes são Appvg_new e rootvg. Mas os mesmos nomes estão presentes na lista VG do computador. É possível ver que um nome de VG tem dois UUIDs.
Agora é necessário renomear os nomes de VG para volumes baseados em script, por exemplo: /dev/SDG, /dev/SDH e /dev/sdm2. Para renomear o grupo de volume, use o seguinte comando
sudo vgimportclone -n rootvg_new /dev/sdm2
sudo vgimportclone -n APPVg_2 /dev/sdg /dev/sdh
Agora todos os nomes de VG tem IDs exclusivos.
Ativar grupos de volumes
Certifique-se de que os grupos de volumes correspondentes aos volumes do script estão ativos. O comando a seguir é usado para exibir os grupos de volume ativos. Verifique se os grupos de volume relacionados do script estão presentes nessa lista.
sudo vgdisplay -a
Caso contrário, ative o grupo de volume usando o comando a seguir.
sudo vgchange –a y <volume-group-name>
Listar volumes lógicos em grupos de volumes
Depois de obter a lista de VGs exclusivos e ativos relacionados ao script, os volumes lógicos presentes nesses grupos de volume podem ser listados usando o comando a seguir.
sudo lvdisplay <volume-group-name>
Este comando exibe o caminho de cada volume lógico como 'LV path'.
Montar volumes lógicos
Para montar os volumes lógicos no caminho de sua escolha:
sudo mount <LV path from the lvdisplay cmd results> </mountpath>
Aviso
Não use o comando 'mount -a'. Esse comando monta todos os dispositivos descritos em '/etc/fstab '. Isso significa que dispositivos duplicados podem ser montados. Os dados podem ser redirecionados para dispositivos criados por um script, o que não os mantém e pode resultar em perda de dados.
Para matrizes RAID
O comando a seguir exibe detalhes sobre todos os discos raid:
sudo mdadm –detail –scan
O disco RAID relevante é exibido como /dev/mdm/<RAID array name in the protected VM>
Use o comando de montagem se o disco RAID tiver volumes físicos:
sudo mount [RAID Disk Path] [/mountpath]
Se o disco RAID tiver outra LVM configurada, utilize o procedimento anterior para partições de LVM, mas utilize o nome de volume no lugar do nome do RAID Disk.
Etapa6: fechar a conexão
Depois de identificar os arquivos e copiá-los para um local de armazenamento local, remova ou desmonte as unidades adicionais. Para desmontar as unidades, no menu Recuperação de Arquivos no portal do Azure, clique em Desmontar Discos.
Você receberá uma mensagem quando os discos estiverem desmontados. Pode levar alguns minutos até que a conexão seja atualizada para que você possa remover os discos.
No Linux, após a conexão com o ponto de recuperação ser interrompida, o sistema operacional não removerá automaticamente os caminhos de montagem correspondentes. Os caminhos de montagem existem como volumes "órfãos" e são visíveis, mas geram um erro ao acessar/gravar os arquivos. Eles podem ser removidos manualmente executando o script com o parâmetro "clean" (python scriptName.py clean). O script, quando executado, identifica esses volumes existentes em qualquer ponto de recuperação anterior e limpa mediante consentimento.
Observação
Certifique-se de que a conexão seja fechada depois que os arquivos necessários forem restaurados. Isso é importante, especialmente no cenário em que o computador no qual o script é executado também é configurado para backup. Se a conexão ainda estiver aberta, o backup subsequente pode falhar com o erro "UserErrorUnableToOpenMount". Isso acontece porque os volumes/unidades montados devem estar disponíveis e podem falhar quando forem acessados se o armazenamento subjacente, ou seja, o servidor de destino iSCSI não estiver disponível. A limpeza da conexão vai remover essas unidades/volumes e elas não estarão disponíveis durante o backup.
Segurança
Esta seção aborda várias medidas de segurança tomadas para a implementação da recuperação de arquivos de backups de VM do Azure.
Fluxo de recursos
Esse recurso foi criado para acessar os dados da VM sem a necessidade de restaurar toda a VM ou os discos de VM e com o número mínimo de etapas. O acesso aos dados da VM é fornecido por um script (que monta o volume de recuperação quando executado conforme mostrado abaixo) que forma a base de todas as implementações de segurança:
Implementações de segurança
Selecionar o ponto de recuperação (quem pode gerar script)
O script fornece acesso aos dados da VM, portanto, é importante regular quem pode gerá-lo. Você precisa entrar no portal do Azure e ser autorizado pelo RBAC do Azure para gerar o script.
A recuperação de arquivo precisa do mesmo nível de autorização necessário para restauração de VM e restauração de discos. Em outras palavras, somente usuários autorizados podem exibir os dados da VM e podem gerar o script.
O script gerado é assinado com o certificado oficial da Microsoft para o serviço de Backup do Azure. Qualquer violação no script significa que a assinatura foi violada e qualquer tentativa de executar o script é sinalizada como um risco potencial pelo sistema operacional.
Montar o volume de recuperação (quem pode executar o script)
Somente um administrador pode executar o script que deve ser executado no modo elevado. O script executa apenas um conjunto de etapas gerado previamente e não aceita a entrada de qualquer fonte externa.
Para executar o script, é necessária uma senha que é exibida apenas para o usuário autorizado no momento da geração do script no portal do Azure ou no PowerShell/CLI. Isso é para garantir que o usuário autorizado que faz o download do script também seja responsável pela execução.
Procurar arquivos e pastas
Para procurar arquivos e pastas, o script usa o iniciador iSCSI no computador e se conecta ao ponto de recuperação configurado como um destino iSCSI. Aqui você pode imaginar cenários em que alguém está tentando imitar/falsificar um ou todos os componentes.
Usamos um mecanismo de autenticação CHAP mútuo para que cada componente autentique o outro. Isso significa que é extremamente difícil para um iniciador falso se conectar ao destino iSCSI e para que um destino falso seja conectado ao computador na qual o script é executado.
O fluxo de dados entre o serviço de recuperação e o computador é protegido por meio da criação de um túnel TLS seguro sobre TCP (TLS 1.2 deve ter suporte no computador no qual o script é executado).
Qualquer lista de controle de acesso (ACL) de arquivo presente na VM pai/com backup também é preservada no sistema de arquivos montado.
O script fornece acesso somente leitura a um ponto de recuperação e é válido por apenas 12 horas. Se você quer remover o acesso antes disso, entre no portal do Azure/PowerShell/CLI e execute desmontar discos para esse ponto de recuperação específico. O script será invalidado imediatamente.
Próximas etapas
- Saiba como restaurar arquivos por meio do PowerShell
- Saiba como restaurar arquivos por meio da CLI do Azure
- Depois que a VM for restaurada, saiba como gerenciar backups