전체 시스템 파티션이 NAS 앱에 영향을 미치는지 확인하는 방법

전체 시스템 파티션이 가득 차면 대용량 데이터 풀에 테라바이트의 여유 공간이 있어도 NAS 앱이 중단될 수 있습니다.

애플리케이션은 로그, 데이터베이스, 임시 파일, 업데이트, 컨테이너 레이어, 소켓, 구성 기록을 위해 로컬 공간이 필요합니다. 어떤 마운트가 가득 찼는지 확인하고, 앱 오류를 실패한 쓰기와 일치시키며, 시스템 소비자를 찾아 해당 구성 요소를 통해 공간을 회수하세요.

시스템 파티션이 가득 찬 마운트인지 확인하기

모든 마운트된 파일시스템을 확인하고 루트, 부트, 애플리케이션, 컨테이너, 데이터 경로를 매핑하세요. 첫 번째 작업은 정확히 어떤 마운트가 가득 찼는지 확인하는 것입니다. 데이터 풀의 여유 공간은 루트 파일시스템에 쓰기를 만족시킬 수 없기 때문입니다.

df -h 명령어로 블록 용량을, df -i 명령어로 파일 레코드를 확인하세요. 경로는 여유 블록과 여유 아이노드가 별도의 한계일 때 둘 중 하나가 소진되면 새 파일을 거부할 수 있습니다.

앱 실패를 부족한 쓰기 공간과 일치시키기

“공간 부족”, 읽기 전용 파일시스템, 저널 실패, 임시 파일 생성 불가 등의 메시지를 앱, 데이터베이스, 컨테이너, 시스템 로그에서 확인하세요. 앱은 메모리에서 웹 페이지를 계속 표시할 수 있지만 백그라운드 작업, 업로드, 데이터베이스 커밋은 실패할 수 있습니다.

타임스탬프를 기록하고 영향을 받은 경로에서 무해한 쓰기 테스트를 하세요. 증거를 확보하기 전에는 광범위한 재시작을 피하세요. 모든 앱을 재시작하면 로그가 더 생성되고 최초 오류가 가려지며 다음에 실패하는 서비스가 바뀔 수 있습니다.

로그, 컨테이너 레이어, 아이노드, 삭제된 파일 찾기

최상위 시스템 디렉터리 크기를 측정한 후 가장 큰 결과를 자세히 조사하세요. 일반적인 공간 소비자는 저널, 애플리케이션 로그, 이미지 레이어, 빌드 캐시, 크래시 덤프, 패키지 캐시, 썸네일, 임시 파일입니다. 불투명한 데이터 디렉터리를 삭제하기 전에 앱 또는 컨테이너 관리자의 보고 기능을 사용하세요.

디렉터리 총합이 파일시스템 사용량을 설명하지 못하면 아직 열려 있는 삭제된 파일이 있는지 확인하세요. 아이노드가 가득 찼다면 작은 캐시나 세션 파일이 많은 디렉터리를 찾아보세요. 복구 후에는 로그 회전 및 보존 한도를 설정하여 긴급 삭제를 반복하지 않도록 하세요.

안전하게 공간 확보하고 복구 확인하기

문서화된 정리 경로부터 시작하세요: 로그를 회전하거나 정리하고, 사용하지 않는 패키지 캐시를 제거하며, 사용하지 않는 컨테이너 아티팩트만 정리하고, 도구를 통해 오래된 크래시 덤프를 삭제하세요. 데이터베이스, 명명된 볼륨, 활성 이미지, 구성은 검증된 백업이 있을 때까지 보존하세요.

파일시스템 및 아이노드 사용량을 다시 확인한 후 영향을 받은 의존성 체인만 재시작하고 실제 앱 쓰기를 테스트하세요. 복구가 여전히 실패하면 공간 문제라고 가정하지 말고 재부팅 후 서비스 시작 순서를 조사하세요.

자주 묻는 질문

NAS 데이터 풀에 여유 공간이 있는데도 앱이 실패하는 이유는?

앱이 데이터베이스, 로그, 임시 파일, 컨테이너 상태를 더 작은 시스템 파티션에 쓸 수 있습니다. 용량은 마운트 간에 자동으로 공유되지 않습니다.

로그 파일을 삭제하면 문제가 더 악화될 수 있나요?

네. 실행 중인 프로세스가 삭제된 로그를 계속 열고 있을 수 있어 경로는 사라져도 공간이 점유된 상태로 남습니다. 올바른 서비스 절차를 통해 로그를 회전하거나 축소하세요.

시스템 파티션은 얼마나 많은 여유 공간을 유지해야 하나요?

보편적인 비율은 없습니다. 업데이트, 로그, 데이터베이스 유지관리, 컨테이너 증가, 복구 작업을 위한 충분한 여유 공간을 확보하고, 성장 속도와 남은 양 모두에 대해 알림을 설정하세요.