오래 전에 저는 우리 웹사이트의 백업 스크립트를 작성했고 그 이후로 이를 업데이트했습니다. 그러나 때때로 문제가 발생하고 일부 오래된 백업이 이제 손상되었습니다.
과거에는 zipinfo자동화된 스크립트에서 이 유틸리티를 사용하여 이전 백업이 손상되었는지 확인한 다음 백업을 다시 시도했지만 아직 일부 zip백업이 남아 있는 동안 (적어도) 두 가지 문제가 있었습니다.
첫째, zip근본적인 한계가 있으므로 tar더 큰 규모의 백업을 사용합니다.
둘째, zip메타데이터를 많이 캡처하지 않으므로 tar특정 유형의 항목에 선호됩니다.
gzip또한 대신 피벗을 수행했으며 zip압축도 수행했습니다 tars.
이제 백업 용량이 엄청나서 무엇을 삭제하고 무엇을 보관해야 할지 고민 중입니다. 손상된 파일을 보관할 필요가 없습니다. 그래서 저는 다양한 백업 디렉터리(온사이트와 오프사이트 등)를 병합하는 스크립트를 작성 중입니다. 때로는 한 복사본은 손상되었지만 다른 복사본은 괜찮기 때문에 각 파일의 유효성을 확인해야 할 필요성을 강하게 느낍니다.
gzip버전 을 찾았 zipinfo지만 찾을 수 없습니다. 나는 그런 말을 들어본 적이 없지만 tar단지 무지할 수도 있습니다!
나는 디스크 공간을 확장하는 데 의지하고 싶지 않습니다!
답변1
에 대한 gzip:
(이는 gz, tgz및 tz파일에 적용됩니다.)
zipinfo을 기반으로 한다는 점에 주목하여 더 철저하게 unzip조사한 gzip결과 직접적인 동등한 조합은 없지만 다음 zipinfo -t과 유사한 조합이 있음을 발견했습니다 gunzip.
# gunzip -t -v [file-specification(s)]
[file-specification]: OK
하지만 원하는 출력이 stderr대신 전송된다는 점에 유의하세요 stdout! 또한 출력 콜론과 "OK" 사이에 탭이 있으므로 그에 따라 스크립트를 조정하십시오.
에 대한 tar:
위의 설명에서 지적했듯이 tar에는 우리가 원하는 검사 기능이 없지만 tar -t"아무것도 없는 것보다 나은" 솔루션을 위한 합리적인 시작이라는 점도 발견했습니다.
출력이 가 아닌 gunzip에서 나오는지 확인하는 경우와 마찬가지로 두 출력 스트림 모두 특정 하위 목표에 따라 유용할 수 있습니다.stderrstdout
엄밀히 말하면 Fedora 38의 현재 tar 버전은 다음과 같은 문제를 제기합니다.
이것은 tar 아카이브처럼 보이지 않습니다.
...아카이브가 유효하지 않은 경우. 즉, tar에 인식할 수 있는 파일이 없다고 해서 반드시 유효하지 않다는 의미는 아니며, 처음에 올바르게 빌드되지 않았을 수도 있습니다. 따라서 어떤 사람들은 이것을 유효하지 않은 아카이브라고 생각할 수도 있습니다! YMMV.