Zimbra 9를 Zimbra 10(Daffodil)으로 업그레이드하는 방법(단계별 안내)

Zimbra 9는 더 이상 운영 환경 메일 플랫폼으로 지원되지 않습니다. 2026년 10월 기준으로 Zimbra 9.0은 지원이 종료되었고, Zimbra 10.0 또한 지원 기간이 만료되었으며, 현재 Daffodil 브랜치는 Zimbra 10.1입니다. 따라서 현재 Zimbra 9 업그레이드 계획은 10.0에서 멈추지 않고 지원되는 Zimbra 10.1 릴리스를 목표로 해야 합니다. 이 글을 작성하는 시점 기준으로 Zimbra 10.1.21은 2026년 9월 24일에 출시되었습니다. 패치 요구 사항 및 알려진 문제가 변경될 수 있으므로 운영 환경 작업을 계획하기 전에 Zimbra 10.1.21 공식 릴리스 노트를 확인하십시오.

표준 설치 환경에서는 업그레이드 자체가 간단할 수 있지만, 적절한 방법은 운영 체제, 토폴로지, NG 모듈, 사용자 지정 인증, 라이선스 및 다운타임 허용 범위에 따라 달라집니다. 이 가이드는 명령어뿐만 아니라 이러한 선택 사항에도 중점을 두어 모든 배포를 동일한 절차로 진행하는 대신 환경에 맞는 방법을 선택할 수 있도록 도와줍니다.

생산에 착수하기 전에 업그레이드 전략을 선택하세요

접근하다	장점	절충	가장 적합한
현장 업그레이드	기존 서버 ID, 데이터 경로 및 대부분의 구성을 그대로 유지합니다. Zimbra 공식 문서에서는 단일 노드 및 다중 노드 배포에 대한 인플레이스 업그레이드를 지원합니다.	유지 관리 기간이 필요하며, 기존 운영 체제나 스토리지 레이아웃을 재설계할 여지가 줄어듭니다.	안정적이고 지원이 잘 되는 운영체제이며, 일반적인 Zimbra 9 구성입니다.
다중 서버 롤링 업그레이드	역할을 통제된 순서로 업그레이드하면 광범위한 서비스 중단을 줄일 수 있습니다.	더 많은 조정이 필요합니다. 혼합 버전 메일 저장소 동작 및 프록시 로그인 서버 구성에 특히 주의를 기울여야 합니다.	서비스 연속성이 중요한 대규모 멀티노드 환경.
Zimbra 10.1 신규 설치 및 마이그레이션	이 기능을 사용하면 기존의 모든 종속성을 그대로 유지하지 않고도 지원되는 최신 운영 체제, 새로운 스토리지 또는 재설계된 토폴로지로 마이그레이션할 수 있습니다.	마이그레이션 계획, 임시 용량 확보, DNS/전환 작업 및 추가 검증이 필요합니다.	오래된 운영 체제, 주요 하드웨어 교체, 상당한 사용자 지정 또는 제자리 업그레이드를 원하지 않는 배포 환경.

Zimbra의 최신 문서에는 NG 모듈이 포함된 환경을 포함하여 현재 위치 업그레이드 및 롤링 업그레이드 경로가 나와 있지만, NG 모듈 사용자는 전용 마이그레이션 자료를 참조하도록 안내하고 있습니다. 설치 프로그램에서 NG 모듈을 감지하면 해당 검사를 무시하지 마십시오. 설치 프로그램은 계속 진행할 경우 NG 패키지 및 관련 데이터가 삭제될 수 있다고 경고합니다. 먼저 공식 Daffodil 업그레이드 지침 과 해당 NG 마이그레이션 가이드를 검토하십시오.

1단계: 현재 Zimbra 버전 및 서비스 상태를 기록합니다.

먼저 기준선을 설정하십시오. zimbra사용자 계정으로 로그인하여 설치된 릴리스 버전과 현재 서비스 상태를 기록하십시오.

su - zimbra
zmcontrol -v
zmcontrol status

