Haru Utils

ARTIFACT REPOSITORY

Nexus Repository 설치와 저장공간 관리

지원 중인 Nexus Repository 배포본을 전용 계정과 systemd로 설치하고 애플리케이션·데이터·Blob Store를 분리해 최소 여유공간, Soft Quota, 백업과 안전한 롤백까지 구성합니다.
Nexus Repository 설치Nexus blob storeNexus 저장공간Nexus systemdNexus soft quota
지원 환경Sonatype가 지원하는 최신 Nexus Repository 릴리스 · Linux x86-64
예상 시간75
난이도고급
검토일2026-08-28

BEFORE YOU START

시작 전에 준비하세요

01

Sonatype 공식 Version Status에서 확인한 지원 릴리스와 공식 아카이브·체크섬

02

애플리케이션용 /opt, 데이터용 /var/lib/nexus, Blob Store용 /srv/nexus-blobs 용량 계획

03

동일 호스트 TLS 역방향 프록시와 8081을 루프백으로만 제한할 네트워크 정책

04

H2 또는 외부 PostgreSQL 중 실제 DB 방식을 식별하고 DB·Blob Store·설정·Node ID를 하나의 복구 시점으로 묶는 백업·복원 절차

권장 대상 Maven·npm·Docker 등의 사설 아티팩트를 운영하면서 데이터 디렉터리 고갈과 Blob Store 직접 조작을 피하고 백업 가능한 구조를 만들려는 운영자

FOLLOW THE RECIPE

8단계 구성·점검 레시피

1
확인시스템을 변경하지 않는 점검 단계

지원 릴리스와 저장 구조 확정

Nexus의 설치 디렉터리, 데이터 디렉터리, Blob Store는 수명과 I/O 특성이 다릅니다. 업그레이드 가능한 버전별 애플리케이션 경로와 영속 데이터·Blob 볼륨을 분리합니다.

OS·아키텍처
cat /etc/os-release
uname -m
CPU·메모리
nproc
free -h
파일시스템과 마운트
df -hT /opt /var /srv
findmnt -T /var/lib/nexus
findmnt -T /srv/nexus-blobs
아직 경로가 없으면 부모 경로의 파일시스템을 확인합니다.
시간 동기화
timedatectl status
  • 현재 지원 릴리스와 업그레이드 경로를 Sonatype Version Status에서 확인했습니다.
  • 애플리케이션, 데이터베이스·설정, Blob Store의 볼륨과 백업 주기를 분리했습니다.
  • 최소 4GB보다 충분히 큰 비상 여유공간과 성장률 경보를 계획했습니다.
결과 읽기

Nexus는 가용 공간이 4GB 아래로 내려가면 데이터베이스가 읽기 전용으로 전환될 수 있습니다. 설치 가능 용량이 아니라 성장률·정리 지연·복구 공간까지 포함해 계획합니다.

다음 판단

기존 서비스·포트·데이터 디렉터리를 변경 전 기준으로 기록합니다.

2
확인시스템을 변경하지 않는 점검 단계

기존 인스턴스와 디스크 기준값 점검

기존 Nexus가 있으면 신규 설치 절차로 덮어쓰지 않습니다. 서비스, 8081 포트, 설치·데이터·Blob 경로의 소유권과 사용량을 먼저 기록합니다.

