서버 로그 관리 스크립트 문의드립니다.

---

최근 서버 운영하면서 로그 파일 용량 관리가 꽤 이슈가 되고 있습니다.
어떤 시스템은 로그가 계속 누적되면서 디스크 용량을 빠르게 잠식하고 있어서요.
단순히 오래된 파일 지우는 것보다, 주기적으로 백업하면서 안전하게 보관하고, 일정 기준(예: 3개월 이상)은 삭제하는 로직이 필요한 상황입니다.
혹시 이런 패턴을 구현하는 효율적인 쉘 스크립트나, 혹은 이 부분에 대해 검증된 아키텍처 패턴 아시는 분 계실까요?
특정 환경(Linux 기준)에 최적화된 코드를 참고하고 싶습니다.

안녕하세요.
로그 관리 문제로 고생하고 계시네요.
이거 정말 서버 운영하면서 가장 흔하게 부딪히는 문제 중 하나라 저도 여러 번 겪어봤던 부분입니다.
단순히 오래된 거 지우는 것보다 '보관'과 '삭제'의 경계를 잘 설정하는 게 핵심이죠.
말씀하신 '주기적 백업 후 일정 기간 보관하고 삭제' 패턴은 사실 리눅스 시스템 관리에서 매우 기본적이면서도 중요한 부분이라, 워낙 다양한 방식이 존재합니다.
어떤 수준의 안전성과 복구 능력을 원하시는지에 따라 접근법이 달라지기 때문에, 몇 가지 관점별로 접근법과 팁을 드려볼게요.
--- ### 1.
가장 기본적인 접근: logrotate 활용 (★가장 추천하는 기본 방어막) 만약 특별한 커스텀 로직이 필요하지 않고, 시스템 기본 기능만으로 해결하고 싶다면, 무조건 logrotate를 써보시는 게 제일 좋습니다.
이건 그냥 쉘 스크립트 하나로 뚝딱 만들 때보다 훨씬 안정적이고, 시스템 차원에서 검증된 방식이라서요.
logrotate는 로그 파일을 회전(rotate)시키고, 압축(compress)하며, 오래된 버전을 정리해주는 전용 유틸리티입니다.
대부분의 서비스(Apache, Nginx 등)는 이미 /etc/logrotate.d/ 디렉터리 안에 설정 파일이 존재할 거예요.
핵심 원리: 1.
압축: logrotate는 보통 gzip 같은 걸 사용해서 이전 로그 파일들을 압축합니다.
용량 절감 효과가 확실하죠.
2.
보관 주기: 설정 파일 내에서 rotate N 옵션을 사용해서 몇 개까지 보관할지 정할 수 있습니다.
(예: rotate 32면 32개 분량 보관) 3.
삭제 주기: maxage 옵션이나, 설정 자체를 통해 오래된 파일은 아예 삭제하도록 지정할 수 있습니다.
팁: 만약 특정 서비스의 로그가 너무 빨리 쌓인다면, 해당 서비스의 설정 파일(예: /etc/logrotate.d/myapp)을 열어서 daily나 weekly 같은 주기 설정과 함께 rotate 값을 조절해보세요.
이걸 쓰면 스크립트 오류 위험이 거의 없고, 시스템 부하도 적습니다.
--- ### 2.
쉘 스크립트 기반의 커스텀 로직 구현 (고급 사용자용) 만약 logrotate가 처리하기 어려운 아주 특수한 로직(예: 특정 패턴의 로그만 백업하거나, 백업할 때 메타데이터를 추가해야 할 때)이 필요하다면, 쉘 스크립트가 필요합니다.
이 경우는 '백업'과 '삭제'를 분리해서 생각해야 합니다.
A.
백업(Archive) 로직: * 기준 설정: 어떤 로그를 백업할지 명확히 정의해야 합니다.
(예: /var/log/app/ 디렉토리 전체) * 타임스탬프 활용: 백업 시점의 날짜를 포함하는 디렉토리를 만드는 게 중요합니다.
TIMESTAMP=$(date +%Y%m%d) mkdir -p /mnt/backup_logs/$TIMESTAMP tar -czf /mnt/backup_logs/$TIMESTAMP/logs_$TIMESTAMP.tar.gz /var/log/app/ B.
보관 및 삭제(Retention) 로직: 여기가 가장 중요합니다.
백업된 디렉터리들을 순회하면서 오래된 것을 지워야 하죠.

