journald vacuum, 디스크를 어떻게 줄이나

journald vacuum은 journalctl --vacuum-size=·--vacuum-time=·--vacuum-files=로 이미 아카이브된 저널 파일을 지워 디스크를 즉시 줄이는 작업입니다. 장기적으로는 journald.conf의 Storage=와 SystemMaxUse=(또는 Runtime 계열)로 상한을 고정합니다.

이 글은 디스크 사용량·보존(retention) 만 다룹니다. -u·-p·-S 같은 필터로 로그를 찾는 방법은 별도 글(#17 각도)을 참고하시기 바랍니다. 가격·플랜 비교는 없습니다.

vacuum 옵션은?

한 줄 답: --vacuum-size=는 용량 한도, --vacuum-time=는 기간 한도, --vacuum-files=는 파일 개수 한도이며, 세 가지를 한 번에 합칠 수 있습니다. 필요하면 --rotate를 앞에 붙여 활성 파일까지 아카이브한 뒤 비웁니다.

먼저 사용량을 확인합니다.

journalctl --disk-usage

즉시 정리 예:

# 아카이브 합이 약 200M 이하가 될 때까지 오래된 파일부터 삭제
sudo journalctl --vacuum-size=200M

# 2주보다 오래된 아카이브 삭제
sudo journalctl --vacuum-time=2weeks

# 아카이브 파일 개수를 제한
sudo journalctl --vacuum-files=5

# 크기·시간·개수를 한 호출에 결합
sudo journalctl --vacuum-size=500M --vacuum-time=30days --vacuum-files=10

공식 journalctl(1) 기준으로 알아둘 점:

vacuum은 아카이브된 저널만 대상입니다. 현재 쓰고 있는(active) 파일은 지우지 않습니다.
그래서 --disk-usage가 vacuum 직후에도 크게 안 줄 수 있습니다. 활성 파일 용량이 포함되기 때문입니다.
--rotate와 함께 쓰면 활성 파일을 먼저 아카이브한 뒤 vacuum이 돌아가므로, “지금까지 쌓인 로그”를 최대한 반영해 비울 수 있습니다.

sudo journalctl --rotate --vacuum-size=200M

인자를 0으로 두는 것은 “그 한도를 적용하지 않음”과 같아서 사실상 불필요합니다. 단위는 크기 K/M/G/T(1024 기준), 시간은 s/m/h/days/weeks/months/years 등 systemd.time 문법을 따릅니다.

persistent vs volatile?

한 줄 답: Storage=persistent면 /var/log/journal에 남겨 재부팅 후에도 남고, volatile이면 /run/log/journal에만 두어 재부팅 시 사라집니다. auto는 /var/log/journal 디렉터리가 있으면 persistent처럼 동작합니다.

설정 위치는 보통 /etc/systemd/journald.conf 또는 /etc/systemd/journald.conf.d/*.conf입니다.

Storage	위치	재부팅 후
`persistent`	`/var/log/journal` 우선	유지
`volatile`	`/run/log/journal`	소실
`auto`	디렉터리 존재 여부에 따름	조건부
`none`	저널 저장 최소화	—

디스크 상한은 접두사로 나뉩니다.

System* (SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles=) — persistent, /var/log/journal
Runtime* (RuntimeMaxUse= 등) — volatile, /run/log/journal

예: 영속 저널을 대략 200M로 제한

# /etc/systemd/journald.conf.d/size.conf
[Journal]
Storage=persistent
SystemMaxUse=200M
# 다른 용도를 위해 남길 여유(선택)
# SystemKeepFree=1G

적용:

sudo mkdir -p /etc/systemd/journald.conf.d
# 위 파일 작성 후
sudo systemctl restart systemd-journald
# 또는 daemon-reload 후 journald 재시작(배포판 관행에 따름)

journald.conf(5)에 따르면, 기동 시점에 이미 한도를 넘긴 상태면 한도가 “실제 여유”에 맞게 올라갈 수 있고, 이후 다른 프로세스가 디스크를 채운다고 해서 journald가 기존 파일을 알아서 더 깎지는 않습니다. 그래서 급할 때는 vacuum으로 아카이브를 지우고, 평소에는 SystemMaxUse=로 상한을 걸어 두는 조합이 실무적입니다.

부팅 초기에 /var가 아직 없으면 volatile로 쓰다가, journalctl --flush(또는 systemd-journal-flush.service)로 /var/log/journal에 넘기는 흐름도 있습니다. vacuum 대상·경로를 헷갈리면 Storage=와 실제 디렉터리 존재 여부를 먼저 확인합니다.

서비스 로그는 남기나?

한 줄 답: vacuum은 서비스별 필터가 아니라 오래된 아카이브 파일 단위로 지웁니다. 특정 유닛만 “영원히” 남기려면 저널 vacuum만으로는 부족하고, 별도 파일 로그·원격 수집·보존 정책이 필요합니다.

오해하기 쉬운 점:

journalctl -u nginx.service로 조회하는 것과, vacuum으로 디스크를 비우는 것은 다른 축입니다.
vacuum 후 최근 아카이브·활성 파일에 남아 있는 구간은 유닛 필터로 다시 볼 수 있습니다. 삭제된 오래된 구간은 어떤 -u로도 복구되지 않습니다.
감사·규정 때문에 특정 서비스만 장기 보관해야 하면, rsyslog/파일 리다이렉트, 원격 syslog, 또는 백업 파이프라인으로 저널 바깥에 복사하는 편이 맞습니다.

실무 체크리스트:

디스크 알람이 울리면 → journalctl --disk-usage → --rotate --vacuum-size=…
재발 방지 → SystemMaxUse= / RuntimeMaxUse= 고정
“이 서비스만 길게” → 저널 vacuum이 아니라 별도 retention 경로
필터로 원인을 찾을 때 → vacuum 글이 아니라 필터 howto

마무리

journald 디스크를 줄이려면 journalctl --vacuum-*로 아카이브를 즉시 비우고, Storage=·SystemMaxUse=로 상한을 고정합니다. vacuum은 활성 파일을 직접 지우지 않으므로 효과가 약하면 --rotate를 함께 씁니다. 유닛 필터로 로그를 찾는 방법과, 디스크를 비우는 방법을 섞지 않으면 운영이 단순해집니다.

journald vacuum, 디스크를 어떻게 줄이나

vacuum 옵션은?

persistent vs volatile?

서비스 로그는 남기나?

마무리

출처