많은 사람들이 여러 백업 스토리지에 데이터를 백업하는 것을 선호하므로 이는 완벽한 선택이 아닙니다.
클러스터에 있는 수백 개의 다른 서버에 연결된 서버에 저장된 비디오 파일을 가정해 보겠습니다. 백업 메커니즘은 매일 백업 스토리지에 자동으로 백업됩니다.
그런데 어느 날, 해당 비디오 파일에 영향을 미치는 배드 섹터(영구적인 디스크 손상)가 발생합니다.
백업 메커니즘은 평소대로 비디오를 백업하는 것입니다. *nix 서버는 디스크 손상으로 인해 해당 비디오 파일이 손상되었는지 알 수 없습니다. 2개월 후에는 이전 백업 스냅샷이 백업 스토리지에서 자동으로 삭제됩니다. 따라서 해당 비디오 파일의 모든 복사본은 손상된 파일입니다.
방문자가 해당 비디오 파일의 비디오를 재생하려고 하면 중간에 멈추게 됩니다. 유튜브에서 이런 일이 일어난다고 상상해 보세요. 이것은 부끄러운 일입니다.
나는 이와 같은 백업 메커니즘이 효과적이지 않고 너무 많은 공간이 필요하다고 생각합니다.
그렇다면 디스크 오류로부터 데이터를 백업하는 가장 좋은 방법은 무엇입니까?
답변1
다른 일별/시간별 백업 외에 월별 데이터 스냅샷과 같은 것일 수도 있습니다. 정적 데이터는 절대 변경되지 않으므로 지난 달 말의 백업이 전 달과 동일하다는 점에서 이점을 얻습니다.
간단한 2개월 '전체' 스타일 백업에 대해 말씀하시는 것 같습니다. 물론 이 백업은 항상 마지막 아웃 스타일에서 첫 번째가 됩니다. 2주 분량의 테이프를 사용하는 가장 기본적인 백업의 경우에도 10개의 테이프로 2주 동안 MF 백업을 수행하고 한 달이 끝날 것입니다. 매주 10개의 테이프는 항상 순환되며 가장 오래된 테이프는 항상 2주마다 덮어쓰기됩니다.
답변2
이는 이유할아버지-아버지-아들백업 순환이 사용됩니다. 사용자가 하드웨어 문제보다 파일을 더 자주 덮어쓰거나 오용했기 때문에 몇 달 동안의 테이프를 다시 살펴보게 되었습니다.
답변3
데이터 보존을 보장하기 위해 체크섬 시스템을 구현할 수 있습니다. 매주 MD5를 교차 확인하고, 체크섬 오류가 발생할 경우 백업 삭제를 중지합니다. 올바른 백업에서 문제가 있는 파일을 재생합니다.
장기간의 데이터 보존은 실제로 고통스럽습니다.
볼륨 스냅샷은 도움이 되지 않습니다. 스냅샷 사이에 파일이 기록되지 않으면 불량 블록이 VSS 캐시 파일에 복사되지 않았기 때문입니다.
답변4
특정 섹터에 영구적인 디스크 오류가 있는 경우 이에 대한 알림을 받게 되며 이 파일의 백업이 실패합니다. 하지만 로그 파일을 읽지 않는다면 운이 좋지 않을 것입니다.