Zimbra 업그레이드 전에 zmcontrol 버전 및 서비스 상태를 확인하는 터미널 화면입니다. — 패키지를 변경하기 전에 현재 릴리스 및 서비스 상태를 기록하십시오. 표시된 터미널은 예시 명령 화면이며 실제 운영 서버 화면이 아닙니다.

이미 서비스에 문제가 발생하고 있다면 주요 업그레이드 전에 해당 문제를 해결하십시오. 업그레이드 중에 LDAP, 사서함, MTA 또는 프록시 문제가 유지 관리 기간 이전에 발생했다는 사실을 발견하는 것은 매우 부적절합니다. 또한 사용자 지정 Zimlet, 외부 인증, 통합, 인증서, 릴레이 규칙, 스크립트 및 모든 로컬 변경 사항을 목록화하십시오 /opt/zimbra.

2단계: 데이터베이스 무결성 검사를 실행하고 백업을 확인합니다.

zmdbintegrityreportZimbra는 특히 업그레이드 전 점검 사항으로 MariaDB의 기존 손상 문제를 주요 버전 변경 시 진단하기가 더 어려워질 수 있음을 강조합니다 . zimbra스토어 노드의 사용자 계정으로 실행하십시오.

su - zimbra
zmdbintegrityreport

Zimbra 10 업그레이드 전에 zmdbintegrityreport가 완료되는 터미널 화면을 보여주는 그림입니다. — 업그레이드를 복구 절차로 간주하지 말고, 업그레이드 전에 데이터베이스 무결성 보고서를 실행하고 오류를 조사하십시오.

Zimbra는 이 보고서가 데이터베이스 크기와 스토리지 성능에 따라 몇 분에서 한 시간까지 소요될 수 있다고 안내합니다. 대규모 메일 저장소의 경우, 보고서 생성 직전에 이 작업을 예약하지 마십시오.

다음으로, 사용 중인 에디션 및 환경에 적합한 백업 방법을 사용하여 복원 가능한 전체 백업을 생성하십시오. 백업은 위치를 알고 있고, 성공적으로 완료되었으며, 실행 가능한 복원 계획이 있는 경우에만 유용합니다. Zimbra는 데이터베이스 스키마 변경이 발생할 수 있으므로 주요 업그레이드 작업 전에 전체 백업을 수행하고 업그레이드 후에도 다시 전체 백업을 수행할 것을 권장합니다.

SAML 및 SPNEGO 사용자 지정 설정도 별도로 백업하십시오. Zimbra는 업그레이드 중에 이러한 사용자 지정 설정이 덮어쓰여질 수 있다고 경고합니다. 사용자 지정 파일 salocal.cf.in, 사용자 지정 SpamAssassin 규칙 또는 기타 로컬에서 관리되는 파일에 의존하는 경우, 교체될 수 있는 파일이 있는지 최신 릴리스 노트를 확인하고 업그레이드를 시작하기 전에 사본을 저장하십시오.

3단계: 다중 서버 배포의 경우 역할 순서를 따르십시오.

단일 서버 설치의 경우 사전 검사 후 설치 프로그램으로 바로 이동할 수 있습니다. 다중 서버 배포의 경우 설치 순서를 명확히 해야 합니다. Zimbra에서 제공하는 설치 순서는 LDAP 마스터 서버, LDAP 복제본, MTA 서버, 프록시 서버, 라이선스 데몬 서비스, OnlyOffice 서버, 그리고 마지막으로 메일 저장소 서버 순입니다.

터미널 스타일 체크리스트로, LDAP 마스터부터 메일 저장소까지 Zimbra 멀티 서버 업그레이드 순서를 보여줍니다. — 다중 서버 환경의 경우, 유지 관리 기간 동안 문서화된 역할 순서를 유지하여 종속 서비스가 순서대로 업그레이드되지 않는 일이 없도록 하십시오.

다른 역할로 진행하기 전에 LDAP 마스터를 업그레이드하고 실행해야 합니다. 롤링 업그레이드 중에 Zimbra는 Zimbra 10과 이전 버전의 메일 저장소가 공존하는 경우 zimbraReverseProxyUpstreamLoginServersZimbra 10 사서함 서버만 포함해야 한다고 경고합니다. 그렇지 않으면 Zimbra 10 메일 저장소 사용자가 최신 웹 앱 로그인 문제를 겪을 수 있습니다.

