journalctl -b -1 로그가 없을 때: 이전 부팅 기록과 저장 방식 점검

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.

이전 부팅 로그가 안 보인다면 먼저 보유 중인 부팅 목록과 조회 권한을 확인하고, journald 저장 방식과 보존 정책을 살펴보세요. 지금 영구 저장을 켜도 이미 사라진 과거 기록이 다시 생기지는 않습니다.

적용 환경: systemd 255 공식 매뉴얼 기준 Linux; 배포판 설정과 설치 버전 별도 확인. 공식 문서 확인일: 2026-10-23. 아래 내용은 문서 기반 점검 가이드이며 운영 환경에서 실행한 시험 결과가 아닙니다.

1. 원인: 조회할 기록이 남아 있는지 먼저 봅니다

journalctl --list-boots는 현재 읽을 수 있는 저널의 부팅 번호·ID·시간 범위를 보여 줍니다. -b -1은 이전 부팅을 고르는 옵션이지, 없어진 로그를 복구하는 명령이 아닙니다. 권한 부족 안내가 있으면 승인된 계정으로 조회 범위를 확인합니다.

2. 해결 순서: 조회와 저장 설정을 분리합니다

journalctl --version
journalctl --list-boots --no-pager
journalctl -b -1 --no-pager -n 100
journalctl --disk-usage

이 명령들은 조회용이며 서버 설정을 바꾸지 않습니다. 부팅 목록의 날짜가 찾는 사고 시간대와 맞는지 확인하세요. -n 100은 표시 줄 수만 제한합니다.

Storage 값	기본 저장 동작
volatile	/run/log/journal의 휘발 저장
persistent	디스크 저장을 우선 사용
auto	/var/log/journal 존재 여부에 따라 결정
none	저널 저장을 하지 않음

실제 설정은 본 파일뿐 아니라 drop-in의 우선순위도 확인합니다. persistent여도 초기 부팅이나 디스크가 쓰기 불가능한 동안에는 휘발 저장으로 대체될 수 있습니다. 영구 저장 여부와 무기한 보존 여부는 별개입니다.

3. 확인: 앞으로 남는 기록을 검증합니다

저장 방식 변경이 필요하면 기존 설정과 디스크 여유 공간을 먼저 기록하고 승인된 변경 절차를 사용합니다. 이후 정상 운영 중 새 기록이 지속 저장되는지 확인합니다. 검증 때문에 운영 서버를 임의로 재부팅하지 않습니다.

과거 기록이 없다면 보존 용량·기간, 아카이브 정리 이력과 별도 로그 수집처를 확인합니다. 보존된 기록을 더 지우는 vacuum 명령은 원인 조사 단계에서 실행하지 않습니다.

4. 주의와 FAQ

persistent이면 이전 로그가 모두 복원되나요? 아닙니다. 저장되지 않았거나 이미 제거된 데이터는 설정 변경으로 복구되지 않습니다.

--disk-usage가 크면 이전 부팅이 있나요? 사용량만으로는 알 수 없습니다. 부팅 ID와 실제 기록을 함께 확인합니다.

매뉴얼과 서버가 다른데요? 이 글은 systemd 255 문서를 기준으로 작성했습니다. 설치 버전과 배포판 기본값·관리 정책을 우선 확인하세요.

공식 출처와 이어 읽기

journalctl 255 조회 옵션

journald 255 저장 설정

systemd 서비스 최초 실패와 재시작 제한 진단