기존 서비스
systemctl status nexus.service --no-pager
없다는 메시지는 신규 설치입니다.
기존 포트
sudo ss -lntup | grep -E ':8081[[:space:]]'
기존 경로 메타데이터
sudo stat -c '%U %G %a %n' /opt/sonatype/nexus /var/lib/nexus /srv/nexus-blobs
파일 내용을 출력하지 않습니다.
현재 사용량과 inode
sudo du -sh /var/lib/nexus /srv/nexus-blobs 2>/dev/null
df -hT /var/lib /srv
df -i /var/lib /srv
데이터베이스 방식 식별
if sudo test -f /var/lib/nexus/etc/fabric/nexus-store.properties; then echo 'external PostgreSQL configuration present'; elif sudo test -f /var/lib/nexus/db/nexus.mv.db; then echo 'embedded H2 database present'; else echo 'database mode not yet initialized or unknown' >&2; fi
sudo stat -c '%U %G %a %n' /var/lib/nexus/keystores/node 2>/dev/null
nexus-store.properties는 자격증명을 포함할 수 있으므로 내용을 출력하지 않습니다. DB 방식을 확정하지 못하면 백업·복원 명령으로 진행하지 않습니다.
실패 서비스
systemctl --failed --no-pager
  • 기존 Nexus의 버전·데이터 경로·Blob Store 매핑을 UI와 대조했습니다.
  • H2와 외부 PostgreSQL 중 실제 DB 방식을 하나만 확정하고 Node ID 경로를 기록했습니다.
  • 기존 인스턴스가 있으면 이 가이드를 중단하고 공식 업그레이드 절차로 전환했습니다.
  • 데이터와 Blob Store를 함께 복원한 최근 테스트 결과가 있습니다.
결과 읽기

Blob Store 파일은 Nexus가 이름과 메타데이터를 관리하므로 OS에서 직접 이동·수정·삭제하면 안 됩니다. 공간 부족도 UI의 작업과 공식 복구 절차로 처리합니다.

다음 판단

공식 아카이브를 검증하고 전용 계정·빈 경로에만 배치합니다.

3
변경패키지·설정·서비스 상태가 달라지는 단계

공식 아카이브 검증과 전용 경로 배치

공식 다운로드에서 아카이브와 게시 체크섬을 별도로 받아 비교합니다. 신규 설치 경로가 비어 있음을 확인한 뒤 전용 nexus 계정과 영속 경로를 만듭니다.

변경 단계입니다. 대상 서버, 백업 파일, 서비스 중단 영향과 바로 이전 상태로 돌아가는 방법을 다시 확인하세요.
복구 ZIP 검사 도구 확인
command -v unzip && unzip -v | head -n 2
뒤의 H2 백업·복원 검증에 필요합니다. 없으면 배포판의 unzip 패키지를 먼저 설치하고 이 확인이 성공하기 전에는 진행하지 않습니다.
다운로드 파일
ls -lh <NEXUS_ARCHIVE>.tar.gz <NEXUS_ARCHIVE>.tar.gz.sha256
체크섬 검증
sha256sum <NEXUS_ARCHIVE>.tar.gz
출력 전체를 공식 다운로드 페이지의 같은 릴리스 SHA256 값과 문자 단위로 대조합니다. MD5·SHA1만으로 승인하지 않습니다.
아카이브 목록 점검
tar -tzf <NEXUS_ARCHIVE>.tar.gz | head -n 40
전용 계정
sudo useradd --system --home-dir /var/lib/nexus --create-home --shell /usr/sbin/nologin nexus
계정이 이미 있으면 UID·홈·셸을 확인하고 다시 만들지 않습니다.
영속 경로
sudo install -d -m 0750 -o nexus -g nexus /var/lib/nexus /srv/nexus-blobs
sudo install -d -m 0755 -o root -g root /opt/sonatype/nexus
신규 설치 경로 비어 있음
sudo test -z "$(sudo find /opt/sonatype/nexus -mindepth 1 -maxdepth 1 -print -quit)"
실패하면 압축을 풀지 말고 기존 설치·잔여 파일을 조사합니다.
격리 staging에 압축 해제
sudo install -d -m 0750 -o root -g root /opt/sonatype/staging-<BACKUP_SUFFIX>
sudo tar --no-overwrite-dir -xzf <NEXUS_ARCHIVE>.tar.gz -C /opt/sonatype/staging-<BACKUP_SUFFIX>
아카이브에는 설치 디렉터리와 초기 데이터 디렉터리가 함께 있을 수 있으므로 바로 운영 경로에 풀지 않습니다.
설치 디렉터리 구조 확인
sudo test -x /opt/sonatype/staging-<BACKUP_SUFFIX>/nexus-<NEXUS_VERSION>/bin/nexus
sudo find /opt/sonatype/staging-<BACKUP_SUFFIX> -mindepth 1 -maxdepth 2 -type d -print
공식 아카이브의 nexus-<NEXUS_VERSION> 디렉터리를 확인하고 동봉된 sonatype-work를 운영 데이터로 자동 채택하지 않습니다.
검증한 설치 파일 복사
sudo cp --archive --no-clobber /opt/sonatype/staging-<BACKUP_SUFFIX>/nexus-<NEXUS_VERSION>/. /opt/sonatype/nexus/
비어 있음을 확인한 신규 설치 경로에만 복사하고 staging은 검증이 끝날 때까지 보존합니다.
소유권 설정
sudo chown -R nexus:nexus /opt/sonatype/nexus
sudo chmod 0750 /opt/sonatype/nexus
  • 지원 중인 릴리스와 체크섬이 일치합니다.
  • 기존 설치 경로를 덮어쓰지 않았습니다.
  • nexus 계정은 로그인할 수 없고 영속 경로만 쓸 수 있습니다.
  • SMB·CIFS를 embedded data 경로로 사용하지 않았습니다.
