NHN Cloud 디스크를 늘렸는데 df는 그대로라면: 볼륨·파티션·파일시스템 구분

콘솔에서는 증설된 용량이 보이는데 서버에서 df를 조회하면 이전 크기가 나옵니다. 이때 같은 변경을 다시 요청하기보다, 지금 보고 있는 숫자가 어느 계층의 값인지 확인하는 편이 먼저입니다.

이번 글은 NHN Cloud에 연결된 Linux 블록 스토리지의 용량 반영을 살펴봅니다. 운영 서버에서 실행한 사례나 완료 보고가 아니라, 현재 구성을 확인하고 확장 지원을 상담하기 위한 설명입니다. Windows의 디스크 관리 절차나 복잡한 저장장치 구성 전체를 다루지는 않습니다.

콘솔에서 늘린 용량이 운영체제에 바로 반영되나요?

콘솔의 블록 스토리지 증설과 운영체제의 파일시스템 확장은 구분해 확인해야 하는 단계입니다.

NHN Cloud 블록 스토리지 가이드는 크기를 늘릴 수만 있고 줄일 수는 없다고 안내합니다. 연결된 인스턴스에서는 파티션과 파일시스템 확장도 살피도록 설명하죠. 콘솔의 용량 변경만 보고 서버 안의 반영까지 끝났다고 판단하면 안 되죠.

GNU df 매뉴얼이 설명하는 대상은 파일시스템의 공간입니다. df -hT는 사람이 읽기 쉬운 용량과 파일시스템 유형을 확인하는 조회 예시죠. 콘솔에서 지정한 블록 스토리지 크기를 그대로 검증하는 명령은 아니에요.

따라서 df의 값이 그대로라는 사실만으로 콘솔 증설 실패를 확정하지 않습니다. 변경한 볼륨과 확인 중인 파일시스템이 같은 대상인지부터 맞춰야 하죠. 조회 시각과 단위도 기록해, 다른 대상이나 다른 표시 방식을 비교하지 않도록 합니다.

볼륨·파티션·파일시스템은 어떻게 구분하나요?

볼륨은 제공받는 블록 저장장치이고 파티션은 그 구획이며 파일시스템은 파일을 담는 구조로 구분합니다.

운영체제에서 장치를 나눠 파티션 위에 파일시스템을 사용하는 단순한 구성을 생각해 보세요. 바깥쪽 장치가 커졌다는 사실과 안쪽 파일시스템이 커졌다는 사실은 별도로 확인해야 합니다. 파티션을 쓰지 않거나 다른 계층이 있는 구성도 있으므로 이 그림을 모든 서버의 구조로 일반화하지는 않죠.

lsblk 매뉴얼은 블록 장치 정보를 기본적으로 트리 형태로 보여준다고 설명합니다. 장치와 파일시스템의 관계가 항상 일대일은 아니라는 점도 중요하죠. 화면에 장치가 보인다는 이유만으로 업무 데이터가 그 장치에 있다고 단정하지 않아요.

표의 명령은 상태 조회용입니다. 현재 OS에서 제공하는 출력 열과 로컬 매뉴얼을 확인하고, 콘솔 정보와 마운트 경로를 함께 대조하세요. 단순 조회 결과만으로 변경 대상을 확정하기 어려우면 연결 관계부터 더 확인해야 해요.

파티션이 없는 구성도 같은 절차를 쓰나요?

파티션이 없는 구성은 파티션 확장을 그대로 적용하지 않고 실제 파일시스템과 장치의 관계부터 확인합니다.

NHN Cloud의 Linux 안내는 파티션이 없으면 파일시스템 확장 항목으로 이동하도록 설명합니다. 용량을 반영하려고 없던 파티션을 새로 만들어야 한다는 뜻은 아닙니다. 기존 데이터가 있는 장치의 초기화나 포맷으로 해결하려고 해서는 안 돼요.

논리 볼륨 관리인 LVM이나 암호화 계층 등이 있다면 단순한 파티션 구성의 설명을 그대로 적용하지 않습니다. 추가 계층의 존재와 현재 연결 관계를 정리하고, 각 구성에 맞는 문서를 검토해야 하죠. 이 글은 그런 환경의 변경 명령을 대신하지 않아요.

조사 결과에는 장치·파티션의 유무뿐 아니라 어떤 파일시스템이 어디에 연결되어 있는지도 남깁니다. 이름이 비슷한 다른 디스크를 대상으로 삼지 않도록, 콘솔과 운영체제에서 확인한 근거를 함께 정리하는 방식이 좋습니다.

파일시스템 종류와 연결 대상을 왜 먼저 확인하나요?

파일시스템 유형과 마운트 대상을 먼저 확인해야 현재 구성에 맞는 확장 절차와 확인 범위를 정할 수 있습니다.

NHN Cloud 가이드는 유형을 확인한 뒤 XFS와 Ext4의 확장 예시를 나눠 제시합니다. 문서 속 장치 이름이나 마운트 경로를 운영 서버에 그대로 대입하는 방식은 피해야 하죠. 실제 대상과 운영체제 버전에 맞는 절차를 먼저 검토하죠.

작업 전에는 현재·목표 용량, 백업과 복원 준비, 서비스의 쓰기 작업과 허용 가능한 중단 시간을 정리하세요. 무중단 여부나 복구 방법을 미리 확정하지 않고, 해당 환경에서 확인해야 해요. 특히 NHN 블록 스토리지의 크기를 줄이는 방식으로 원복할 수 있다고 전제하지 않습니다.

작업 후 확인 범위도 미리 정하는 편이 좋습니다. 같은 파일시스템의 용량뿐 아니라 필요한 읽기·쓰기와 서비스 동작을 누가 확인할지 남겨 두세요. 이는 완료 판정을 위한 운영 제안이며, 특정 작업의 무중단이나 데이터 보존을 보장하는 설명은 아니죠.

용량이 남았는데 파일 생성이 실패하는 문제는 디스크 여유가 있는데 파일을 못 만든다면: df -h와 df -i를 함께 보는 이유에서 다룹니다. 이번 글은 inode 진단을 반복하기보다 증설한 용량의 반영 계층에 집중하죠.

스피디 상담에서 확장 작업의 어떤 범위를 정하나요?

현재 저장장치 구조와 목표 용량을 공유하고 대상 확인부터 변경 작업과 사후 점검까지 지원 범위를 협의합니다.

스피디의 클라우드 서비스 안내는 컨설팅부터 도입·운영·기술 지원까지 소개합니다. NHN Cloud 확장 지원을 문의할 때도 증설할 용량만 전달하기보다, 현재 어느 계층까지 확인했는지 함께 정리해 보세요. 실제 작업 범위와 일정은 환경·권한·계약 조건에 따라 협의하죠.

이 목록은 상담을 위한 준비 항목이죠. 모든 OS와 파일시스템의 변경 작업이 기본 지원에 포함된다는 뜻은 아니에요. 대상 확인 지원, 실제 변경, 서비스 확인 중 어디까지 맡을지 구분하는 것이 핵심이죠.

조회 결과를 전달할 때는 상담에 필요한 범위로 정리하고 비밀번호·토큰·개인정보는 제외하세요. 실행하지 않은 작업을 완료로 표시하거나 미확인 항목을 추정해서 채울 필요는 없어요. 확인된 사실과 추가로 점검할 부분을 나누면 지원 범위를 더 명확하게 협의할 수 있죠.

이것만 기억하세요

자주 묻는 질문 (FAQ)