☰

실수

tag-icon • tag-icon debian tar corruption
실수

이것을 디버깅하는 방법은 무엇입니까? 이 문제는 지난 이틀 동안 갑자기 나타났습니다. 웹사이트의 모든 백업이 손상되었습니다.

백업을 그대로 두면 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

압축을 깨는 데이터가 있어야 합니다.

또한 다음을 수행하여 하드 드라이브의 상태를 확인해 보았습니다.

# 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가 손상된 파일을 찾는 방법은 무엇입니까? 그냥 삭제하고 싶어요.

고쳐 쓰다

이제 모든 파일을 다른 서버에 복사했는데도 똑같은 문제가 발생했습니다. 모든 것을 압축하고 문제 없이 추출할 수 있지만 파일을 압축하려는 순간 압축을 풀 수 없습니다(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운영 체제가 손상을 감지하지 못했지만 파일은 여전히 ​​유효하지 않습니다(손상되거나 잘림). 어느 쪽이든 파일을 복구할 수는 없습니다. 오프라인 백업에서 복원해야 합니다.

답변2

손상된 tar 파일을 생성하는 방법에 대해 아무것도 볼 수 없습니까?

웹사이트에서 백업한 것이라고 하는데, 보여주시는 문제들은 모두 복원/추출 시 발생하는 문제이므로 (출처)에서 문제 해결이 필요합니다.

백업을 다른 컴퓨터/위치로 옮긴 후 파일의 압축을 풀 수 없다면 해당 파일이 잘못 생성되었거나 전송 중에 손상된 것일 수 있습니다.

오류의 원인을 찾으려면:

  • 네트워크 서버에서 수동으로 백업 생성( 포함 pv및 제외 -i)
  • 네트워크 서버에서 수동으로 백업 테스트( 포함 pv및 제외 -i)

지금까지 문제가 발견되지 않은 경우:

  • 웹 서버에서 백업 복사
  • 대상 머신에서 복제된 백업을 테스트합니다( 포함 pv및 제외 -i).

지금까지 문제가 발견되지 않은 경우 백업 스크립트는 수동으로 생성된 것처럼 아카이브를 생성하지 않습니다(수동으로 생성하도록 수정해야 할 수도 있음).

또한 모든 관련 명령에 대해 절대 경로를 사용해야 합니다. 시스템에 불량 $PATH및/또는 변수 및 침입자 가 있는 경우 트로이 목마 바이너리를 사용하고 있을 수 있으며 이로 인해 예상치 못한 부작용이 발생할 수 있습니다.$LD_LIBRARY_PATH

tar물론, 두 시스템이 모두 데비안이 아닌 이상 호환되지 않는 버전 도 포함될 수 있습니다. 강제로 시도해볼 수 있습니다.POSIX- 양면 모드.

답변3

사용 중인 플래그 의 긴 형식 -i은 입니다 --ignore-zeros. 이것이 tar가 파일 손상에 대해 불평하지 않는 이유입니다. 따라서 tar 파일을 디버그하려면 해당 -i옵션을 제거하면 손상된 파일 목록이 표시됩니다.

UNIX에서 (일반적으로) 손상된 파일을 찾는 다른 두 가지 방법이 있습니다. 나는 다른 질문에 주어진 대답을 인용합니다.

rsync를 사용하여 디렉터리를 복사할 수 있으며 오류로 인해 rsync가 종료되면 종료 지점에서 복제를 다시 시작할 수 있습니다.

rsync의 --dry-run옵션을 사용하면 실제로 아무것도 복사하지 않고도 복사될 내용을 확인할 수 있습니다. --stats옵션 --progress도 유용합니다. 또는 읽기가 --human-readable더 -h쉽습니다.

예를 들어

rsync --dry-run -avh --stats --progress /path/to/src/ /path/to/destination/

Mac OS X에 rsync가 기본적으로 설치되어 있는지는 확실하지 않지만 Mac에서 사용해 본 적이 있어서 확실히 사용할 수 있다는 것을 알고 있습니다.

하위 디렉터리의 파일을 읽을 수 있는지 빠르게 확인하려면 grep -r XXX /path/to/directory/ > /dev/null출력이 삭제되므로 검색 정규식은 중요하지 않습니다.

STDOUT은 /dev/null로 리디렉션되므로 오류만 표시됩니다.

여기서 grep을 선택한 유일한 이유는 -R재귀 옵션 때문입니다. 여기에는 grep 대신 사용할 수 있는 다른 명령이 많이 있으며 find와 함께 사용하면 훨씬 더 많은 명령이 있습니다.

참조:손상된 파일 찾기

답변4

@MattBianco의 답변에 대한 추론은 내가 체계적으로 따르는 것입니다.해결하다이 특별한 문제.

블록을 0으로 만드는 것은 EOF를 나타내지만 이는 블록 요소에 따라 다릅니다(기본값은 컴파일 상수, 일반적으로 20입니다). tar의 --compare|는 ( )를 사용하여 암시적으로 수행 --diff되는 것 같습니다 .--ignore-zeros-i

문제를 일으키는 것으로 pv의심되는 추가적인 복잡성을 고려하여 다음을 확인하십시오.tar -ixz차단 요인에 대한 Tar Man의 영향먼저 제거하는 것이 좋습니다-i

그런 다음 도움이 되지 않으면 다음으로 교체하세요.

--read-full-records --blocking-factor=300

구글링을 하다가 이 글을 보고 계시다면"tar: N에 단일 제로 블록", 배관을 하지 않고 시도하십시오 --ignore-zeros.

관련 정보