4단계: 운영 체제, 여유 공간 및 라이선스를 확인합니다.

Zimbra 9 서버의 운영 체제가 2026년에도 여전히 적합한 대상이라고 가정하지 마십시오. 최신 Zimbra 문서에 따르면 지원되는 플랫폼은 RHEL/Rocky/Oracle Linux 9 및 Ubuntu 22.04이며, Ubuntu 24.04 지원은 Zimbra 10.1.17 버전부터 일반에 공개되었습니다. Zimbra 10.1.21 릴리스 노트에는 다음 릴리스부터 Ubuntu 18.04 지원이 중단될 예정이라고 명시되어 있습니다. Zimbra 9 호스트가 구형 플랫폼에 있는 경우, 주요 Zimbra 변경과 운영 체제 전환을 동시에 진행하는 것보다 새로 설치하고 마이그레이션하는 방식이 더 나을 수 있습니다.

설치 프로그램을 실행하기 전에 여유 저장 공간이 충분한지 확인하십시오. Zimbra 설치 프로그램은 사용 가능한 공간을 확인하고 시스템에 공간이 부족하면 설치를 중단합니다.

Zimbra 설치 경로의 디스크 공간 확인을 보여주는 Linux 터미널 화면입니다. — Zimbra 데이터 및 소프트웨어가 저장된 파일 시스템의 사용 가능한 저장 공간을 확인하십시오. 표시된 수치는 예시일 뿐이며 크기 조정 지침이 아닙니다.

Zimbra 10.1은 라이선스 방식도 변경했습니다. 기존 라이선스 license.xml형식은 10.1에서 지원되지 않습니다. 설치 또는 업그레이드 전에 새로운 18~26자리의 영숫자 라이선스 키가 필요합니다. 유지보수 기간 전에 Zimbra에서 올바른 라이선스 키를 받으십시오. Zimbra 공식 다운로드 페이지에서는 시작하기 전에 새로운 v10.1 라이선스를 확보해야 한다는 경고를 명시적으로 안내하고 있습니다.

5단계: 올바른 Zimbra 10.1 빌드를 다운로드하세요.

Zimbra 공식 다운로드 영역에서 사용 중인 운영 체제 및 CPU 아키텍처에 맞는 패키지를 다운로드하십시오. 다른 배포판용으로 제작된 패키지를 재사용하지 마십시오. 다운로드한 압축 파일은 `/etc/mzm/`과 같은 작업 디렉터리에 보관하십시오 /var/tmp.

Zimbra에서 다운로드한 패키지의 체크섬을 제공하는 경우, 압축을 풀기 전에 체크섬을 확인하십시오. 로컬 체크섬 계산식은 다음과 같습니다.

sha256sum zcs.tgz

Zimbra 설치 아카이브에 대한 SHA-256 체크섬 계산 결과를 보여주는 터미널 화면입니다. — 패키지 체크섬을 로컬에서 계산하고 선택한 다운로드에 대해 게시된 값과 비교합니다.

그림에 표시된 체크섬은 릴리스 체크섬이 아닙니다. 실제 패키지에 제공된 체크섬만 사용하십시오.

6단계: 압축 파일을 해제하고 업그레이드 설치 프로그램을 시작합니다.

Zimbra의 문서화된 인플레이스 업그레이드 프로세스는 업그레이드 전에 서비스를 수동으로 중지할 필요가 없습니다. 설치 프로그램이 필요에 따라 서비스를 중지하고 시작합니다. root다운로드한 아카이브의 압축을 풀고, 압축 해제된 디렉터리로 이동하여 다음 명령을 실행하십시오 install.sh.

cd /var/tmp
tar xzvf zcs.tgz
cd <expanded-directory>
./install.sh

터미널 화면에 tar 압축 해제 후 Zimbra 설치 스크립트(install.sh)가 실행되는 모습이 표시됩니다. — Zimbra 압축 파일을 해제하고 해당 디렉토리로 이동한 다음, 루트 권한으로 install.sh를 실행하십시오. 디렉토리 이름은 다운로드한 빌드에 따라 다를 수 있습니다.