결과 읽기

체크섬 오류나 예상 밖 최상위 경로가 나오면 압축을 풀지 않습니다. 미러·프록시 캐시보다 공식 다운로드와 시스템 시간을 먼저 확인합니다.

다음 판단

데이터 경로와 systemd 유닛을 백업 후 구성합니다.

4
주의권한·연결·중단 영향을 확인할 단계

외부 데이터 경로와 systemd 구성

버전 교체 때 영속 데이터가 설치 디렉터리에 묻히지 않도록 karaf.data를 /var/lib/nexus로 지정합니다. nexus.properties에서 HTTP를 127.0.0.1에 명시적으로 바인딩하고 기존 vmoptions·속성·유닛을 별도 접미사로 백업합니다.

기존 vmoptions 백업
sudo cp --archive --no-clobber /opt/sonatype/nexus/bin/nexus.vmoptions /opt/sonatype/nexus/bin/nexus.vmoptions.<BACKUP_SUFFIX>.bak
vmoptions 편집
sudoedit /opt/sonatype/nexus/bin/nexus.vmoptions
애플리케이션 설정 디렉터리
sudo install -d -m 0750 -o nexus -g nexus /var/lib/nexus/etc
기존 nexus.properties 백업
sudo cp --archive --no-clobber /var/lib/nexus/etc/nexus.properties /var/lib/nexus/etc/nexus.properties.<BACKUP_SUFFIX>.bak
기존 파일이 있을 때만 실행합니다.
nexus.properties 편집
sudoedit /var/lib/nexus/etc/nexus.properties
sudo chown nexus:nexus /var/lib/nexus/etc/nexus.properties
sudo chmod 0640 /var/lib/nexus/etc/nexus.properties
application-host와 application-port는 각각 한 번만 두고 기존 사용자 정의 속성은 유지합니다.
기존 유닛 백업
sudo cp --archive --no-clobber /etc/systemd/system/nexus.service /etc/systemd/system/nexus.service.<BACKUP_SUFFIX>.bak
기존 파일이 있을 때만 실행합니다.
systemd 유닛 편집
sudoedit /etc/systemd/system/nexus.service
경로 권한 재확인
sudo chown -R nexus:nexus /var/lib/nexus /srv/nexus-blobs
sudo chmod 0750 /var/lib/nexus /srv/nexus-blobs
설정 예시 · /opt/sonatype/nexus/bin/nexus.vmoptions
설치 경로 밖의 영속 데이터 디렉터리
-Dkaraf.data=/var/lib/nexus
-Dkaraf.log=/var/lib/nexus/log
-Djava.io.tmpdir=/var/lib/nexus/tmp
기존 공식 JVM 옵션은 유지하고 같은 키가 중복되지 않도록 수정합니다.
설정 예시 · /var/lib/nexus/etc/nexus.properties
TLS 프록시 뒤 루프백 HTTP 바인딩
application-host=127.0.0.1
application-port=8081
외부 클라이언트는 CA 서명 TLS 프록시로만 접근합니다. 다른 사용자 정의 속성이 있다면 보존하고 같은 키를 중복 작성하지 않습니다.
설정 예시 · /etc/systemd/system/nexus.service
전용 계정으로 실행하는 Nexus 유닛
[Unit]
Description=Sonatype Nexus Repository
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
User=nexus
Group=nexus
LimitNOFILE=65536
ExecStart=/opt/sonatype/nexus/bin/nexus start
ExecStop=/opt/sonatype/nexus/bin/nexus stop
Restart=on-abort
TimeoutSec=600
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target
  • karaf.data가 /var/lib/nexus를 가리킵니다.
  • nexus.properties에 application-host=127.0.0.1이 중복 없이 명시됐습니다.
  • Blob Store 경로는 /var/lib/nexus 밖의 /srv/nexus-blobs입니다.
  • 유닛이 전용 nexus 계정으로 실행되고 root로 실행되지 않습니다.
  • 기존 설정과 유닛 백업의 접미사·시점을 기록했습니다.
