전원 손실로 인한 SSD 손상을 방지 할 수있는 방법이 있습니까? 기계에 대한 현장 보고서를 받고

Linux, 로컬 웹 서버 및 PostgreSQL이 설치된 소비자 단말기 그룹이 있습니다. 문제가있는 기계에 대한 현장 보고서를 받고 있으며 조사 결과 정전이 발생한 것으로 보이며 이제 디스크에 문제가있는 것 같습니다.

문제는 데이터베이스가 손상되었거나 최근 변경 사항이있는 파일이 스크램블 된 것으로 가정했지만 다른 이상한 보고서가 있습니다.

  • 권한이 잘못된 파일
  • 디렉토리가 된 파일 (예 index.php: 이제 디렉토리 임)
  • 파일이 된 디렉토리
  • 스크램블 된 데이터가있는 파일

데이터베이스가 손상되는 데 문제가 있지만 예상했던 것입니다. 더 놀랍게도 권한이나 파일을 디렉토리로 변경하는 것과 같은보다 기본적인 파일 시스템 문제입니다. 최근에 변경되지 않은 파일 (예 : 소프트웨어 코드 및 구성)에서도 문제가 발생합니다.

이것이 SSD 손상에 대한 “정상”입니까? 원래 우리는 그것이 싼 SSD에서 일어나고 있다고 생각했지만, 이것은 유명 브랜드 (소비자 등급)에서 일어나고 있습니다.

FWIW, 우리는 부정한 부팅에서 autofsck을 수행하지 않습니다 (왜 새로운 지 모르겠습니다). 일부 지역에는 UPS가 설치되어 있지만 때로는 제대로 수행되지 않는 등의 경우도 있습니다.이 문제는 해결되어야하지만 사람들은 터미널의 전원을 불결하게 끄는 등의 작업을 수행 할 수 있습니다. 파일 시스템은 ext4입니다.

문제는 시스템 수준에서 문제를 완화하기 위해 할 수있는 일이 있습니까?

하드웨어 캐시를 끄거나 드라이브를 동기화 모드로 마운트하는 것에 관한 기사를 찾았지만이 경우 도움이 될지 확실하지 않습니다 (메타 데이터 손상 및 최근이 아닌 변경). 또한 파일 시스템을 읽기 전용 모드로 마운트하는 것에 대한 참조를 읽었습니다. 우리는 쓰기가 필요하기 때문에 그렇게 할 수 없지만 도움이된다면 코드와 구성을위한 읽기 전용 파티션을 만들 수 있습니다.

다음은 드라이브의 예입니다 sudo hdparm -i /dev/sda1.

Model=KINGSTON RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7

답변

갑자기 전원이 꺼지면 MLC / TLC / QLC SSD에는 두 가지 장애 모드가 있습니다.

  • 기내 및 DRAM 전용 쓰기를 잃습니다.
  • 프로그래밍중인 NAND 셀의 아래쪽 페이지에 저장된 미사용 데이터를 손상시킬 수 있습니다.

첫 번째 고장 조건은 분명합니다. 전원 보호가 없으면 안정적인 스토리지 (예 : NAND 자체)가 아닌 휘발성 캐시 전용 (DRAM)에있는 데이터가 손실됩니다. 고전적인 기계식 디스크에서도 마찬가지입니다 (그리고 fsync를 제대로 발행하지 않는 파일 시스템을 혼란스럽게 만들 수도 있습니다).

두 번째 실패 조건은 MLC + SSD입니다. 새로운 데이터를 저장하기 위해 높은 페이지 비트를 다시 프로그래밍 할 때 예기치 않은 전력 손실로 인해 하위 비트 (예 : 이전 커밋 된 데이터)도 파괴 / 변경 될 수 있습니다.

유일하고 진실한 유일한 해결책은 고급 RAID 컨트롤러가 영원히 사용했던 것처럼 전력 손실 방지 DRAM 캐시 (일반적으로 배터리 / 슈퍼 캡 사용)를 통합하는 것입니다. 그러나 이것은 드라이브 비용 / 가격을 증가시킵니다. 소비자 드라이브에는 일반적으로 전원 손실 보호 캐시가 없습니다. 오히려 다음과 같이보다 경제적 인 솔루션을 사용합니다.

  • 부분적으로 보호 된 쓰기 캐시 (즉 : Crucial M500 / M550 / M600 +);
  • NAND 변경 저널 (예 : 삼성 드라이브, SMART PoR 속성 참조);
  • 특별한 SLC / 의사 -SLC NAND 영역은 이전 데이터의 위험없이 새로운 쓰기를 흡수합니다 (예 : Sandisk, Samsung 등).

