이것을 디버깅하는 방법은 무엇입니까? 이 문제는 지난 며칠 사이에 갑자기 나타났습니다. 웹사이트의 모든 백업이 손상되었습니다.
백업을 로 그냥 두면 tar문제가 없지만 tar가 로 압축되자마자 gz압축 xz을 풀 수 없습니다.
사용 가능한 디스크가 많이 있습니다.
Local disk space 2.68 TB total / 2.26 TB free / 432.46 GB used
오류
tar: Skipping to next header[===============================> ] 39% ETA 0:01:14
tar: A lone zero block at 2291466===============================> ] 44% ETA 0:01:13
tar: Exiting with failure status due to previous errors
878MiB 0:00:58 [15.1MiB/s] [===================================> ] 44%
그리고 왜 그렇게 말합니까 Skipping to next header? 이전에는 그런 일을 한 적이 없습니다. 일부 파일에 심각한 문제가 있습니다.
디렉토리에는 약 15,000개의 pdf, jpg 또는 png 파일이 있습니다.
명령
pv $backup_file | tar -izxf - -C $import_dir
압축을 손상시키는 일부 데이터가 있어야 합니다.
또한 다음을 수행하여 HDD 상태를 확인하려고 시도했습니다.
# getting the drives
lsblk -dpno name
smartctl -H /dev/sda
smartctl -H /dev/sdb
두 드라이브 모두에서 다음을 얻습니다.
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
tar.gz를 손상시키는 파일을 어떻게 찾을 수 있습니까? 그냥 삭제하고 싶어요.
업데이트
이제 모든 파일을 다른 서버에 복사했는데 똑같은 문제가 발생했습니다. 모든 것을 tar하고 문제 없이 추출할 수 있지만, 파일을 압축하려고 하면 압축을 풀 수 없습니다(gz/xz).
답변1
파일이 잘렸거나 손상되어 xz데이터 끝까지 도달할 수 없습니다. tar아카이브가 중간에 중지되기 때문에 불평하는데, 이는 xz전체 데이터를 읽을 수 없었기 때문에 논리적입니다.
다음 명령을 실행하여 문제가 있는 위치를 확인하십시오.
cat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null
xzcat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null
불만이 제기 되면 cat디스크의 파일이 손상된 것이며 운영 체제가 손상을 감지한 것입니다. 자세한 내용은 커널 로그를 확인하세요. 일반적으로 이 시점에서 디스크를 교체해야 합니다. 불만 만 있는 경우 xz에는 OS가 손상을 감지하지 못했지만 그럼에도 불구하고 파일은 유효하지 않습니다(손상되었거나 잘렸음). 어느 쪽이든 이 파일을 복구할 수는 없습니다. 오프라인 백업에서 다시 가져와야 합니다.
답변2
깨진 tar 파일이 어떻게 생성되는지에 대한 언급이 없나요?
웹사이트에서 백업한 것이라고 말씀하셨는데, 보여지는 문제들은 모두 복원/압축해제할 때 나타나는 문제이므로 거기(소스)에 문제해결 노력을 하셔야 할 부분이 있습니다.
백업을 다른 머신/위치로 옮긴 후 파일의 압축을 풀 수 없는 경우 파일이 잘못 생성되었거나 전송 중에 손상된 것입니다.
오류의 원인을 찾으려면:
- 웹 서버에서 수동으로 백업 생성(없이
pv또는 없이-i) - 웹 서버에서 백업을 수동으로 테스트합니다(없이
pv또는 없이-i).
지금까지 문제가 발견되지 않은 경우:
- 웹 서버에서 백업을 복사하세요
- 대상 머신에서 복사된 백업을 테스트합니다( 없이
pv및 제외-i).
지금까지 문제가 발견되지 않은 경우 백업 스크립트는 수동으로 수행할 때와 동일한 방식으로 아카이브를 생성하지 않습니다(수동으로 수행한 작업을 수행하도록 수정해야 할 수도 있음).
또한 관련된 모든 명령의 절대 경로를 사용해야 합니다. 시스템에 불량 $PATH및/또는 $LD_LIBRARY_PATH변수가 있고 침입자가 있는 경우 트로이 목마 바이너리를 사용하고 있을 수 있으며 이로 인해 의도하지 않은 부작용이 발생할 수 있습니다.
물론 tar두 시스템이 모두 데비안이 아닌 이상 호환되지 않는 버전일 수도 있습니다. 강제로 시도해 볼 수도 있습니다.POSIX- 양쪽 모드.
답변3
-i긴 형식의 플래그를 사용하고 있습니다 --ignore-zeros. 이것이 tar가 손상된 파일에 대해 불평하지 않는 이유입니다. 따라서 tar 파일을 디버그하려면 -i옵션을 제거하면 손상된 파일 목록이 표시됩니다.
유닉스에서 (일반적으로) 손상된 파일을 찾는 다른 두 가지 방법도 있습니다. 다른 질문에 나온 답변을 인용하겠습니다.
rsync는 디렉터리를 복사하는 데 사용할 수 있으며, 오류로 인해 rsync가 종료되는 경우 복사가 종료된 지점부터 복사본을 다시 시작할 수 있습니다.
rsync의
--dry-run옵션을 사용하면 실제로 아무것도 복사하지 않고도 복사되는 내용을 확인할 수 있습니다. 및--stats옵션--progress도 유용할 것입니다. 또는 읽기가--human-readable더-h쉽습니다.예를 들어
rsync --dry-run -avh --stats --progress /path/to/src/ /path/to/destination/
rsync가 Mac OS X에 기본적으로 설치되어 있는지는 확실하지 않지만 Mac에서 rsync를 사용해 본 적이 있기 때문에 확실히 사용할 수 있다는 것을 알고 있습니다.
하위 디렉터리의 파일을 읽을 수 있는지 여부를 빠르고 간단하게 확인하려면
grep -r XXX /path/to/directory/ > /dev/null. 어쨌든 출력이 삭제되기 때문에 검색 정규식은 중요하지 않습니다.STDOUT이 /dev/null로 리디렉션되므로 오류만 표시됩니다.
여기서 grep을 선택한 유일한 이유는
-R재귀 옵션 때문이었습니다. 여기에서는 grep 대신 사용할 수 있는 다른 명령이 많이 있으며, find와 함께 사용하면 더 많은 명령이 가능합니다.
참고로:손상된 파일 찾기
답변4
@MattBianco의 답변에 대한 추론은 내가 체계적으로 따르는 것입니다.해결하다이 특별한 문제.
0으로 지정된 블록은 EOF를 나타내지만 이는 차단 요소에 따라 다릅니다(기본값은 컴파일된 상수, 일반적으로 20). 타르의 --compare| ( ) --diff로 암시적으로 실행되는 것으로 보입니다 .--ignore-zeros-i
의 추가적인 복잡성을 고려 하면 에 대한 문제를 일으키는 것으로 pv의심됩니다.tar -ixz차단 요인에 대한 타르 맨먼저 제거하는 것이 좋습니다-i
그런 다음 도움이 되지 않으면 다음으로 교체하세요.
--read-full-records --blocking-factor=300
구글링을 해서 이 글을 읽고 있다면"tar: N에 있는 단일 제로 블록", 아무것도 파이핑하지 않는 경우 시도해 보세요 --ignore-zeros.