오래된 백업 디렉토리 찾기 및 삭제 find "$LOG_BACKUP_DIR" -maxdepth 1 -type d -mtime +$RETENTION_DAYS -exec echo "삭제 예정: {}" \; -exec rm -rf {} \; # 2.
(선택 사항) 만약 로그 파일 자체를 주기적으로 정리하고 싶다면 # find /var/log/app -type f -mtime +365 -delete # 1년 넘은 파일 통째로 삭제 (매우 주의 필요!) ``` **실무 팁 및 주의점 (스크립트 사용 시):** 1.
**`find` 명령어의 이해:** * `-mtime +N`: N일 전 마지막으로 수정된 파일/디렉토리를 찾습니다.
(이게 핵심입니다.) * `-type d`: 디렉토리만 찾습니다.
* `-exec command {} \;`: 찾은 각 항목에 대해 명령을 실행합니다.
2.
**`rm -rf`의 위험성:** 절대 함부로 쓰면 안 됩니다.
삭제할 대상(`{}`)을 반드시 `--dry-run`으로 먼저 테스트해보세요.
3.
**실행 주기:** 이 스크립트는 반드시 `cron` 작업으로 등록해야 합니다.
(예: 매일 새벽 1시에 실행) --- ### 3.
아키텍처 관점에서의 접근 (진짜 엔터프라이즈급) 만약 이 문제가 단순한 스크립트 문제가 아니라, 시스템 아키텍처의 일부로 다뤄져야 한다면, 단순히 '삭제'가 아니라 '분리'하는 관점으로 접근해야 합니다.
**A.
중앙 집중식 로깅 시스템 도입 (가장 이상적):** 로그를 서버 로컬 디스크에 남기지 않고, 모든 서버에서 발생하는 로그를 **ELK Stack (Elasticsearch, Logstash, Kibana)** 이나 **Grafana/Loki** 같은 전문 로깅 시스템으로 전송하는 것이 가장 모범적인 패턴입니다.
* **장점:** 디스크 용량 걱정이 사라지고, 검색/분석/보존 정책(Retention Policy)이 UI/API 레벨에서 완벽하게 통제 가능합니다.
* **단점:** 초기 구축 비용과 학습 곡선이 매우 높습니다.
**B.
로그 전용 저장소 분리:** 아예 로그를 기록할 전용 마운트 지점(예: NFS로 마운트된 별도 서버의 디스크)을 만들고, 이 로그만 관리하는 전용 서비스(Daemon)를 돌리는 방법입니다.
* 이 경우, 로컬 디스크는 시스템 로그와 핵심 애플리케이션 로그만 남기고, 모든 대용량 로그는 이 전용 저장소로 보내버리는 구조가 됩니다.
--- ### 📚 종합 정리 및 체크리스트 (질문자님께 드리는 조언) 어떤 방법을 택하든, 아래 세 가지 질문에 스스로 답해보세요.
1.
**"이 로그를 3개월 뒤에 다시 봐야 할 가능성이 있는가?"** * Yes $\rightarrow$ **백업 (압축 + 별도 저장소)** 후 보관.
(스크립트/`logrotate` 활용) * No $\rightarrow$ 즉시 삭제하거나, 7일 정도만 임시 보관 후 삭제.
(자동 정리) 2.
**"로그를 단순히 지우는 것만으로 충분한가, 아니면 검색/분석이 필요한가?"** * 단순 삭제 $\rightarrow$ `logrotate` 또는 `find -mtime` 기반 삭제.
* 검색/분석 $\rightarrow$ 전문 로깅 시스템(ELK 등) 도입 검토.
3.
**"이 스크립트를 누가, 언제, 어떻게 실행할 것인가?"** * `cron`이나 `systemd timer`를 이용해 **작업 실패 시 알림(Alert)** 기능까지 추가하는 것이 가장 안전합니다.
(예: 스크립트 실행 후 로그가 남는지 확인하는 로직 추가) 결론적으로, **가장 빠르고 안전한 개선책은 `logrotate`를 점검하고, 이것으로 부족한 부분만 `find`와 `tar`를 이용한 백업/삭제 스크립트로 보완**하는 것입니다.
로그 관리는 한 번의 설정으로 끝나지 않고, 서비스 규모나 요구사항 변화에 따라 계속 정책을 수정해야 하는 작업입니다.
처음에는 간단하게 시작해서, 문제가 생기거나 요구사항이 늘어남에 따라 아키텍처 레벨로 끌어올리는 점진적인 접근을 추천드립니다.
궁금한 점 있으시면 언제든지 다시 질문해주세요.
화이팅입니다!