이미지를 수동으로 복구했습니다 - 이전 호스팅에서 복사해 온 거예요. 지금은 모든 기능이 정상적으로 작동하지만, 백업에 문제가 생겼습니다. 동일한 설정인데도 용량이 4배 더 많이 차지하네요.
불필요한 파일을 모두 정리할 수 있는 방법이 있을까요?
사용자 기기의 해상도에 따라 이미지의 여러 사본이 필요하기 때문에 레티나 이미지 크기 지정 때문일 가능성이 높습니다.
원본 에셋만 백업하는 옵션을 추가할 수 있을까요? 복구 시 재처리 작업이 많이 필요하다는 점은 이해합니다. 하지만 운영 관점에서 보면 로컬 디스크 공간 확보와 시스템 간 데이터 전송에 큰 도움이 될 것 같습니다.
네, 그런데 왜 마이그레이션 후에 동일한 사본이 4배나 더 많이 차지하는 건가요?
결국 파일과 콘텐츠가 정확히 동일합니다. 그 원인이 어디서 비롯되는지 이해가 되지 않습니다.
대부분 캐싱 관련 문제입니다. 그렇지 않으면 더 작은 크기로 이미지를 실시간으로 다시 렌더링해야 하는데, 이는 계산적으로 매우 부담이 큽니다.
@stephen과 저는 @sam이 과거에 이 부분을 언급한 적이 있다는 것을 알고 있습니다. 백업에서는 이 단계를 건너뛸 수 있을 것입니다. 유일한 단점은 백업 복원 시 모든 해상도를 다시 렌더링해야 하므로 CPU 부하가 매우 커진다는 점입니다. 하지만 제 생각에는 심각한 단점은 아닙니다. 급하게 복원이 필요하거나, CPU 성능이 부족한 서버를 사용하는 경우가 아니라면요.
모두를 대표해서 말할 수는 없지만, 저는 백업을 위해 4배 더 많은 디스크 공간을 할당하는 것보다, 자산을 재생성하는 과정에서 단기적인 CPU 부하를 감수하는 쪽을 선호합니다.
그걸 어떻게 하시나요??
백업은 기본적으로 그렇게 동작합니다. 기본적으로 섬네일(미리보기 이미지)은 백업에 포함되지 않습니다. 우리는 최소 1년 전부터 그렇게 변경했습니다.
include_thumbnails_in_backups 사이트 설정으로 해당 동작을 구성할 수 있습니다.
백업에 생성된 섬네일을 포함합니다. 이 기능을 비활성화하면 백업 크기가 줄어듭니다. 하지만 복원 후 모든 게시물에 대해 다시 베이킹(rebake)이 필요합니다.
@eextra 백업이 왜 이렇게 큰지 파악하기 위해, 구버전과 신버전 백업의 콘텐츠에 대해 파일 기반 차이를 비교해 보시는 것을 권장합니다.
실수했습니다. 설명해 주셔서 감사합니다 @gerhard 
.. 이것이 더 나은 기본값이라고 생각합니다.