데이터 파손

Data corruption
여기서 "파손" 리다이렉트 합니다.일본 금속 밴드에 대해서는 파손(밴드)을 참조해 주세요.
포토 데이터의 파손.이 경우는, 하드 디스크 드라이브로부터의 데이터 리커버리의 장해가 원인입니다.
파손된 RAM이 있는 Atari 2600의 사진.

데이터 손상이란 쓰기, 읽기, 저장, 전송 또는 처리 중에 발생하는 컴퓨터 데이터의 오류를 말합니다. 이 오류로 인해 원래 데이터가 의도하지 않게 변경됩니다.컴퓨터, 전송 및 스토리지 시스템은 엔드 투 엔드의 데이터 무결성 또는 오류 부족을 제공하기 위해 여러 가지 방법을 사용합니다.

비트가 1개 변경되어 PNG 이미지가 손상됨

일반적으로 데이터 파손이 발생하면 해당 데이터를 포함하는 파일은 시스템 또는 관련 응용 프로그램에서 액세스할 때 예기치 않은 결과를 생성합니다.결과는 사소한 데이터 손실에서 시스템 충돌까지 다양합니다.예를 들어 문서 파일이 손상된 경우, 문서 편집기를 사용하여 파일을 열려고 하면 오류 메시지가 표시되므로 파일이 열리지 않거나 일부 데이터가 손상된 상태로 열 수 있습니다(또는 일부 경우 문서가 완전히 손상되어 알 수 없는 상태로 남아 있습니다.인접한 이미지는 대부분의 정보가 손실된 이미지 파일입니다.

일부 유형의 멀웨어는 일반적으로 작동하지 않거나 가비지 코드로 덮어쓰기하여 페이로드의 일부로 의도적으로 파일을 손상시킬 수 있으며, 악성 바이러스가 아닌 바이러스도 파일에 액세스할 때 의도하지 않게 파일을 손상시킬 수 있습니다.이 페이로드 방식의 바이러스 또는 트로이 목마가 컴퓨터의 운영 체제 소프트웨어 또는 물리적 하드웨어 실행에 중요한 파일을 변경하는 데 성공했을 경우 시스템 전체를 사용할 수 없게 될 수 있습니다.

일부 프로그램에서는 오류 발생 후 자동으로 파일을 복구하도록 제안할 수 있으며 일부 프로그램에서는 파일을 복구할 수 없습니다.파손의 정도와 에러를 처리하기 위한 애플리케이션의 내장 기능에 의해서 다릅니다.부패의 원인은 다양하다.

개요

비디오가 파손되었습니다.경고: 이 비디오에는 밝은 플래시 이미지가 포함되어 있습니다.

컴퓨터 시스템과 관련된 데이터 손상에는 탐지되지 않은 것과 탐지되지 않은 것의 두 가지 유형이 있습니다.감지되지 않은 데이터 손상(사일런트 데이터 손상이라고도 함)은 데이터가 잘못되었다는 징후가 없기 때문에 가장 위험한 오류를 초래합니다.검출된 데이터의 파손은 데이터의 손실로 영속적인 경우가 있습니다.또, 시스템의 일부가 에러를 검출해 수정할 수 있는 경우는 일시적인 경우가 있습니다.후자의 경우 데이터 파손은 없습니다.

호스트에서 스토리지 미디어에 이르기까지 시스템의 모든 수준에서 데이터가 손상될 수 있습니다.최신 시스템은 많은 레이어에서 파손을 검출하여 복구 또는 수정을 시도하고 있습니다.이는 거의 항상 성공하지만 시스템 메모리에 도달하는 정보가 파손되어 예측 불가능한 결과를 초래할 수 있는 경우는 거의 없습니다.

송신중의 데이터 파손에는, 다양한 원인이 있습니다.데이터 전송이 중단되면 정보가 손실됩니다.환경조건은 데이터 전송을 방해할 수 있으며, 특히 무선 전송 방식을 다룰 때는 더욱 그렇습니다.짙은 구름은 위성 송신을 방해할 수 있다.무선 네트워크는 전자레인지 등의 디바이스로부터의 간섭에 취약합니다.

하드웨어 및 소프트웨어 장애가 데이터 손실의 두 가지 주요 원인입니다.백그라운드 방사선, 헤드 크래시, 스토리지 디바이스의 노후화 또는 마모는 전자의 범주에 속하지만 소프트웨어 장애는 일반적으로 코드의 버그로 인해 발생합니다.우주선은 [1]DRAM의 대부분의 소프트 에러를 일으킵니다.

사일런트

다음 항목도 참조하십시오.하드 디스크 드라이브의 에러율과 처리

일부 오류는 디스크 펌웨어 또는 호스트 운영 체제에서 감지되지 않고 인식되지 않습니다. 이러한 오류를 사일런트 데이터 손상이라고 합니다.

디스크 스토리지 서브시스템 자체 이외에도 많은 오류 원인이 있습니다.예를 들어, 케이블이 약간 느슨하거나,[2] 전원의 신뢰성이 떨어지거나, 큰 [3]소리등의 외부 진동, 네트워크에 검출되지 않는 파손,[4] 우주 복사등의 소프트 메모리 에러의 원인이 되는 경우가 있습니다.분석한 39,000대의 스토리지 시스템에서 펌웨어 버그가 스토리지 [5]장애의 5~10%를 차지했습니다.전반적으로 CERN의 침묵 손상 연구에서 관찰된 오류율은 10비트당16 [6]1개보다 훨씬 높습니다.Webshop Amazon.com에서는 마찬가지로 [7]높은 데이터 파손률을 보이고 있습니다.2021년에 Google과 Facebook에 의해 프로세서 코어의 결함이 추가 원인으로 확인되었습니다.코어는 수천 [8][9]개의 코어 중 몇 개의 코어의 비율로 결함이 발견되었습니다.

한 가지 문제는 하드 디스크 드라이브의 용량이 크게 증가했지만 오류율은 변하지 않았다는 것입니다.데이터 손상률은 항상 일정하므로 최신 Disk는 이전 Disk보다 훨씬 안전하지 않습니다.이전 Disk에서는 적은 양의 데이터를 저장하기 때문에 데이터 손상 가능성이 매우 낮았습니다.최신 디스크는 훨씬 더 많은 데이터를 저장하지만 안전하지는 않기 때문에 가능성이 훨씬 더 큽니다.이렇게 하면 스토리지 장치가 비교적 작고 느린 상태로 유지되는 동안 조용한 데이터 손상은 심각한 문제가 되지 않았습니다.오늘날에는 대용량 드라이브와 매우 빠른 RAID 설정이 등장함에 따라 사용자는 상당히 짧은 시간에 10비트를 전송할16 수 있으며, 따라서 데이터 [10]손상 임계값에 쉽게 도달할 수 있습니다.

예를 들어, ZFS의 크리에이터 Jeff Bonwick은 대규모 데이터 웨어하우징 및 분석을 전문으로 하는 데이터베이스 소프트웨어 회사인 Greenplum의 빠른 데이터베이스가 [11]15분마다 소리 없는 손상을 겪는다고 말했습니다.또 다른 예로, NetApp이 41개월 동안 150만 개 이상의 HDD에 대해 수행한 실제 연구에서 400,000개 이상의 자동 데이터 손상이 발견되었으며, 이 중 30,000개 이상이 하드웨어 RAID 컨트롤러에 의해 감지되지 않았습니다.CERN이 6개월에 걸쳐 약 97페타바이트의 데이터를 대상으로 수행한 또 다른 연구에서는 약 128메가바이트의 데이터가 영구적으로 손상된 [12][13]것으로 나타났습니다.

사일런트 데이터가 파손되면 캐스케이드 장애가 발생할 수 있습니다.이 경우 시스템이 검출되지 않은 초기 에러로 인해 최종적으로 검출될 때까지 더 많은 문제가 발생할 [14]수 있습니다.예를 들어 파일 시스템 메타데이터에 영향을 미치는 장애는 파일 시스템이 손상된 상태에서 사용되므로 여러 파일이 부분적으로 손상되거나 완전히 액세스할 수 없게 됩니다.

대책

다음 항목도 참조하십시오.오류 검출 및 수정

데이터 손상이 포아송 프로세스로 동작하는 경우, 각 비트가 독립적으로 변경될 확률이 낮습니다. 일반적으로 체크섬을 사용하여 데이터 손상을 감지할 수 있으며 오류 수정 코드(ECC)를 사용하여 데이터를 수정할 수 있습니다.

수정할 수 없는 데이터 손상이 감지되면 자동 재전송 또는 백업으로부터의 복원과 같은 절차를 적용할 수 있습니다.RAID 디스크 어레이의 특정 레벨에는 하드 디스크 세트 전체에 걸쳐 데이터의 패리티 비트를 저장하고 평가하는 기능이 있으며, 구현된 RAID 레벨에 따라 1개 또는 여러 개의 디스크에 장애가 발생했을 때 손상된 데이터를 재구성할 수 있습니다.일부 CPU 아키텍처에서는 다양한 투과 체크를 사용하여 CPU 캐시, CPU 버퍼 및 명령 파이프라인의 데이터 파손을 검출하고 경감합니다.예를 들어 인텔 Itanium [15]프로세서에서 사용할 수 있는 인텔 Instruction Replay 테크놀로지가 있습니다.

많은 에러는, 섹터 마다 디스크에 격납되어 있는 ECC[16] 코드를 사용해 하드 디스크 드라이브에 의해서 검출되어 수정됩니다.디스크 드라이브가 섹터에서 여러 읽기 오류를 검출한 경우, OS를 사용하지 않고 디스크의 고장난 섹터를 스페어 섹터에 재매핑함으로써 디스크의 다른 부분에 장애가 발생한 섹터의 복사본을 만들 수 있습니다(다만, 이 섹터는 다음 섹터에 쓸 때까지 지연될 수 있습니다).이 「사일런트 수정」은, SMART 파라미터의 악화를 감시하는 것으로써, 대부분의 operating system에 이용 가능한 툴과 S.M.A.R.T.를 사용해 감시할 수 있습니다.

Btrfs, HAMMER, ReFS 및 ZFS와 같은 일부 파일 시스템은 내부 데이터 및 메타데이터 체크섬을 사용하여 사일런트 데이터 손상을 탐지합니다.또, 파손이 검출되어 파일 시스템이 데이터의 용장성을 제공하는 통합 RAID 메커니즘을 사용하고 있는 경우, 이러한 파일 시스템은 파손된 데이터를 투과적으로 [17]재구성할 수도 있습니다.이 접근 방식을 사용하면 스토리지 스택의 서로 다른 계층에 걸쳐 있지 않고 데이터가 서로 다른 [18]계층 간에 경계를 통과하는 동안 데이터 손상이 발생하는 다른 데이터 무결성 접근 방식에 비해 데이터 경로 전체를 포괄하는 데이터 무결성 보호가 향상됩니다. 이 접근 방식은 일반적으로 엔드 투 엔드 데이터 보호라고 합니다.

데이터 스크러빙은 여러 오류가 누적되어 패리티 비트 수를 초과하기 전에 Disk 오류를 포착하고 복구하므로 데이터 손상 가능성을 줄이는 또 다른 방법입니다.판독마다 패리티를 체크하는 대신 디스크의 정기적인 스캔 중에 패리티를 체크합니다.이는 보통 우선순위가 낮은 백그라운드프로세스로 실행됩니다."데이터 스크러빙" 작업을 수행하면 패리티 검사가 활성화됩니다.사용자가 디스크에서 데이터를 읽는 일반 프로그램을 실행하는 경우 읽기 시 패리티 체크가 디스크 서브시스템에서 모두 지원되고 활성화되지 않는 한 패리티는 체크되지 않습니다.

데이터 손상을 검출하고 복구하기 위해 적절한 메커니즘을 사용하면 데이터 무결성을 유지할 수 있습니다.이는 감지되지 않은 오류로 인해 데이터베이스 인덱스가 손상되거나 계정 잔액에 큰 영향을 미치도록 데이터를 변경할 수 있는 상용 애플리케이션(예: 뱅킹)과 작은 오류로 인해 광범위한 데이터 세트를 사용할 [6]수 없게 될 수 있는 암호화 또는 압축 데이터 사용에서 특히 중요합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Scientific American (2008-07-21). "Solar Storms: Fast Facts". Nature Publishing Group. Archived from the original on 2010-12-26. Retrieved 2009-12-08.
  2. ^ Eric Lowe (16 November 2005). "ZFS saves the day(-ta)!". Oracle – Core Dumps of a Kernel Hacker's Brain – Eric Lowe's Blog. Oracle. Archived from the original (Blog) on 5 February 2012. Retrieved 9 June 2012.
  3. ^ bcantrill (31 December 2008). "Shouting in the Datacenter" (Video file). YouTube. Archived from the original on 3 July 2012. Retrieved 9 June 2012.
  4. ^ jforonda (31 January 2007). "Faulty FC port meets ZFS" (Blog). Blogger – Outside the Box. Archived from the original on 26 April 2012. Retrieved 9 June 2012.
  5. ^ "Are Disks the Dominant Contributor for Storage Failures? A Comprehensive Study of Storage Subsystem Failure Characteristics" (PDF). USENIX. Archived (PDF) from the original on 2022-01-25. Retrieved 2014-01-18.
  6. ^ a b Bernd Panzer-Steindel (8 April 2007). "Draft 1.3". Data integrity. CERN. Archived from the original on 27 October 2012. Retrieved 9 June 2012.
  7. ^ "Observations on Errors, Corrections, & Trust of Dependent Systems". Archived from the original on 2013-10-29.
  8. ^ Hochschild, Peter H.; Turner, Paul Jack; Mogul, Jeffrey C.; Govindaraju, Rama Krishna; Ranganathan, Parthasarathy; Culler, David E.; Vahdat, Amin (2021). "Cores that don't count" (PDF). Proc. 18th Workshop on Hot Topics in Operating Systemsda: 9–16. doi:10.1145/3458336.3465297. ISBN 9781450384384. S2CID 235311320. Archived (PDF) from the original on 2021-06-03. Retrieved 2021-06-02.
  9. ^ HotOS 2021: Cores That Don't Count (Fun Hardware), archived from the original on 2021-12-22, retrieved 2021-06-02
  10. ^ "Silent data corruption in disk arrays: A solution". NEC. 2009. Archived from the original (PDF) on 29 October 2013. Retrieved 14 December 2020.
  11. ^ "A Conversation with Jeff Bonwick and Bill Moore". Association for Computing Machinery. November 15, 2007. Archived from the original on 16 July 2011. Retrieved 14 December 2020.
  12. ^ David S. H. Rosenthal (October 1, 2010). "Keeping Bits Safe: How Hard Can It Be?". ACM Queue. Archived from the original on December 17, 2013. Retrieved 2014-01-02.
  13. ^ Lakshmi N. Bairavasundaram; Garth R. Goodson; Shankar Pasupathy; Jiri Schindler (June 2007). An Analysis of Latent Sector Errors in Disk Drives. Proceedings of the International Conference on Measurements and Modeling of Computer Systems (SIGMETRICS'07). San Diego, California, United States: ACM. pp. 289–300. CiteSeerX 10.1.1.63.1412. doi:10.1145/1254882.1254917. ISBN 9781595936394. S2CID 14164251. Retrieved 9 June 2012.
  14. ^ David Fiala; Frank Mueller; Christian Engelmann; Rolf Riesen; Kurt Ferreira; Ron Brightwell (November 2012). "Detection and Correction of Silent Data Corruption for Large-Scale High-Performance Computing" (PDF). fiala.me. IEEE. Archived (PDF) from the original on 2014-11-07. Retrieved 2015-01-26.
  15. ^ Steve Bostian (2012). "Rachet Up Reliability for Mission-Critical Applications: Intel Instruction Replay Technology" (PDF). Intel. Archived (PDF) from the original on 2016-02-02. Retrieved 2016-01-27.
  16. ^ "Read Error Severities and Error Management Logic". Archived from the original on 7 April 2012. Retrieved 4 April 2012.
  17. ^ Margaret Bierman; Lenz Grimmer (August 2012). "How I Use the Advanced Capabilities of Btrfs". Oracle Corporation. Archived from the original on 2014-01-02. Retrieved 2014-01-02.
  18. ^ Yupu Zhang; Abhishek Rajimwale; Andrea Arpaci-Dusseau; Remzi H. Arpaci-Dusseau (2010). "End-to-end data integrity for file systems: a ZFS case study" (PDF). USENIX Conference on File and Storage Technologies. CiteSeerX 10.1.1.154.3979. S2CID 5722163. Wikidata Q111972797. Retrieved 2014-08-12.

외부 링크