결과 읽기

Blob Store 경로만 옮겨도 기존 저장소 매핑이 자동 변경되지는 않습니다. 신규 Blob Store는 UI에서 만들고 저장소에 연결하며 기존 Blob 마이그레이션은 공식 절차로 별도 수행합니다.

다음 판단

유닛과 실행 파일을 검증한 뒤 서비스를 시작합니다.

5
주의권한·연결·중단 영향을 확인할 단계

구성 검증 후 서비스 시작

유닛 문법과 경로 쓰기 권한을 먼저 확인합니다. 첫 기동은 데이터베이스 초기화 시간이 필요하므로 TimeoutSec 내에서 로그를 관찰하고 반복 재시작하지 않습니다.

유닛 검증
sudo systemd-analyze verify /etc/systemd/system/nexus.service
루프백 설정 검증
sudo -u nexus grep -Fxc 'application-host=127.0.0.1' /var/lib/nexus/etc/nexus.properties
sudo -u nexus grep -Fxc 'application-port=8081' /var/lib/nexus/etc/nexus.properties
각 명령이 1을 출력하지 않으면 중복 또는 누락을 수정한 뒤에만 시작합니다.
서비스 계정 경로 확인
sudo -u nexus test -x /opt/sonatype/nexus/bin/nexus
sudo -u nexus test -w /var/lib/nexus
sudo -u nexus test -w /srv/nexus-blobs
유닛 반영과 시작
sudo systemctl daemon-reload
sudo systemctl enable nexus.service
sudo systemctl start nexus.service
상태와 로그
systemctl status nexus.service --no-pager
sudo journalctl -u nexus.service -n 160 --no-pager
내부 HTTP 상태
curl --fail --silent --show-error --head http://127.0.0.1:8081/
  • systemd-analyze verify가 성공했습니다.
  • application-host와 application-port 검사가 각각 정확히 한 줄을 확인했습니다.
  • nexus 계정이 필요한 설치·데이터·Blob 경로만 접근합니다.
  • 서비스가 enabled·active이고 로컬 8081이 응답합니다.
  • 초기화 중 디스크 부족·DB read-only 오류가 없습니다.
결과 읽기

서비스 active와 UI 준비 완료는 다를 수 있습니다. nexus.log의 준비 완료 메시지와 로컬 HTTP 응답이 모두 정상일 때 프록시를 연결합니다.

