synology / self-hosting / security / performance

운영 요령

시놀로지 DSM 7.1.1에서 7.3으로 올릴 때 겪은 것: MariaDB, PHP, 패키지 오류

DSM 7.3 업그레이드에서 MariaDB 10.3→10.11 mysql_upgrade 90분, PHP 7.4·8.0 제거, Docker 24 전환, 패키지 status 259·272 대응까지 실제로 손본 것을 정리했습니다.

시놀로지 DS918+를 DSM 7.1.1에서 7.3으로 올렸습니다. 업데이트 버튼 한 번이면 끝날 줄 알았는데, 그 위에서 돌던 패키지들이 같이 크게 바뀌면서 손볼 게 꽤 나왔습니다. 웹사이트와 DB를 NAS에서 돌리고 있다면 미리 알아 두면 좋을 것들을 정리합니다.

같이 바뀐 것

DSM 7.1.1 → 7.3 업그레이드 때 함께 바뀐 구성 (2026-02-12)
항목전후
DSM7.1.17.3
Docker (Container Manager)20.1024.0.2
MariaDB10.3.3210.11.11
phpMyAdmin5.2.1-10785.2.2-1102
PHP7.4, 8.0, 8.2 공존7.4·8.0 제거 → 8.2, 이후 8.4 패키지로 전환

업그레이드와 함께 더 이상 쓰지 않던 패키지와 컨테이너(Mattermost, LibreChat, Portainer, 별도 PHP 8.3 FPM)는 정리했습니다.

MariaDB: mysql_upgrade에 90분

제일 오래 걸린 건 MariaDB였습니다. 10.3에서 10.11로 올라가면 시스템 테이블 구조가 바뀌어서, 데이터 파일을 새 버전에 맞추는 mysql_upgrade를 돌려야 합니다. 저는 두 번 돌렸고, 합쳐서 약 90분이 걸렸습니다. 이 동안 DB를 쓰는 사이트는 사실상 멈춥니다.

DB 크기와 디스크 속도에 따라 다르겠지만, 워드프레스 여러 개가 들어 있는 DB라면 업그레이드는 사람이 적은 시간에 하는 게 좋습니다. 업그레이드 뒤 MariaDB 패키지가 스스로 안 올라오는 경우를 대비해, 수동으로 띄우는 명령도 적어 뒀습니다.

/var/packages/MariaDB10/target/usr/local/mariadb10.11/bin/mysqld_safe \
  --datadir=/var/packages/MariaDB10/target/mysql \
  --socket=/run/mysqld/mysqld10.sock &

경로에 버전(mariadb10.11)이 들어가 있어서, 옛 문서에 적힌 10.3 경로를 그대로 쓰면 안 됩니다.

PHP: 7.4와 8.0이 사라집니다

DSM 7.3에서는 PHP 7.4와 8.0이 없어집니다. 이 버전으로 돌던 사이트는 Web Station에서 PHP 8.2 프로파일로 옮겼고, 같은 날 PHP 8.4 패키지를 설치해 전체 PHP 사이트를 8.4 프로파일로 다시 옮겼습니다.

옮긴 뒤에는 원래 PHP 7.4, 8.0용이던 프로파일 두 개가 PHP 8.2 프로파일로 바뀌어 남았습니다. 나중에 헷갈리지 않게 어느 프로파일이 원래 무엇이었는지 따로 적어 뒀습니다.

그리고 나중에 알았는데, 8.4로 옮긴 프로파일에서는 opcache가 꺼져 있었습니다. 8.2 쪽은 켜져 있었으니 새 프로파일을 만들면 캐시 설정부터 확인하는 게 좋습니다. 이 얘기는 opcache 글에 따로 적었습니다.

패키지가 안 켜질 때: status 259와 272

업그레이드 뒤 패키지가 시작되지 않을 때를 대비해 대응법을 두 가지 적어 뒀습니다. 패키지 센터에 뜨는 상태 코드로 원인이 갈립니다.

업그레이드 후 패키지 상태 코드별 대응
코드뜻대응
259 (version_limit)설치된 패키지 버전이 새 DSM에서 허용되지 않음시놀로지 아카이브에서 최신 SPK를 받아 수동 설치
272 (start_failed)시작 실패 표시가 남아 다시 시작을 안 함실패 표시 파일을 지우고 수동 시작

259는 설치된 버전이 새 DSM에서 막힐 때 납니다. 시놀로지 공식 아카이브에서 해당 모델용 최신 SPK를 받아 root로 설치합니다.

/usr/syno/bin/synopkg install /tmp/<패키지>.spk

272는 한 번 시작에 실패한 기록 파일 때문에 이후에도 계속 멈춰 있는 경우입니다. 기록을 지우고 켜짐 상태로 표시한 뒤 서비스를 직접 시작하면 올라옵니다.

rm -f /var/packages/<패키지명>/startFailed /var/packages/<패키지명>/starting
touch /var/packages/<패키지명>/enabled
systemctl start pkgctl-<패키지명>

둘 다 root 권한이 필요합니다.

Docker: 컨테이너 설정을 적어 두세요

Docker 엔진이 20.10에서 24.0.2로 올라갔습니다. 컨테이너를 다시 만들 일이 생기면, 환경 변수와 볼륨 마운트를 빠뜨리는 순간 데이터가 날아갑니다. 예를 들어 워크플로 도구는 설정 폴더 볼륨이 빠지면 워크플로가 전부 사라지고, 모니터링 도구도 데이터 볼륨이 빠지면 모니터 설정이 없어집니다.

그래서 컨테이너마다 docker run 전체 명령을 한 줄로 문서에 적어 두고, 업데이트할 때는 그 명령을 그대로 씁니다. 업그레이드 전에 해 둘 일을 하나만 고르라면 이겁니다.

다시 한다면

  1. DB 덤프, 웹 루트, 컨테이너 실행 명령을 먼저 백업합니다.
  2. PHP 7.4·8.0을 쓰는 사이트를 미리 8.2 이상으로 옮겨 두고 확인합니다.
  3. 업그레이드는 MariaDB mysql_upgrade 시간을 감안해 한가한 시간에 합니다.
  4. 끝나면 패키지 상태를 보고, 259는 아카이브 SPK로, 272는 실패 표시를 지워서 해결합니다.
  5. 새 PHP 프로파일의 캐시 설정을 확인합니다.

확인한 공식 자료

구현 과정에서 판단 기준을 교차 확인한 공식 문서입니다. 글의 사례와 결론은 운영자가 직접 겪은 작업을 바탕으로 작성했습니다.