screenZimbra는 특히 원격 SSH 세션에서 업그레이드를 실행할 때 연결이 끊어져 장시간 업그레이드가 중단되는 것을 방지하기 위해 터미널 멀티플렉서(예: ) 내에서 업그레이드를 실행하는 것을 권장합니다 .

screen ./install.sh

화면 내부에서 실행되는 Zimbra install.sh 세션의 터미널 일러스트레이션 — 스크린 세션을 사용하면 SSH 연결 끊김으로 인해 업그레이드 프로세스가 중단될 위험을 줄일 수 있습니다.

7단계: 설치 프로그램의 안내에 신중하게 답변하십시오

설치 프로그램은 기존 Zimbra 설치를 감지하고 업그레이드 경로를 제시합니다. Zimbra의 최신 안내에 따르면, 메시지가 표시되면 Zimbra 패키지 저장소 사용을 수락한 후 업그레이드를 진행하라고 되어 있습니다. 단일 노드 10.1 업그레이드의 경우 해당 zimbra-license-daemon패키지가 필수이며, 거부할 경우 업그레이드가 진행되지 않습니다.

최종 질문에 답변하기 전에 패키지 목록을 검토하십시오. 백업, 라이선스, 패키지 소스, 스토리지 및 유지 관리 통신이 모두 설정되었는지 확인한 후에만 The system will be modified. Continue? [N]입력하십시오 Y. 설치 프로그램은 기존 서비스를 중지하고, 패키지를 교체하고, 구성을 복원하고, 업그레이드 작업을 수행한 후 서비스를 다시 시작합니다. 대규모 환경은 소규모 테스트 시스템보다 설치 시간이 훨씬 오래 걸릴 수 있습니다.

오프라인/수동 라이선스를 사용하는 경우 Zimbra의 최신 업그레이드 가이드에 나와 있는 특정 활성화 경로를 따르십시오. 온라인 라이선스 관련 지침을 오프라인 환경에 복사하지 마십시오. 마찬가지로 활성화 확인이 필요한 경우 사서함 노드 관련 지침이 다르므로 이전 릴리스에서 복사한 명령 대신 버전별 문서를 사용하십시오.

8단계: 서비스, 버전, 메일 흐름 및 클라이언트 액세스 권한 확인

설치가 완료되면 zimbra사용자 계정으로 돌아가 서비스 상태와 설치된 버전을 확인하십시오.

su - zimbra
zmcontrol status
zmcontrol -v

업그레이드 후 실행 중인 Zimbra 서비스를 보여주는 터미널 화면 이미지입니다. — 업그레이드 후 검증은 서비스 상태 확인으로 시작되지만, 서비스 목록이 정상(녹색)으로 표시되는 것은 첫 번째 확인 사항일 뿐입니다.

그런 다음 사용자가 실제로 의존하는 동작을 테스트합니다. 여기에는 수신 및 발신 SMTP, 내부 배달, 활성화된 경우 IMAP/POP, 최신 및 기존 웹 앱 로그인, 위임된 사서함, 캘린더 작업, 모바일 동기화, 라이선스가 있는 경우 Outlook 연결, 외부 인증, Zimlet, 백업, 모니터링, 그리고 Zimbra SOAP 또는 EWS 인터페이스를 사용하는 모든 애플리케이션이 포함됩니다.

릴리스별 업그레이드 후 조치를 건너뛰지 마십시오. Zimbra 10.1.19 이상 릴리스 노트에는 10.0.x, 9.0.x 또는 8.8.15에서 업그레이드하는 고객을 위한 업데이트된 SNMP 완화 조치가 명시되어 있습니다. 2026년 프로덕션 업그레이드를 계획하고 있다면 최신 패치 노트를 읽고 주요 업그레이드 후 필요한 완화 조치를 적용하십시오. Zimbra 10.1.21에는 클래식 웹 클라이언트, WebDAV 인증, 암호 복구, OpenJDK, NGINX 및 통합에 영향을 미치는 보안 수정 사항도 포함되어 있으므로, 구형 10.0 빌드에서 업그레이드를 중단하지 않는 것이 좋습니다.

