정전으로 인한 손상에 Linux가 취약합니까?

우리 회사의 sysadmins는 Linux가 정전으로 인해 위험에 빠지기 쉽다고 말합니다. 그들은 Windows 시스템은 항상 정전에도 불구하고 Linux 상자는 종종 복구 할 수 없게된다고 말합니다 (즉, 더 이상 시스템을 부팅 할 수 없음). 그들은 전력 회사가 오랫동안 사무실의 전원을 차단한다고 말했기 때문에 관리자는 내가 정전 전에 내가 액세스 할 수있는 모든 Linux 상자를 종료하고 싶었습니다.

리눅스가 강력해야한다고 생각 했나요?
내 질문,-Linux 상자가 정전으로 인해 막히지 않도록 실행 해야하는 프로세스가 있습니까?

리눅스가 윈도우보다 부서지기 쉬운가요?
대답은 : 그것은 종속 주체 .

이 상황에서 누군가가 "부팅 할 수 없음"이라고 말하면 "파일 시스템 손상"으로 변환하고 원래 질문에 대한 예 또는 아니오로 답하면 사용중인 파일 시스템에 따라 다릅니다.

Windows는 Linux 박스가 허용하는 파일 시스템에 대한 모든 선택을 허용하지 않습니다. NTFS가 아닌 Windows 시스템은 거의 볼 수 없습니다. NTFS에는 장애 발생시 롤백 할 수있는 저널링 및 파일 트랜잭션 과 같은 전원 손실이있는 경우 도움이되는 기능이 내장되어 있습니다.

리눅스 박스는 이것을 가질 수 있지만 가질 수 없었습니다. 서버 설정 방법에 따라 다릅니다. 서버가 ext2 ¹ 을 사용 하면 정전시 파일이 손상 될 수 있습니다. NTFS보다 더 많은 데이터 무결성 기능을 가진 Btrfs 와 같은 것을 사용하는 시스템과 비교하십시오 .

따라서 시스템 관리자가 ext2 시스템에서만 작동 한 경우에는 옳을 수 있지만 다른 파일 시스템을 사용하면 잘못되었을 수 있습니다.

^{1 : Ext2는 데비안과 Red Hat Linux 모두에서 오랫동안 기본으로 사용되었습니다. 이제는 데이터 무결성 기능을 위해 NTFS와 비슷한 Ext3으로 대체되었습니다.}

아니요, Linux는 갑작스러운 정전으로 인해 Windows보다 본질적으로 덜 강력하지는 않습니다. OS 중 하나의 경우 발생할 수있는 일은 정확히 전원이 끊긴 순간 하드 드라이브의 파일 시스템에 파일이 기록되고 있으며 (이력 적으로) 파일 시스템을 손상시킬 수 있습니다.

이 문제에 대한 해결책은 정보를 작성하는 방식에 따라이 문제에 영향을받지 않는 저널링 파일 시스템을 사용하는 것입니다. NTFS도 마찬가지로 Ext3 및 ExT4 (Linux의 가장 일반적인 파일 시스템)를 포함한 대부분의 새로운 파일 시스템. 저널링 파일 시스템을 사용하는 한이 문제는 발생하지 않습니다.

나중에 부팅 프로세스가 종료되면 데이터베이스가있는 경우 (MySQL을보고 있는데 Postgres는이 문제를 겪지 않습니다) MYSQL 데이터베이스와 비슷한 문제가있을 수 있습니다-MYSQL은 종종 강력하지 않습니다 (Google ACID 준수 MYSQL for 이 주제). MySQL 설정이 ACID와 호환되지 않는 경우 재부팅시 인덱스를 강제 검사하여이 문제를 해결할 수 있습니다.

또 다른 (어떤 Jaded 및 불공평 한 Windows)보기는 이것입니다-Linux 상자는 Windows 상자보다 안정적입니다 (업타임 및 재부팅해야 함)-Linux 상자가 재부팅 할 때 실패 할 수 있습니다. 소프트웨어 문제가 아닌 오래된 문제로 인한 하드웨어 문제-재부팅 빈도가 높아져서 실패한 Windows 상자가 더 빨리 감지 될 수 있음)

배포판과 사용중인 파일 시스템에 따라 다소 취약 할 수 있습니다. 예정된 정전에 대해 알고 있다면 수동으로 종료해야합니다 (시스템 청소 또는 배선과 같은 유지 보수 시간을 사용해야합니다. 예기치 않은 정전이 발생하면 UPS 시스템에 Linux 종료 소프트웨어를 설치하십시오. 대부분의 Linux 배포판에 사용할 수있는 APCUPSD 파일이있는 경우 배포판을 확인하여 이미 포함되어 있거나 사용 가능한 파일이 있는지 확인하십시오. 의지하기 전에 시스템을 깨끗하게하십시오.

이 질문에 대한 조사를 한 결과 IT 부서의 말이 본질적으로 정확하고 Linux는 Windows보다 정전에 훨씬 취약하다는 것을 알았습니다. Linux / unix에서 inode 테이블이 작동하는 방식이 그 이유입니다. 정렬되지 않은 목록이고 지속적으로 수정되고 있기 때문에 커널 바이너리와 같은 중요한 정적 파일과 임시 파일과 같은 쓸모없는 파일은 구분되지 않습니다. 이것이 의미하는 바는 중요한 시스템 파일에 대한 inode 항목이 지속적으로 다시 작성되고 있다는 것입니다. 실제로, 중요한 시스템 파일은 실제로 비 필수 파일보다 주어진 시간에 inode 항목이 작성 될 가능성이 높습니다. 전원이 꺼지면 시스템 파일에 대한 포인터가 포함되어 있지 않을 가능성이있는 inode 테이블의 일부가 불려가는 경향이 있습니다. 시스템 파일 자체는 양호하지만 손상되지 않았지만 찾을 디렉토리가 손상되었습니다. 디스크 캐싱에 의해 상황이 악화되어 inode 테이블의 손상된 영역의 크기를 증가시키는 효과가 있습니다.

Windows에서는 이전 FAT 파일 시스템조차 이보다 훨씬 강력합니다. FAT에는 테이블도 있지만 정렬 된 테이블이므로 시스템 파일이 임시 파일과 혼합되어 있지 않습니다. 일반적으로 시스템 파일은 모두 디렉토리의 한 영역에 있으며이 영역은 자주 작성되지 않을 것입니다. 또한 FAT에는 백업 디렉토리가 있으므로 디렉토리가 손상된 경우에도 백업으로 되돌아갑니다. 즉, FAT를 사용하면 정전시 임시 파일을 포함한 파일 링크가 손실 될 가능성이 없습니다. 그러나 Linux에서는 inode 테이블이 지속적으로 작성되므로 정전시 파일에 대한 액세스 권한이 사실상 상실됩니다.

이를 완화하기 위해 수행 할 수있는 유일한 방법은 디스크 캐싱을 끄는 것입니다.