백업 압축 수준에 대한 일반적인 사례

백업 압축 수준에 대한 일반적인 사례

이 질문은 약간 "의견 기반"일 수 있지만 압축 수준 사용에 대한 권위 있는 정보 소스를 찾는 것으로 이것을 고려하십시오.

다양한 크기(메가바이트에서 40GB까지)의 여러 데이터베이스가 있는 서버가 있습니다. 현재 gzip -9압축 수준을 사용하고 있으며 백업이 매우 느립니다.

우리는 일일 백업 정책을 갖고 있으며 다음을 유지합니다.

  • 14일 동안 매일 백업
  • 2개월 동안 매주 백업
  • 2년간 월간 백업
  • 연간 영구 백업

데이터베이스 백업은 다음과 같이 수행됩니다.mysqldump ... > | gzip -9 -c > $TIMESTAMP.sql.gz

소규모 데이터베이스에 대해 다양한 압축 수준을 시도했습니다. 결과는 다음과 같습니다. (서버의 부하가 약간 과중하여 약간 부정확할 수 있습니다.)

level | time (real) | output file size
    1 |    0m1.844s | 6.6M
    3 |    0m1.902s | 6.1M
    5 |    0m2.112s | 5.1M
    7 |    0m2.447s | 4.9M
    9 |    0m3.498s | 4.8M

그 후에는 5 또는 7 압축 수준을 사용해야 하며 9 압축 수준은 피해야 한다고 생각합니다.

문제는 다음과 같습니다

백업 압축 수준과 관련된 일반적인 관행은 무엇입니까?

회사나 기관에서는 어떤 표준을 사용합니까?

답변1

백업 압축 수준과 관련된 일반적인 관행은 무엇입니까?

아니요, 모든 것은 엄격히 귀하의 필요와 능력에 달려 있습니다.

회사나 기관에서는 어떤 표준을 사용합니까?

아니요, 자신에게 맞는 것을 사용하세요.

gzip 대신 ZSTD를 사용하는 것이 좋습니다. 충분히 성숙했고, 압축률이 gzip보다 훨씬 좋고, 압축 해제 속도도 놀라울 정도로 빠릅니다. --long1과 2를 포함하여 22개의 압축 수준이 있으므로 --ultra어떤 것이 가장 적합한지 찾기 위해 실험을 해야 합니다.

압축된 데이터에 PAR2를 사용하고 원본 데이터와 압축된 데이터의 체크섬을 유지하는 것을 고려하세요. 체크섬이 없으면 데이터를 저장하거나 검색할 때 비트 오류로 인해 데이터가 손실되기 쉽습니다.

관련 정보