제자리에 머무르는 대신 방향을 바꿔야 할 때는 언제일까요?

기존 시스템을 업그레이드하는 것은 구성 요소를 적게 변경하기 때문에 매력적이지만, 자동으로 위험도가 낮은 선택은 아닙니다. 다음과 같은 상황이 발생하면 계획을 재고해 보세요.

현재 운영 체제는 더 이상 사용되지 않거나 Zimbra 지원이 거의 종료되었습니다.
데이터베이스 무결성 검사에서 설명할 수 없는 오류가 보고되었습니다.
NG 모듈을 보유하고 있지만 지원되는 마이그레이션 절차를 검증하지 않았습니다.
SAML, SPNEGO, Zimlets, 바이러스 백신/스팸 방지 맞춤 설정 또는 타사 통합은 비즈니스에 매우 중요하며 10.1 버전에 대한 테스트를 거치지 않았습니다.
스토리지 아키텍처, 호스트 이름, 네트워크 설계 또는 하드웨어를 동시에 변경하고 있는 것입니다.
유지보수 기간 전에는 필요한 10.1 라이선스를 획득할 수 없습니다.

이러한 경우, 제어된 마이그레이션을 통해 병렬 Zimbra 10.1 환경을 구축하는 데 더 많은 준비가 필요할 수 있지만, 더 깔끔한 롤백 경계를 제공하고 기본 플랫폼을 현대화할 수 있는 더 나은 기회를 제공합니다.

실용적인 업그레이드 체크리스트

Zimbra 9의 정확한 버전과 현재 서비스 상태를 확인하십시오.
최신 10.1 릴리스 노트와 공식 업그레이드 가이드를 검토하십시오.
zmdbintegrityreport스토어 노드에서 실행 하고 오류를 해결합니다.
전체 백업을 생성하고 검증하며, 사용자 지정 인증 및 필터링 구성을 저장합니다.
대상 운영 체제가 대상 10.1 릴리스를 지원하는지 확인하십시오.
새로운 10.1 라이선스 키를 받으세요. 이전 라이선스 키에 의존하지 마세요 license.xml.
디스크 용량을 확인하고 올바른 플랫폼 패키지를 다운로드하십시오.
다중 서버 배포의 경우, 문서에 명시된 역할 순서를 따르십시오.
설치 프로그램을 실행하거나 screen이와 동등한 영구 터미널 세션을 실행하십시오.
서비스, 버전, 메일 흐름, 웹 클라이언트, 인증, 통합 및 모니터링을 검증합니다.
버전별 업그레이드 후 완화 조치를 적용하고 새 전체 백업을 생성합니다.

결론

지원되는 운영 체제에서 일반적인 구성으로 정상적으로 작동하는 Zimbra 9 서버의 경우, 현재 Zimbra 10.1 Daffodil 브랜치로의 인플레이스 업그레이드가 일반적으로 가장 간단한 방법입니다. 하지만 운영 체제가 오래되었거나, 복잡한 차세대 모듈이 배포되었거나, 주요 인프라 변경이 필요한 서버의 경우, 더 많은 작업이 필요하더라도 새로 설치하고 마이그레이션하는 것이 더 깔끔한 운영 환경을 제공할 수 있습니다.

핵심 품질 검사는 단순히 install.sh업그레이드가 완료되었는지 여부만이 아닙니다. 성공적인 업그레이드란 서버가 지원되는 10.1 패치를 사용하고, 필요한 모든 서비스가 정상적으로 작동하며, 메일 흐름과 사용자 액세스가 예상대로 이루어지고, 사용자 지정 통합이 재테스트되었고, 라이선스가 활성화되었으며, 버전별 완화 조치가 완료되었고, 업그레이드 후 최신 백업이 확보된 상태를 의미합니다. 업그레이드 계획을 세울 때는 공식 Zimbra Daffodil 업그레이드 가이드 , 최신 10.1.21 릴리스 노트 , 그리고 공식 멀티 서버 문서를 항상 참고하십시오 . 이러한 자료들은 이전 명령어 스니펫보다 우선적으로 고려되어야 합니다.