백업 압축을 비활성화하는 방법이 있을까요?

지원
1

백업의 gzip 압축을 비활성화할 방법이 있을까요?

Digital Ocean 서버 용량을 결국 늘려야 한다는 것은 알고 있지만, 그렇게 하면 월 비용이 사실상 두 배가 되므로 가능한 한 늦추고 있습니다.

최근 업데이트(새로운 postgres로 전환된 때) 이후에는 백업 생성 자체는 되지만, 백업의 gzip 압축 과정에서 실패하는 것 같습니다. 아이러니한 일이죠.

백업이 생성된 후에는 서버에서 복사해서 다른 곳에 저장하고 있기 때문에, gzip이 실질적인 가치를 제공하지 않습니다(전송 시간이 약간 길어질 뿐). 장기 보관을 위해 서버에서 백업을 꺼낸 후에 gzip으로 압축할 수도 있습니다. 또한 백업 크기의 상당 부분은 업로드된 파일이고, 이미지 등은 이미 압축된 상태입니다.

하지만 현재는 gzip 과정 때문에 백업 전체가 실패하고 있습니다.

그래서 — 백업을 gzip으로 압축하지 말라고 설정할 방법이 있을까요?

2

기존 데이터베이스를 삭제하기 위해 다음 명령어를 실행해 보셨나요?

./launcher cleanup

추가로, 블록 스토리지를 사용하여 공간을 늘리는 것도 방법입니다.

3

이전 요청/관찰 항목을 참조하세요:

백업 중복 압축(gzip)을 피하여 로컬 디스크 공간 요구량을 줄입니다

4

잠깐, tar에 --gzip 플래그만 추가하면 문제가 완전히 해결되는 건가요?

5

아직 안 해봤는데, 실제로 상당한 용량을 확보할 수 있었고, 당면한 문제를 해결할 수 있었습니다.

--gzip 옵션을 사용하는 것이 여전히 매우 좋은 아이디어인 것 같습니다.

하지만 적어도 월 요금을 두 배로 올리는 것을 6개월 이상 더 미룰 수 있게 되었으니, 감사합니다.

6

블록 스토리지는 꽤 저렴한 것 같습니다. 백업 용도로만 사용하거나 업로드에도 활용할 수 있습니다. 다만, 백업을 생성하는 데 사용되는 임시 공간으로 블록 스토리지가 사용된다는 점을 파악하는 것이 다소 어려울 수 있습니다.

7

블록 스토리지를 백업 용도로만 사용할 수 있을까요? 가능하면 서버 용량을 2배로 늘려야 하는 시점을 늦출 수 있는 옵션이 될 수 있겠습니다. 다만, 먼저 로컬에서 생성한 뒤 S3로 복사하는 방식이라면 전혀 도움이 되지 않을 것입니다.

8

네, 가능합니다. 업로드에 대해 설명드린 것과 동일한 개념입니다. 임시 파일이 어디에 기록되는지 기억이 나지 않습니다. 백업 로그에 있을 것 같습니다. app.yml에서 해당 디렉토리가 추가 저장 공간에 매핑되어 있는지 확인하시면 됩니다.

9

아래와 같은 내용을 작성해야 할 것 같습니다.

volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/dashboard/log/var-log
      guest: /var/log
  - volume:
      host: /bigExtraSpace/tmp
      guest: /shared/tmp
  - volume:
      host: /bigExtraSpace/backups
      guest: /shared/backups