Recuperación de un volumen de inicio dañado para instancias basadas en Linux

Si su instancia no se inicia correctamente o se inicia con el volumen de inicio configurado para acceso de solo lectura, el volumen de inicio de la instancia puede estar dañado. Si bien es raro, se pueden producir daños en el volumen de inicio en los siguientes escenarios:

  • Cuando una instancia experimenta un apagado forzado utilizando la API.

  • Cuando una instancia experimenta un bloqueo del sistema debido a un error del sistema operativo o del software y un reinicio o apagado de la instancia se agota, y luego se produce un apagado forzado.

  • Cuando se produce un error o una interrupción en la infraestructura subyacente y había escrituras críticas en el disco pendientes en el sistema.

Importante

En la mayoría de los casos, un reinicio simple resolverá los problemas de daños del volumen de inicio, por lo que esta es la primera acción que debe tomar al solucionar este problema.

En este tema se describe cómo determinar si el volumen de inicio de su instancia basada en Linux está dañado y qué pasos tomar para solucionar y recuperar el volumen de inicio dañado. Para las instancias de Windows, consulte Recuperación de un volumen de inicio dañado para instancias basadas de Windows.

Detección de daños de volumen de inicio

La corrupción del volumen de inicio puede evitar que una instancia se inicie correctamente, por lo que es posible que no pueda conectarse a la instancia mediante SSH. En su lugar, puede usar la función de conexión de consola de instancia para conectarse a la instancia que no funciona correctamente. Para obtener más información sobre el uso de esta función, consulte Solución de problemas de instancias con conexiones de la consola de instancias.

En esta sección se describe cómo usar una conexión de consola serie para detectar si se ha producido un daño en el volumen de inicio.

Consejo

Si ya ha confirmado que el volumen de inicio de su instancia está dañado o si está utilizando una imagen personalizada importada, vaya a la sección Recuperación del volumen de inicio, que describe cómo usar una segunda instancia junto con las herramientas estándar del sistema de archivos para detectar y reparar la corrupción del volumen de inicio.
  1. Crear una conexión de consola serie para la instancia.
  2. Conéctese a la instancia a través de la consola serie.

    En este punto, es normal que la consola serie parezca bloquearse, ya que el sistema puede haber fallado.

  3. Reinicie la instancia desde la consola.
  4. Una vez que comience el proceso de reinicio, vuelva a la ventana de terminal y debería ver que los mensajes del sistema desde la instancia comienzan a aparecer en la ventana.

  5. Supervise los mensajes que aparecen cuando se inicia el sistema. La mayoría de los sistemas operativos configurarán el volumen de inicio en solo lectura tan pronto como se detecte la corrupción del disco para evitar que las escrituras corrompan aún más el volumen, así que busque mensajes que indiquen que el volumen de inicio está en modo de solo lectura. A continuación se muestran algunos ejemplos:

    • En una instancia con volúmenes de inicio asociados a iSCSI, el servicio iscsiadm no podrá asociar un volumen porque el volumen está en modo de solo lectura. Esto normalmente evitará que las instancias continúen arrancando. La consola serie puede mostrar un mensaje similar al siguiente:

      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
    • En una instancia con volúmenes de inicio asociados paravirtualizados, el sistema puede continuar el proceso de inicio, pero estará en un estado degradado porque no se puede escribir nada en la unidad de inicio. La consola serie puede mostrar mensajes de error similares a los siguientes:

      [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'

    Los mensajes de error y el comportamiento del sistema descritos aquí son los más comúnmente vistos para la corrupción del volumen de inicio; sin embargo, dependiendo del sistema operativo, puede ver diferentes mensajes de error y comportamiento del sistema. Si no ve los que se describen aquí, consulte la documentación de su sistema operativo para obtener información adicional sobre la solución de problemas.

Recuperación del volumen de inicio

Para solucionar problemas y recuperar el volumen de inicio dañado, debe separar el volumen de inicio de la instancia y luego asociar el volumen de inicio a una segunda instancia como un volumen de datos.

Desasociación del volumen de inicio

Si ha detectado que el volumen de inicio de su instancia está dañado, debe desconectar el volumen de inicio de la instancia antes de comenzar los pasos de solución de problemas y recuperación.

  1. Parada de la instancia.
  2. Desasocie el volumen de inicio de la instancia.

Asociación del volumen de inicio como un volumen de datos a una segunda instancia

Para la segunda instancia, recomendamos que utilice una instancia que ejecute un sistema operativo que coincida más estrechamente con el sistema operativo para la instancia del volumen de inicio. Solo debe adjuntar volúmenes de inicio para instancias basadas en Linux a otras instancias basadas en Linux. La segunda instancia debe estar en el mismo dominio de disponibilidad y región la instancia del volumen de inicio. Si no hay ninguna instancia existente disponible, cree una nueva instancia de Linux mediante los pasos descritos en Creación de una instancia. Una vez que tenga la segunda instancia, asegúrese de poder iniciar sesión en la instancia y de que sea funcional antes de continuar con los pasos de recuperación. Para obtener más información sobre los pasos para acceder a la instancia, consulte Conexión a una instancia de Linux. Después de haber confirmado que la instancia es funcional, realice los siguientes pasos.

  1. Ejecute el comando lsblk y tome nota de las unidades que se encuentran actualmente en la instancia, por ejemplo:

    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. Asocie el volumen de inicio a la segunda instancia como un volumen de datos. Para obtener más información, consulte Asociación de un volumen en bloque a una instancia.
    Asociar el volumen de inicio como volumen de datos
    1. Abra el menú de navegación y seleccione Recursos informáticos. En Recursos informáticos, seleccione Instancias.
    2. Haga clic en la instancia a la que desea asociar un volumen.
    3. En Recursos, haga clic en Volúmenes en bloque asociados.
    4. Haga clic en Asociar volumen en bloque.
    5. Seleccione el tipo de anexo del volumen. Si hay anexos paravirtualizados disponibles para esta instancia, recomendamos que seleccione este tipo de anexo para este procedimiento.

      Si selecciona iSCSI como tipo de asociación de volumen, consulte Conexión a un volumen en bloque para obtener más información.

    6. En la lista desplegable Compartimento de volumen en bloque, seleccione el compartimento.
    7. Seleccione la opción Seleccionar volumen y, a continuación, seleccione el volumen en la sección Volumen de inicio de la lista desplegable Volumen en bloque.
    8. Seleccione Lectura/Escritura como tipo de acceso.
    9. Haga clic en Asociar.

      Cuando el icono del volumen ya no lo enumere como Asociando, continúe con los siguientes pasos.

  3. Vuelva a ejecutar el comando lsblk para confirmar que el volumen de inicio ahora se muestra como un volumen asociado a la instancia. En este resultado de ejemplo para lsblk, el volumen de inicio asociado como volumen de datos muestra hasta 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. Ejecute el comando fsck en la partición raíz del volumen. La partición raíz suele ser la partición más grande del volumen.

    El siguiente ejemplo del comando fsck muestra la salida cuando no hay errores o corrupción en las particiones de una instancia de 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).

    Si hay errores en una partición, normalmente se le pedirá que repare los errores. A continuación, se muestra un ejemplo de una sesión de reparación interactiva de un volumen de inicio ext4 dañado para una instancia de 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
    Nota

    Los sistemas de archivos XFS generalmente repararán automáticamente su contenido cuando el sistema se inicie, reparando cualquier daño durante el proceso de inicio. Puede utilizar el comando xfs_repair para forzar una reparación para casos en los que la corrupción del volumen de inicio impide que funcione la funcionalidad del par automático, como se muestra en el siguiente ejemplo:

    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