다음 판단

첫 로그인 보안 설정과 별도 Blob Store를 UI에서 검증합니다.

6
주의권한·연결·중단 영향을 확인할 단계

첫 로그인·저장소·Blob Store 실제 검증

초기 관리자 비밀번호 파일은 터미널 출력이나 채팅으로 복사하지 않고 보안 콘솔에서만 확인해 즉시 변경합니다. 익명 접근을 검토하고 테스트 전용 저장소로 업로드·다운로드를 한 번씩 수행합니다.

초기 비밀번호 파일 메타데이터
sudo stat -c '%U %G %a %n' /var/lib/nexus/admin.password
내용을 cat·로그·화면 캡처로 노출하지 않고 로컬 보안 콘솔에서만 사용합니다.
리스닝 범위
sudo ss -lntp | grep -E '127\.0\.0\.1:8081[[:space:]]'
0.0.0.0:8081, [::]:8081 또는 공인·사설 인터페이스 주소가 보이면 프록시 연결 전에 중단합니다.
데이터·Blob 사용량
sudo du -sh /var/lib/nexus /srv/nexus-blobs
df -hT /var/lib/nexus /srv/nexus-blobs
HTTPS 프록시
curl --fail --silent --show-error --head https://<NEXUS_PUBLIC_HOST>/
두 번째 로컬 상태
curl --fail --silent --show-error --head http://127.0.0.1:8081/
  • 초기 관리자 비밀번호를 즉시 변경하고 파일 내용을 외부에 노출하지 않았습니다.
  • 익명 접근과 기본 권한을 조직 정책에 맞게 제한했습니다.
  • UI에서 /srv/nexus-blobs의 새 File Blob Store와 Soft Quota를 만들었습니다.
  • 테스트 저장소의 업로드·다운로드·체크섬이 모두 성공했습니다.
  • 두 번째 브라우저 세션에서 최소 권한 사용자 접근을 검증했습니다.
  • 8081은 127.0.0.1에서만 리슨하고 외부 인터페이스에는 열리지 않았습니다.
결과 읽기

Soft Quota는 쓰기를 차단하는 하드 제한이 아니라 경고입니다. OS 파일시스템 경보와 용량 대응 절차가 별도로 필요합니다.

다음 판단

관리 UI·포트·권한·백업과 저장공간 경보를 강화합니다.

7
주의권한·연결·중단 영향을 확인할 단계

익명 접근·TLS·동일 복구시점 백업 강화

8081은 루프백에서만 접근하게 하고 외부에는 TLS 프록시만 공개합니다. 백업 창에는 프록시·CI의 신규 쓰기를 차단합니다. H2는 UI의 Admin - Backup H2 Database Task가 끝난 직후 Nexus를 중지하고, 외부 PostgreSQL은 Nexus를 중지한 뒤 pg_dump를 수행합니다. 선택한 DB 백업과 같은 복구점 ID로 모든 Blob Store, /var/lib/nexus/etc, /var/lib/nexus/keystores/node를 함께 보존하며 두 DB 분기를 섞지 않습니다.