귀하의 질문으로 돌아가십시오 : Kingstone 드라이브는 지정되지 않은 컨트롤러를 사용하고 기본적으로 공개 사양이없는 매우 저렴한 드라이브입니다. 갑작스런 정전으로 인해 이전 데이터가 손상되었다는 것은 놀라운 일이 아닙니다. 불행히도, 디스크의 DRAM 캐시를 비활성화하더라도 (대량의 성능 손실 명령으로) 이전 데이터 (즉, 미사용 데이터)가 예기치 않은 전력 손실로 인해 손상 될 수 있으므로 문제를 해결 하지 못합니다 . 이들이 이전 Sandforce 컨트롤러를 기반으로하는 경우 “올바른”상황에서 전체 드라이브 브릭도 예상 할 수 있습니다.

UPS를 검토하고 중간에 이러한 노후화 드라이브를 교체 할 것을 적극 권장합니다.

PostgreSQL를 다른 리눅스 데이터베이스에 대한 마지막주의 사항 : 그들은 것 없는 디스크의 캐시를 비활성화해야 하지 그렇게 exptected한다. 오히려, 주요 데이터를 안정적인 스토리지에 커밋하기 위해 주기적 / 필수 fsync / FUA를 발행합니다. 이것은 매우 설득력있는 이유가 존재 하지 않는 한 (즉, ATA FLUSHES / FUA에 관한 드라이브) 수행하지 않는 방법 입니다.

편집 : 가능하면 체크섬 파일 시스템으로 ZFS 또는 BTRFS로 마이그레이션하는 것이 좋습니다. 최소한 저널 체크섬과 최근 메타 데이터 체크섬이있는 XFS를 고려하십시오. EXT4를 사용해야하는 경우 시작시 auto-fsck를 활성화하십시오 (fsck.ext4는 복구 손상에 매우 적합합니다).

답변

네. 초저가 SSD를 구입하지 마십시오. 저가형 소비자 시장 이외의 모든 제품에는 커패시터와 전력 손실에 대한 완벽한 보호 기능이 있습니다. Amd는 실제로 그렇게 많은 비용을 들이지 않습니다.

답변

가장 먼저해야 할 일은 복구 시간과 복구 지점 목표를 정의하는 것입니다. 이 터미널 중 하나를 얼마나 오래 복구해야하며 어떤 데이터 시점이 허용됩니까? 아마도 몇 시간 내에 지난 주 백업으로 복구 할 수 있어야합니다.

비행 중 쓰기가 손실되면 모든 종류의 이상한 일이 파일에 발생할 수 있습니다. 파일 시스템 우선 순위는 고유 한 메타 데이터 일관성을 유지하므로 데이터에 대해 동일한 보장을 제공하지 않을 수 있습니다. 다시 말해, fsck데이터 복구가 보장되지는 않습니다. 그 일은 마운트 할 파일 시스템을 얻는 것입니다.

그래서 힘. UPS가 시스템을 정상적으로 종료하는지 설치, 구성 및 테스트하십시오. 이를 통해 파일 시스템 캐시 및 드라이브 자체에 쓸 수 있습니다.

그리고 디스크 쓰기의 내구성. PostgreSQL의 안정성 장을 읽으십시오 . diskchecker.pl여기에 링크 된 스크립트를 사용하여 충돌 테스트를 수행하고 쓰기가 비 휘발성 스토리지에 있는지 SSD가 거짓말하는지 판별하십시오. 손실이있는 경우 전력 손실 방지 기능이있는 것으로 알려진 SSD로 교체하는 것이 좋습니다.

편집 : 쓰기 캐시가 활성화 된 세부 정보를 추가했습니다. hdparm -W0 /dev/sda하드웨어 어레이에 해당 명령 또는 해당 명령 을 비활성화 할 수 있습니다 . 참조 : RHEL 스토리지 관리 안내서 .

파일 시스템 쓰기 장벽은 저널 커밋 순서를 강제합니다. 데이터가 손상되지 않는다고 보장하는 것은 아니지만 휘발성 캐시가있는 파일 시스템에 대해 더 안전합니다. 이것이 기본값이지만 “배리어”마운트 옵션을 추가하면 성능 대비 일관성을 중요하게 문서화 할 수 있습니다.

마지막으로 마지막 방어선. 응용 프로그램 및 데이터베이스를 원하는 시점으로 가져올 수 있도록 복원 테스트를 수행하십시오. 이것은 정전뿐만 아니라 모든 종류의 데이터 손실에 유용합니다.

답변