icewhale-files-backup이 RAM을 수 기가바이트까지 점유하고 ZimaOS 1.7.0에서 OOM 킬러를 반복적으로 실행한다면, 먼저 ZimaOS 1.7.1 이상으로 업데이트하세요. IceWhale의 1.7.1 릴리스 노트에는 특정 파일 작업 시나리오에서 발생하는 비정상적인 메모리 사용량과 백업 실패 및 중단 문제가 명시적으로 수정되었다고 나와 있습니다.
원본 스레드에서는 1.7.0의 심각한 회귀 문제가 보고되었습니다. 메모리 사용량이 약 3.5GB에서 10GB 이상으로 증가했고, 커널이 Backup 프로세스를 종료했으며, Restart=always 설정으로 프로세스가 다시 실행되었습니다. 이 과정이 반복되면서 서버가 불안정해졌습니다. 서비스를 마스킹하면 반복 실행을 멈출 수 있었지만, 이는 긴급 임시 조치일 뿐입니다.
OOM 반복 루프 확인
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hBackup 프로세스가 반복적으로 메모리 사용량 최상위에 나타난다면, 재시작 루프가 Docker와 다른 서비스의 메모리를 고갈시킬 수 있습니다.
1.7.1 이상으로 업데이트
공식 ZimaOS 1.7.1 릴리스 노트에는 비정상적인 메모리 사용량과 실패하거나 중단될 수 있었던 백업 작업에 대한 수정 사항이 나와 있습니다.
1.7.0에서의 긴급 복구
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.service서비스의 재시작 정책으로 인해 일반적인 중지나 비활성화만으로는 재실행을 항상 막을 수 없었으므로 마스킹이 필요했습니다.
마스킹으로 인해 중단되는 기능 이해하기
마스킹하면 내장 Backup 기능이 비활성화됩니다. 정상적으로 사용할 수 없는 호스트를 업데이트하거나 데이터를 복구할 수 있을 만큼 안정화해야 할 때만 사용하세요.
업데이트 후 마스킹 해제
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.service그런 다음 RAM과 스왑을 모니터링하면서 소규모의 통제된 백업을 실행하세요.
USB 백업 작업이 흔한 원인이었습니다
여러 사용자가 USB 백업 대상에서 비슷한 동작을 보고했습니다. 이는 버그를 재현하는 데 도움이 되지만, 인클로저 자체가 원인이라는 뜻은 아닙니다.
백업 완전성 확인
소스와 대상의 파일 개수를 비교하고 복원 테스트를 수행하세요. 백업 검증 가이드를 참고하면 하나의 작업에 대한 의존도를 줄일 수 있습니다.
메모리 고갈로 Docker가 손상되었는지 확인
해당 스레드에서는 장시간 메모리 압박이 지속된 후 Docker 애플리케이션을 사용할 수 없게 되었습니다. 호스트가 안정화된 후 대규모 백업 작업을 다시 시작하기 전에 docker ps, Docker 데몬 및 주요 컨테이너를 확인하세요.
업데이트 후 소규모 백업부터 시작
문제를 일으킨 수 테라바이트 규모의 작업이나 USB 작업을 즉시 다시 실행하지 마세요. 먼저 소규모 테스트 작업을 만들고 10~20분 동안 메모리를 모니터링한 다음 파일 수와 전체 크기를 점진적으로 늘리세요. 이렇게 하면 수정된 서비스의 메모리 사용량이 안정적으로 유지되는지 확인하기 쉽습니다.
바이트 수만큼 파일 수도 중요
작은 파일 수십만 개는 대용량 미디어 파일 몇 개보다 훨씬 많은 메타데이터 작업을 유발할 수 있습니다. 지원 요청을 제출할 때 전체 바이트 수와 대략적인 파일 개수를 모두 포함하세요.
테스트 중에는 독립적인 백업 경로 유지
내장 Backup이 이전에 불완전하거나 불안정했다면, 복원 테스트를 통해 현재 ZimaOS 작업을 신뢰할 수 있음이 확인될 때까지 별도의 도구나 대상에 정상적으로 작동하는 사본을 추가로 유지하세요.
수정 전후의 로그 보관
업데이트하기 전에 OOM 메시지, 메모리 사용량이 높은 프로세스 목록, ZimaOS 버전 및 백업 대상 유형을 저장하세요. 그런 다음 1.7.1 이상에서 동일한 통제된 작업을 반복하고 메모리 증가량을 비교하세요. 이렇게 하면 단순히 “서버가 안정적인 것 같다”고 판단하는 대신 회귀 문제가 해결되었음을 입증할 수 있습니다.
수정된 버전에서도 메모리가 계속 제한 없이 증가한다면 작업을 중지하고, 업데이트 전후 측정값을 지원팀에 제출하세요.
자주 묻는 질문
여러 사용자가 메모리 누수를 확인했나요?
예. 여러 사용자가 1.7.0에서 동일한 동작을 보고했습니다.
1.7.1에서 이러한 유형의 문제가 해결되었나요?
예. 공식 변경 로그에는 이 문제와 직접적으로 관련된 메모리 및 백업 수정 사항이 포함되어 있습니다.
1.6.2로 되돌려야 하나요?
이는 1.7.1이 출시되기 전의 임시 우회 방법이었습니다. 현재 사용자는 수정된 안정 버전을 우선적으로 사용하는 것이 좋습니다.
수정이 제대로 적용되었는지 어떻게 알 수 있나요?
메모리, 스왑, 로그 및 대상의 백업 완전성을 모니터링하면서 통제된 백업을 실행하세요.