계정·경로 권한
getent passwd nexus
sudo stat -c '%U %G %a %n' /var/lib/nexus /srv/nexus-blobs /etc/systemd/system/nexus.service
네트워크 노출
sudo ss -lntup | grep -E ':8081[[:space:]]'
여유공간과 inode
df -hT /var/lib/nexus /srv/nexus-blobs
df -i /var/lib/nexus /srv/nexus-blobs
최근 경고
sudo journalctl -u nexus.service -p warning --since today --no-pager
유닛 보안 분석
systemd-analyze security nexus.service
백업 분기 재확인
if sudo test -f /var/lib/nexus/etc/fabric/nexus-store.properties; then echo 'use external PostgreSQL backup branch only'; elif sudo test -f /var/lib/nexus/db/nexus.mv.db; then echo 'use embedded H2 backup task branch only'; else echo 'STOP: database mode is unknown' >&2; exit 1; fi
sudo test -d /var/lib/nexus/keystores/node
파일 내용을 출력하지 않습니다. DB 방식을 확정하고 쓰기 차단·승인된 유지보수 창을 연 뒤에만 해당 분기로 진행합니다.
외부 PostgreSQL 백업 분기
pg_dump --host=<PG_HOST> --username=<PG_BACKUP_USER> --format=custom --file=<RECOVERY_POINT_DIR>/database/nexus-postgresql.dump <NEXUS_DATABASE>
pg_restore --list <RECOVERY_POINT_DIR>/database/nexus-postgresql.dump
외부 PostgreSQL 분기에서 Nexus를 정상 중지한 뒤에만 실행합니다. 비밀번호는 명령 인자나 PGPASSWORD에 넣지 말고 승인된 pgpass·대화형 프롬프트를 사용합니다. H2 분기에서는 실행하지 않습니다.
H2 백업 Task 결과 검증
sudo unzip -t <RECOVERY_POINT_DIR>/database/nexus-<H2_TASK_TIMESTAMP>.zip
H2 분기에서 UI의 Admin - Backup H2 Database Task가 만든 ZIP에만 실행합니다. Task 완료 직후 Nexus를 중지하고, 그 사이 신규 쓰기나 정리 Task를 허용하지 않습니다.
동일 복구점 필수 항목 검증
sudo test -d <RECOVERY_POINT_DIR>/blob-stores
sudo test -d <RECOVERY_POINT_DIR>/data-dir/etc
sudo test -d <RECOVERY_POINT_DIR>/data-dir/keystores/node
sudo test -f <RECOVERY_POINT_DIR>/SHA256SUMS
cd <RECOVERY_POINT_DIR> || exit 1
sudo sha256sum --check SHA256SUMS
Nexus가 중지된 동안 승인된 파일시스템·객체 스토리지 백업 도구로 모든 Blob Store와 설정·Node ID를 같은 RECOVERY_POINT_DIR에 백업한 뒤 검사합니다. 하나라도 실패하면 유효한 복구점으로 승인하지 않습니다.
  • 외부 접근은 CA 서명 TLS 프록시로 제한되고 8081은 공인망에 노출되지 않습니다.
  • admin 대신 저장소별 최소 권한 역할·서비스 계정을 사용합니다.
  • Soft Quota와 OS 잔여공간·inode 경보를 함께 구성했습니다.
  • 정리 Task는 대상과 보존기간을 미리 검토하고 백업 뒤 실행합니다.
  • H2 Task ZIP 또는 PostgreSQL dump 중 정확히 하나와 모든 Blob Store·설정·keystores/node가 같은 복구점 ID·체크섬 목록에 있습니다.
  • 별도 격리 호스트에서 같은 복구점을 복원해 저장소 목록과 샘플 아티팩트 다운로드·체크섬을 검증했습니다.
결과 읽기

OS에서 Blob 파일을 직접 지우면 DB 메타데이터와 불일치합니다. 공간 회수는 Repository·Cleanup Policy·Compact Blob Store의 공식 작업을 사용하고 실행 전 영향 범위를 검토합니다.

다음 판단

장애 시 쓰기를 차단하고 데이터 보존 롤백으로 이동합니다.

8
변경패키지·설정·서비스 상태가 달라지는 단계

서비스 중지와 구성·동일 복구시점 복원

프록시와 CI 배포 계정에서 신규 쓰기를 먼저 차단하고 Nexus를 정상 중지합니다. 설정 롤백과 데이터 재해 복구를 구분합니다. 데이터 복원은 운영 경로에 바로 덮어쓰지 않고 격리 복제 환경에서 H2 또는 외부 PostgreSQL 중 한 분기만 선택해 같은 복구점의 DB·Blob Store·설정·Node ID를 모두 검증한 뒤 수행합니다.

