Recuperando um Volume de Inicialização Danificado para Instâncias Baseadas no Linux

Se não for possível reiniciar sua instância ou se ela reinicializar com o volume de inicialização definido para o acesso somente para leitura, o volume de inicialização da instância talvez esteja danificado. Embora isso seja raro, o corrompimento do volume de inicialização pode ocorrer nos seguintes cenários:

  • Quando uma instância experimenta um shutdown forçado usando a API.

  • Quando uma instância experimenta uma interrupção do sistema em decorrência de um erro do sistema operacional ou software e acontece o timeout de uma reinicialização ou shut-down normal da instância e, em seguida, um shut-down forçado ocorre.

  • Quando ocorre um erro ou uma paralisação na infraestrutura subjacente e havia gravações críticas no disco pendentes no sistema.

Importante

Na maioria dos casos, uma reinicialização simples resolverá problemas de corrompimento do volume de inicialização. Portanto, essa é a primeira medida que você deve tomar ao diagnosticar esse problema.

Este tópico descreve como determinar se o volume de inicialização da instância baseada no Linux está corrompido e quais etapas devem ser usadas para diagnosticar e solucionar problemas e recuperar o volume de inicialização danificado. Para instâncias do Windows, consulte Recuperando um Volume de Inicialização Danificado para Instâncias do Windows.

Detectando Danos no Volume de Inicialização

Danos no volume de inicialização podem impedir a inicialização de uma instância com sucesso; portanto, talvez você não consiga se conectar à instância usando SSH. Em vez disso, você pode usar o recurso de conexão da console da instância para estabelecer conexão com a instância que está funcionando incorretamente. Para obter mais informações sobre o uso desse recurso, consulte Diagnosticando e Solucionando Problemas de Instância com o Uso de Conexões da Console da Instância.

Esta seção descreve como usar uma conexão de console serial para detectar se ocorreram danos no volume de inicialização.

Dica

Se você já tiver confirmado que o volume de inicialização da sua instância está corrompido ou se estiver usando uma imagem personalizada importada, vá para a seção Recuperando o Volume de Inicialização, que descreve como usar uma segunda instância juntamente com as ferramentas padrão do sistema de arquivos para detectar e reparar danos no volume de inicialização.
  1. Crie uma conexão da console para a instância.
  2. Estabeleça conexão com a instância por meio da console serial.

    Nesse ponto, é normal que a console serial pareça estar travada, pois o sistema pode já ter falhado.

  3. Reinicialize a instância pela Console.
  4. Depois que o processo de reinicialização for iniciado, volte para a janela do terminal e você deverá ver aparecendo na janela as mensagens do sistema desde a inicialização da instância.

  5. Monitore as mensagens que aparecerem à medida que o sistema for inicializado. A maioria dos sistemas operacionais definirá o volume de inicialização como somente para leitura assim que os danos no disco forem detectados, para evitar que gravações corrompam ainda mais o volume; portanto, procure mensagens que indique que o volume de inicialização está no modo somente para leitura. Estes são alguns exemplos:

    • Em uma instância com volumes de inicialização anexados pelo iSCSI, o serviço iscsiadm falhará ao anexar um volume, pois o volume está no modo somente para leitura. Isso normalmente impedirá que as instâncias continuem a ser inicializadas. A console serial pode exibir uma mensagem semelhante à seguinte:

      iscsiadm: Maybe you are not root?
      iscsiadm: Could not lock discovery DB: /var/lock/iscsi/lock.write: Read-only file system
      touch: cannot touch `/var/lock/subsys/iscsid': Read-only file system
      touch: cannot touch `/var/lock/subsys/iscsi': Read-only file system
    • Em uma instância com volumes de inicialização anexados paravirtualizados, o sistema pode continuar o processo de inicialização, mas ficará em um estado degradado porque nada pode ser gravado na unidade de inicialização. A console serial pode exibir mensagens de erro semelhantes às seguintes:

      [FAILED] Failed to start Create Volatile Files and Directories.
      See 'systemctl status systemd-tmpfiles-setup.service' for details.
      ...
      [   27.160070] cloud-init[819]:     os.chmod(path, real_mode)
      [   27.166027] cloud-init[819]: OSError: [Errno 30] Read-only file system: '/var/lib/cloud/data'

    As mensagens de erro e o comportamento do sistema descritos aqui são os mais comumente vistos quanto ao corrompimento do volume de inicialização. Porém, dependendo do sistema operacional, você poderá ver diferentes mensagens de erro e comportamentos do sistema. Se você não vir aquelas descritas aqui, consulte a documentação do seu sistema operacional para obter informações adicionais sobre solução de problemas.

Recuperando o Volume de Inicialização

Para solucionar problemas e recuperar o volume de inicialização corrompido, é necessário desanexar o volume de inicialização da instância e, em seguida, anexar o volume de inicialização a uma segunda instância como um volume de dados.

Desanexando o Volume de Inicialização

Se você tiver detectado que o volume de inicialização da sua instância está corrompido, será necessário desanexar o volume de inicialização da instância para que você possa iniciar o diagnóstico de problemas e as etapas de recuperação.

  1. Interrompa a instância.
  2. Desanexe o volume de inicialização da instância.

Anexando o Volume de Inicialização como um Volume de Dados a uma Segunda Instância

