¿Cuáles son los pasos de mejores prácticas para verificar o recuperarse de una posible corrupción del sistema operativo Linux, en caso de un corte de energía inesperado (o una falla del host de la VM)?
Por supuesto, "depende" de la instalación y configuración, pero estoy buscando acciones/verificaciones comunes para realizar en la mayoría de los sistemas operativos Linux (Debian, Ubuntu, Mint, otros) y sistemas de archivos (XFS, ZFS, EXT4, vfat). .
No se trata de prevenir cierres indeseados, sino de abordar cuándo ocurren y tratar de garantizar la recuperación en el mejor de los casos.
Soy consciente de que los sistemas operativos tienden a detectar cuando un sistema de archivos no se desmontó (como lo haría durante un apagado ordenado) y, por lo tanto, realizan comprobaciones automáticamente al iniciar, pero ¿cuáles son esas comprobaciones y cómo realizarlas manualmente?
Por ejemplo, e2fsck -fes una de esas herramientas, pero para los no iniciados, ¿cuándo se puede/debería utilizar y cuándo no (o no funcionará)?
Como ejemplo, en Windows podrías hacer:
- Compruebe si hay daños en el sistema de archivos NTFS utilizando el
chkdskequivalente antiguo o moderno derepair-volume(en PowerShell) - Verifique la integridad de los archivos del sistema central del sistema operativo usando
sfc.exe /scannow
Los pasos de verificación/recuperación específicos de la aplicación, como MySQL databaseo LDAP directoriesetc., quedan fuera del alcance de esta pregunta, a menos que sea algo muy común, como alguna base de datos del sistema operativo, por ejemplo, apto snapbases de datos.
¿A qué te dedicas?
Respuesta1
Los sistemas de archivos modernos realizan un diario de metadatos, lo que significa que un simple corte de energía no debería representar ningún problema para la integridad del sistema de archivos en sí: las transacciones completadas pero no confirmadas se reproducen, mientras que las transacciones parciales se revierten.
Sin embargo, los datos en tránsito o en caché,poderperderse o escribirse parcialmente; después de todo, si una aplicación maneja algunos datos en el sistema operativo para escritura asíncrona (es decir, escrituras normales) pero la máquina pierde energía antes de que el sistema operativo pueda reescribirlos en el almacenamiento permanente, los datosvoluntadestar perdido.
Por esta misma razón, las aplicaciones críticas como las bases de datos (excepto MyISAM) implementan su propio registro en diario y escriben datos con semántica de sincronización: uso fsync()y similares.
En resumen: un apagado no planificado generalmente no necesita ninguna reparación del sistema de archivos (más allá de la reproducción automática del diario). La verificación de aplicaciones depende de la aplicación en sí, y la mayoría de las bases de datos no se ven afectadas por un corte de energía repentino, a menos que se use MyISAM, querequierecorrermysqlcheck