변경 단계입니다. 대상 서버, 백업 파일, 서비스 중단 영향과 바로 이전 상태로 돌아가는 방법을 다시 확인하세요.
서비스 중지
sudo systemctl stop nexus.service
systemctl is-active nexus.service
기존 vmoptions 복원
sudo cp --preserve=all /opt/sonatype/nexus/bin/nexus.vmoptions.<BACKUP_SUFFIX>.bak /opt/sonatype/nexus/bin/nexus.vmoptions
기존 설치의 검증된 같은 시점 백업에서만 실행합니다.
기존 nexus.properties 복원
sudo cp --preserve=all /var/lib/nexus/etc/nexus.properties.<BACKUP_SUFFIX>.bak /var/lib/nexus/etc/nexus.properties
기존 설치의 같은 변경 시점 백업이 있는 설정 롤백 분기에서만 실행합니다.
신규 nexus.properties 보존 비활성화
sudo mv --no-clobber /var/lib/nexus/etc/nexus.properties /var/lib/nexus/etc/nexus.properties.disabled.<BACKUP_SUFFIX>
백업이 없는 최초 설치 설정 롤백 분기에서만 실행합니다. 기존 속성 파일 백업이 있다면 이 명령을 실행하지 않습니다.
기존 유닛 복원
sudo cp --preserve=all /etc/systemd/system/nexus.service.<BACKUP_SUFFIX>.bak /etc/systemd/system/nexus.service
기존 설치 분기에서만 실행합니다.
최초 설치 자동 시작 해제
sudo systemctl disable nexus.service
신규 설치 롤백 분기에서 실행합니다.
최초 설치 유닛 보존 비활성화
sudo mv --no-clobber /etc/systemd/system/nexus.service /etc/systemd/system/nexus.service.disabled.<BACKUP_SUFFIX>
신규 설치 분기에서만 실행하며 설치·데이터·Blob·로그는 보존합니다.
유닛 다시 읽기
sudo systemctl daemon-reload
복구점 체크섬·구성요소 검증
sudo test -d <RECOVERY_POINT_DIR>/blob-stores
sudo test -d <RECOVERY_POINT_DIR>/data-dir/etc
sudo test -d <RECOVERY_POINT_DIR>/data-dir/keystores/node
sudo test -f <RECOVERY_POINT_DIR>/SHA256SUMS
cd <RECOVERY_POINT_DIR> || exit 1
sudo sha256sum --check SHA256SUMS
검증 실패 시 복원하지 않습니다. RECOVERY_POINT_DIR은 DB·Blob Store·설정·Node ID가 같은 백업 창에서 만들어진 하나의 복구점이어야 합니다.
H2 복원 입력 검증
sudo unzip -t <RECOVERY_POINT_DIR>/database/nexus-<H2_TASK_TIMESTAMP>.zip
H2 분기에서만 사용합니다. 격리 호스트의 Nexus를 중지한 상태로 ZIP 안의 동일 timestamp DB 파일 전부를 빈 $data-dir/db에 복원하고, 같은 복구점 Blob Store·etc·keystores/node를 배치한 뒤 시작합니다. 개별 H2 파일만 고르지 않습니다.
외부 PostgreSQL 복원 입력 검증
pg_restore --list <RECOVERY_POINT_DIR>/database/nexus-postgresql.dump
외부 PostgreSQL 분기에서만 사용합니다. 격리된 빈 DB에 승인된 PostgreSQL 복원 절차로 이 dump를 복원하고 같은 복구점 Blob Store·etc·keystores/node를 배치합니다. H2 DB 파일과 섞지 않습니다.
데이터 보존 검증
sudo du -sh /var/lib/nexus /srv/nexus-blobs
sudo find /var/lib/nexus /srv/nexus-blobs -maxdepth 0 -printf '%U %G %m %p
'
  • 신규 쓰기 요청을 차단한 뒤 서비스를 정상 중지했습니다.
  • 기존 설치는 같은 변경 시점의 vmoptions·유닛만 복원했습니다.
  • 기존 nexus.properties를 복원했거나 최초 설치 파일만 .disabled로 보존했으며 두 분기를 섞지 않았습니다.
  • 신규 설치는 유닛만 .disabled로 이동하고 데이터와 Blob을 보존했습니다.
  • 이전 바이너리와 현재 데이터베이스 스키마의 호환성을 확인 전 시작하지 않았습니다.
  • 복구는 격리 복제 환경에서 H2 또는 PostgreSQL 중 한 분기와 같은 복구점의 모든 Blob Store·설정·Node ID로 먼저 검증했습니다.
  • 격리 복제는 application-host=127.0.0.1로 시작했고 저장소 목록·샘플 다운로드·체크섬·Node ID 존재를 확인했습니다.
