압축할 파일을 위한 임시 파일을 만들지 않고 Linux 서버(현재 zip을 사용하지만 tar/gz/bz 파생 파일에도 열려 있음)에서 압축 파일을 업데이트하는 방법을 찾으려고 합니다.
전체 도메인의 디렉터리(주어진 시간에 약 36Gb 이상)를 압축하고 있으며 웹 서버의 드라이브 공간이 제한되어 있습니다. 문제는 zip이 새 zip 파일을 빌드할 때 완료되면 기존 zip 파일을 덮어쓸 수 있는 임시 파일을 생성하지만 그 과정에서 소스 디렉터리의 36Gb + 기존 zip 파일의 32Gb가 손실된다는 것입니다. 30Gb의 임시 파일은 내 드라이브 공간을 최대한 활용하는 데 매우 가깝고 향후 어느 시점에는 드라이브의 사용 가능한 공간을 초과하게 됩니다.
현재 디렉토리는 아래와 같이 cronjob 명령을 사용하여 백업되고 있습니다.0 0 * * * zip -r -u -q /home/user/SiteBackups/support.zip /home/user/public_html/support/
매번 zip 파일을 삭제하고 싶지는 않습니다. 첫째, 디렉터리가 4시간마다 압축되고 디렉터리가 너무 크기 때문에 단순히 업데이트하는 대신 전체 디렉터리를 다시 압축하는 것은 상당한 리소스 집약적입니다. 나는 그것이 사실이라고 믿습니다. 어쩌면 내가 틀렸나?
또한 대부분의 데이터(총 36Gb 중 30Gb)가 하나의 디렉터리에 있고 파일 이름이 GUID이므로 예측 가능한 방식으로 파일을 찾을 수 있는 방법이 없기 때문에 이를 다른 디렉터리에 대해 여러 명령으로 나누는 것은 작동하지 않습니다. .
시스템 관리자의 일부 터미널 주짓수에 대해 미리 감사드립니다!
답변1
이것은 거의 확실하게 작동하지 않을 것입니다(고쳐 쓰다: 당신도 볼 수 있습니다이것답변)
Zip 아카이브(다른 아카이브와 크게 다르지 않음)는 파일 시스템처럼 구축됩니다.
File#2를 이동하지 않고 File#1을 업데이트하고 File#1을 사용할 수도 있다고 가정합니다.더 큰일단 압축. 여기에는 다음이 필요합니다.
- 중앙 제목 삭제
- File#2 뒤에 File#1 데이터 추가(두 번째 복사본)
- 중앙 헤더를 다시 추가하고 File#1의 오프셋을 업데이트합니다.
Zip 파일 시작 부분에 "데드 존"을 만듭니다. 이것은 ~이 될 것이다가능한이 영역을 사용하여 다른 파일을 추가로 저장하세요. 기본적으로 수신 파일을 임시 파일로 압축하여 최종 크기를 얻어야 합니다. zip 파일을 스캔하여 "누수"를 찾을 수 있습니다. 적합한 "구멍"이 존재하는 경우 zip 파일 내의 임시 파일을 복사하고, 그렇지 않으면 중앙 헤더를 교체하여 추가하십시오.
하지만가능한, Zip 아카이브 내의 여유 공간을 관리하고 인접한 "구멍"을 병합하려면 주의가 필요하며, 내가 아는 한 아무도 이 작업을 수행하지 않았습니다(예: Zip 파일 내의 파일을 대체하기 위해 압축에 구애받지 않는 유틸리티를 작성할 수 있습니다. 새로운 압축 스트림을 생성하고 이전 파일 이름을 인식 가능한 시퀀스로 대체하여 여유 공간으로 표시하는 기본 zip 유틸리티입니다.무섭게느린).
원하는 것과 가장 가까운 것은 완전히 다른 형식을 사용하는 것입니다. 예를 들어 btrfs루프 장치에 파일 시스템을 만들고 이를 사용 가능한 최대 압축으로 설정할 수 있습니다(LZO라고 생각합니다). 그런 다음 루프 장치를 설치하고 이를 사용 하여 rsync업데이트합니다. 루프 장치를 제거하기 위한 호스트 파일은 일종의 압축 아카이브입니다. 파일의 성격에 따라 btrfs중복 제거 기능을 활용할 수도 있습니다 .
압축된 파일 시스템은 Zip보다 압축률이 낮습니다.하지만여러 파일(분명히 PDF, ZIP, JPEG, PNG 및 GIF와 같은 대부분의 이미지 형식, 최신 (Libre)Office 형식...)압축할 수 없습니다, 따라서 이것은 문제가 되지 않습니다. 압축되지 않은 파일이 36Gb이고 Zip이 32Gb라고 말씀하셨기 때문에 이러한 상황에 처할 수 있으며 다음과 같은 이점을 누릴 수 있습니다.압축되지 않은체재).