예상치 못한 정전(또는 VM 호스트 장애)이 발생할 경우 잠재적인 Linux OS 손상을 확인/복구하는 모범 사례 단계는 무엇입니까?
물론 설치 및 설정에 따라 "의존"하지만 대부분의 Linux OS(Debian, Ubuntu, Mint 등) 및 파일 시스템(XFS, ZFS, EXT4, vfat)에 대해 수행할 일반적인 작업/검사를 찾고 있습니다. .
이는 부당한 종료를 방지하는 것이 아니라, 종료가 발생할 때 이를 처리하고 최상의 복구를 보장하기 위한 것입니다.
나는 OS가 파일 시스템이 마운트 해제되지 않은 경우(예: 정상 종료 중)를 감지하여 부팅 시 자동으로 검사를 수행하는 경향이 있다는 것을 알고 있습니다. 그러나 이러한 검사는 무엇이며 수동으로 수행하는 방법은 무엇입니까?
예를 들어 e2fsck -f그러한 도구 중 하나이지만, 초보자의 경우 언제 사용할 수 있거나 사용해야 하며 언제 사용할 수 없습니까(또는 작동하지 않습니까)?
예를 들어, Windows에서는 다음을 수행할 수 있습니다.
- 이전
chkdsk또는 최신 버전repair-volume(PowerShell에서) 을 사용하여 NTFS 파일 시스템 손상을 확인하세요. - 다음을 사용하여 OS 핵심 시스템 파일의 무결성을 확인합니다.
sfc.exe /scannow
MySQL database등과 같은 애플리케이션별 확인/복구 단계는 LDAP directories이 질문의 범위를 벗어납니다. 데이터베이스 apt와 같은 일부 OS 데이터베이스와 같이 매우 일반적인 것이 아닌 한 snap.
너 뭐하니?
답변1
최신 파일 시스템은 메타데이터 저널을 수행합니다. 즉, 일반 정전이 파일 시스템 무결성 자체에 문제를 일으키면 안 됩니다. 완료되었지만 커밋되지 않은 트랜잭션은 재생되고 부분 트랜잭션은 롤백됩니다.
그러나 이동 중인 데이터 또는 캐시된 데이터는~할 수 있다손실되거나 부분적으로 기록됨 - 결국 애플리케이션이 비동기 쓰기(예: 일반 쓰기)를 위해 OS에 대한 일부 데이터를 처리하지만 OS가 해당 데이터를 영구 저장소에 다시 쓰기 전에 시스템의 전원이 꺼지면 데이터~ 할 것이다길을 잃다.
바로 이러한 이유로 데이터베이스(제외 MyISAM)로서 중요한 애플리케이션은 자체 저널링을 구현하고 동기화 의미론을 사용하여 데이터를 작성합니다 fsync().
즉, 계획되지 않은 종료에는 일반적으로 파일 시스템 복구가 필요하지 않습니다(자동 저널 재생 이상). 애플리케이션 검사는 애플리케이션 자체에 따라 달라지며 대부분의 데이터베이스는 갑작스러운 정전에 영향을 받지 않습니다 MyISAM.필요하다달리기mysqlcheck