# 백업용 압축 방식: gz에서 zstd로 마이그레이션

**URL:** https://meta.discourse.org/t/migrate-from-gz-compression-to-zstd-for-backups/309984
**Category:** Feature
**Tags:** pr-welcome
**Created:** [5월 30, 2024, 3:10오후 UTC](https://meta.discourse.org/t/migrate-from-gz-compression-to-zstd-for-backups/309984 "2024-05-30T15:10:53Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![mentalstring](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mentalstring/32/168934_2.png) [@mentalstring](https://meta.discourse.org/u/mentalstring)
#### Post date: [4월 23, 2026, 12:20오후 UTC](https://meta.discourse.org/t/migrate-from-gz-compression-to-zstd-for-backups/309984/4 "2026-04-23T12:20:41Z")

</div>

가끔 백업 과정이 추가 부하로 인해 가용성 문제를 일으키기도 합니다. 그래서 오늘 zstd로 간단한 실험을 해 보았습니다.

Discourse 백업에서 사용된 gzip (레벨 4)과 zstd (기본 레벨 3, 최대 19)으로 동일한 73GiB 크기의 dump.sql 파일을 압축했을 때의 결과는 다음과 같습니다:

압축 크기: **15.8% 더 작음** (.zst 파일이 .gz 파일 크기의 84%)  
압축 시간 (-T1): **71% 빠름** (gzip 소요 시간의 29%)  
압축 시간 (-T0): **89% 빠름** (gzip 소요 시간의 11%)

결과가 다를 수 있습니다(YMMV). 여러 번 실행하지 않았고, 제 개인용 머신(6코어)에서 실행했으며, 다른 작업도 동시에 수행 중이었고, 그 외 여러 요인이 있었기 때문에 정밀한 측정을 목표로 하지는 않았습니다. 그럼에도 불구하고 이점이 명확하다고 생각합니다.

-T0 옵션이 모든 사용자에게 반드시 좋은 선택일지는 확실하지 않습니다. Discourse 자체를 위한 여유 공간을 확보하는 것이 좋은 아이디어라고 생각하기 때문에, 더 공정한 비교를 위해 -T1 옵션을 사용한 샘플을 제시했습니다.

상호 이익(win-win)이 될 것 같고, Discourse의 호스팅 인프라에도 상당한 영향을 미칠 것으로 보입니다. 다만, PR을 작성할 실력은 없으므로, 발견한 내용만 공유합니다.

---

_[View the full topic](https://meta.discourse.org/t/migrate-from-gz-compression-to-zstd-for-backups/309984)._