결과 읽기

애플리케이션 바이너리만 이전 버전으로 바꾸는 것은 DB 마이그레이션 때문에 안전하지 않을 수 있습니다. Sonatype 업그레이드 경로와 백업 호환성을 확인해야 합니다.

다음 판단

원인과 지원되는 복구 지점을 확정한 뒤 복제 환경에서 저장소 다운로드까지 검증합니다.

SECURITY CHECK

운영 전 마지막 보안 점검

  • Nexus를 로그인 불가 전용 계정으로 실행하고 admin 일상 사용을 피한다.
  • 8081을 공인망에 노출하지 않고 CA 서명 TLS 프록시만 공개한다.
  • Blob Store 파일을 OS에서 직접 수정·이동·삭제하지 않는다.
  • Soft Quota와 OS 잔여공간·inode 경보를 함께 운영한다.
  • DB·설정과 Blob Store를 같은 시점으로 백업하고 복원을 시험한다.
  • keystores/node의 Node ID를 DB·Blob Store·설정과 같은 복구점으로 보존한다.

COMMON ERRORS

자주 막히는 지점

서비스 초기화 지연

증상
systemd는 active 또는 activating이지만 UI가 오래 열리지 않습니다.
가능한 원인
초기 DB 생성, 느린 스토리지, JVM 메모리 또는 파일 권한 문제가 원인입니다.
확인 순서
재시작을 반복하지 말고 nexus.log와 디스크 I/O·권한을 확인합니다.
트러블슈팅으로 이어보기

데이터베이스 read-only

증상
업로드가 실패하고 저장공간 경고가 발생합니다.
가능한 원인
가용 공간이 최소 안전선 아래로 내려갔거나 Blob 정리 지연이 누적됐습니다.
확인 순서
신규 쓰기를 멈추고 파일시스템 사용량과 공식 Cleanup·Compact Task 상태를 확인합니다. Blob 파일을 직접 지우지 않습니다.
트러블슈팅으로 이어보기

프록시 업로드 실패

증상
큰 아티팩트만 413 또는 timeout으로 실패합니다.
가능한 원인
프록시 요청 크기·시간 제한과 Nexus 저장공간·클라이언트 timeout이 맞지 않습니다.
확인 순서
로컬 업로드와 프록시 로그를 비교하고 승인된 최대 크기에 맞게 제한을 조정합니다.
트러블슈팅으로 이어보기

PRIMARY REFERENCES

공식 문서

설치 저장소와 지원 버전은 바뀔 수 있습니다. 검토일 이후에는 링크된 공식 문서와 현재 서버의 패키지 후보 버전을 함께 확인하세요.

도구 빠른 검색

최근 사용한 도구를 다시 열거나, 이름과 기능으로 검색하세요.

검색어와 도구의 입력·결과는 저장하지 않습니다.

↑↓ 이동 · Enter 열기 · Esc 닫기