백업 프로세스는 tar 파일을 생성한 다음 gzip을 적용합니다. tar 파일에는 이미 gzip으로 압축된 SQL 덤프와 업로드된 파일의 내용(요청된 경우) 두 가지가 포함됩니다. 제 경우를 보면 모든 업로드 파일은 이미 압축되어 있습니다: gz, gzip, gif, jpeg, png, zip. 따라서 최종 gzip 압축으로 얻는 크기 절감 효과는 단 1%에 불과합니다.
더 적은 여유 공간을 요구하는 것이 더 낫다고 생각합니다.
2016년의 이전 주제에서는 백업 압축을 비활성화하는 방법에 대해 언급하고 있지만, 당시 SQL 덤프는 압축되지 않았던 것으로 보이며, 이는 트레이드오프를 변화시켰습니다.
이미 이중 압축을 제거하는 새로운 백업 형식을 개발하고 있습니다. 한두 달 안에 완성될 수 있기를 바랍니다.
좋네요 @gerhard!
이 문제에 대한 업데이트가 있나요? 감사합니다
너무 귀찮게 드리고 싶지는 않은데, 진행 상황은 어떻게 되나요?
해당 기능의 개발은 현재 일시 중단되어 있으며, 현재 로드맵에도 포함되어 있지 않습니다. 2024년에 진행할 수 있기를 희망합니다.
압축률에 0을 허용하여 gzip을 비활성화하는 패치를 작성한다면, 그 패치를 받아들이실 수 있을까요?
(그렇게 하면 CPU 시간을 절약할 수 있을 것 같지만, 공간은 절약되지 않을 것 같습니다. 압축된 tar 파일이 여전히 생성되니까요.)
CPU 시간을 절약하는 것이 목표입니다. 사실, 0을 플래그로 사용하여 코드 경로를 변경하고 gzip 압축을 하지 않으려 하고 있습니다. (아쉽게도 제 지식 범위 내에서 0은 모든 gzip 버전에서 지원되는 유효한 압축 레벨이 아닙니다.)
음, 그건 내게 전혀 도움이 안 되겠네요! (제한된 디스크 공간으로 인해 동일한 문제를 겪은 다른 사용자들도 마찬가지일 것입니다.)
tar를 사용했다면, z 또는 j 옵션과 함께 사용할 수 있었을 것입니다. 서브셸을 사용했다면, tar의 출력을 gzip으로 파이프할 수 있었을 것입니다. 하지만 실제로는 더 높은 수준의 ruby 함수가 사용되고 있는 것 같습니다.
기침
너무 어렵지 않을 것 같은데… 백업과 복원 기능에 대한 변경은 매우 신중하게 이루어져야 한다는 점에는 공감하지만, 압축을 인라인으로 처리하는 것만으로도 호환성 문제는 전혀 없이 공간 요구량을 크게 줄일 수 있다고 생각합니다.
tar --help
-a, --auto-compress 아카이브 접미사를 기반으로 압축을 결정합니다.
-z, --gzip, --gunzip, --ungzip 아카이브를 gzip로 필터링합니다.
-z 옵션이 실제로 인플레이스(in-place) 압축을 수행하나요? 저는 항상 tar 파일이 완성된 후에 gzip가 실행된다고 생각했습니다.
이 경우에는 그 판단이 잘못된 것이었습니다! 압축이 풀린 tar 파일을 나타내는 바이트들은 디스크에 저장되지 않았습니다.
"--gzip",
를 단순히 추가하면 실제로 사용된 데이터 공간의 두 배를 요구하지 않게 된다는 뜻인가요?
네, tar 명령에 대한 변경 사항입니다.
더 나은 선택지는 --zstd인 것 같지만, 그렇게 하려면 docker 이미지에도 ‘zstd’ 패키지를 설치해야 합니다.
기존 백업 파일이 *.gz 또는 *.zst 형식일 수 있다는 점을 고려할 때, 더 나은 접근 방식은 tar의 자동 감지 기능을 활용하는 것입니다.
tar --auto-compress -c -f ../file.tar.gz .
tar --auto-compress -c -f ../file.tar.zst .
물론 압축 해제 시에는 어떤 형식의 파일이 나타날지 알 수 없으므로 이 기능이 더욱 중요합니다.
현재 ruby 코드는 tar 자체가 처리할 수 있는 많은 작업을 수행하고 있습니다. 복잡해지기보다는 이 부분이 단순화되기를 바랍니다.
zstd는 압축 속도가 훨씬 빠릅니다. 이로 인해 압축이 거의 불가능한 데이터를 압축하는 데 시간을 쓰는 것이 덜 문제됩니다.
(zstd가 sql 덤프에도 사용된다면, 제 경우 10% 더 작아집니다.)
안녕하세요, 이 문제에 대해 새로운 소식이 있나요? 이 답변을 보면, 이 문제가 1년 넘게 한 줄로 수정 가능한 것으로 알려져 있는 것 같습니다. 서버에 거의 30G의 여유 공간이 있음에도 불구하고 계속 backup failed DM을 받는 것은 꽤 답답한 상황입니다.
CLA 서명 시 물리적 우편 주소를 입력해야 하지 않는다면, 제가 직접 PR을 만들었을 것입니다.