Para a segunda instância, recomendamos que você use uma instância que execute um sistema operacional que melhor corresponda ao sistema operacional da instância do volume de inicialização. Você só deverá anexar volumes de inicialização para instâncias baseadas no Linux a outras instâncias baseadas no Linux. A segunda instância deve estar no mesmo domínio de disponibilidade e região da instância do volume de inicialização. Se nenhuma instância existente estiver disponível, crie uma nova instância do Linux usando as etapas descritas em Criando uma Instância. Depois de ter a segunda instância, verifique se você pode fazer log-in na instância e se ela está funcional antes de prosseguir com as etapas de recuperação. Para saber as etapas para acessar a instância, consulte Estabelecendo Conexão com uma Instância do Linux. Depois de confirmar que a instância está funcionando, execute as etapas a seguir.

  1. Execute o comando lsblk e anote as unidades que estão atualmente na instância, por exemplo:

    lsblk
    NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sda      8:0    0 46.6G  0 disk
    ├─sda2   8:2    0    8G  0 part [SWAP]
    ├─sda3   8:3    0 38.4G  0 part /
    └─sda1   8:1    0  200M  0 part /boot/efi
  2. Anexe o volume de inicialização à segunda instância como um volume de dados. Para obter mais informações, consulte Anexando um Volume em Blocos a uma Instância.
    Para anexar o volume de inicialização como um volume de dados
    1. Abra o menu de navegação e clique em Compute. No serviço Compute, clique em Instâncias.
    2. Clique na instância à qual você deseja anexar um volume.
    3. Em Recursos, clique em Volumes em Blocos Anexados.
    4. Clique em Anexar Volume em Blocos.
    5. Selecione o tipo de anexo do volume. Se anexos paravirtualizados estiverem disponíveis para esta instância, recomendamos que você selecione este tipo de anexo para este procedimento.

      Se você selecionar iSCSI como o tipo de anexo do volume, será necessário estabelecer conexão com o volume. Consulte Conectando-se a um Volume em Blocos para obter mais informações.

    6. Na lista drop-down Compartimento do Volume em Blocos, selecione o compartimento.
    7. Escolha a opção Selecionar Volume e, em seguida, selecione o volume na seção Volume de Inicialização na lista drop-down Volume em Blocos.
    8. Selecione Leitura/Gravação como o tipo de acesso.
    9. Clique em Anexar.

      Quando o ícone do volume não aparecer mais listado como Anexando, prossiga com as próximas etapas.

  3. Execute o comando lsblk novamente para confirmar se o volume de inicialização agora aparece como um volume anexado à instância. Neste exemplo de saída para lsblk, o volume de inicialização anexado como um volume de dados é mostrado como sdb:
    lsblk
    NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sdb      8:16   0 46.6G  0 disk
    ├─sdb2   8:18   0    8G  0 part
    ├─sdb3   8:19   0 38.4G  0 part
    └─sdb1   8:17   0  200M  0 part
    sda      8:0    0 46.6G  0 disk
    ├─sda2   8:2    0    8G  0 part [SWAP]
    ├─sda3   8:3    0 38.4G  0 part /
    └─sda1   8:1    0  200M  0 part /boot/efi
  4. Execute o comando fsck na partição raiz do volume. A partição raiz geralmente é a maior partição do volume.

    A amostra a seguir para o comando fsck mostra a saída quando não há erros ou danos presentes nas partições de uma instância do Oracle 7.6:

    sudo fsck -V /dev/sdb1
    fsck from util-linux 2.23.2
    [/sbin/fsck.vfat (1) -- /boot/efi] fsck.vfat /dev/sdb1
    fsck.fat 3.0.20 (12 Jun 2013)
    /dev/sdb1: 17 files, 2466/51145 clusters
    
    sudo fsck -V /dev/sdb2
    fsck from util-linux 2.23.2
    
    sudo fsck -V /dev/sdb3
    fsck from util-linux 2.23.2
    [/sbin/fsck.xfs (1) -- /] fsck.xfs /dev/sdb3
    If you wish to check the consistency of an XFS filesystem or
    repair a damaged filesystem, see xfs_repair(8).

    Se houver erros em uma partição, geralmente você será solicitado a reparar os erros. A seguir está um exemplo de uma sessão interativa de reparo de um volume de inicialização ext4 corrompido para uma instância do Ubuntu:

    sudo fsck -V /dev/sdb1
    fsck from util-linux 2.31.1
    [/sbin/fsck.ext4 (1) -- /] fsck.ext4 /dev/sdb1
    e2fsck 1.44.1 (24-Mar-2018)
    One or more block group descriptor checksums are invalid.  Fix<y> yes
    Group descriptor 92 checksum is 0xe9a1, should be 0x1f53.  FIXED.
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    Block bitmap differences: Group 92 block bitmap does not match checksum.
    FIXED.
    
    cloudimg-rootfs: ***** FILE SYSTEM WAS MODIFIED *****
    cloudimg-rootfs: 75336/5999616 files (0.1% non-contiguous), 798678/12181243 blocks
    Observação

    Os sistemas de arquivos XFS geralmente reparam automaticamente seu conteúdo quando o sistema é inicializado, corrigindo qualquer dano durante o processo de inicialização. Você pode usar o comando xfs_repair para forçar um reparo em cenários nos quais o corrompimento do volume de inicialização está impedindo o funcionamento do reparo automático, conforme mostrado no exemplo a seguir:

    sudo xfs_repair /dev/sdb3
    Phase 1 - find and verify superblock...
    Phase 2 - using internal log
    - zero log...
    - scan filesystem freespace and inode maps...
    ...
    Phase 7 - verify and correct link counts...
    done