Linux 서버를 운영하다 보면 CPU나 메모리보다 더 자주 마주치는 문제가 바로 디스크와 파일시스템입니다.
“디스크 사용량이 100%가 되었다”, “로그 파일 때문에 서버가 가득 찼다”, “새로운 디스크를 추가해야 한다”, “파일시스템을 확장해야 한다”, “디스크는 남아 있는데 왜 파일을 생성할 수 없는가?“와 같은 문제는 실제 시스템 운영 환경에서 매우 흔하게 발생합니다.
특히 서버에서는 단순히 디스크에 파일을 저장하는 것만으로 끝나지 않습니다. 디스크 장치 확인, 파티션 구성, 파일시스템 생성, 마운트, LVM 관리, 용량 확인, inode 관리, 파일시스템 확장, 장애 분석과 백업까지 종합적으로 이해해야 합니다.
이번 글에서는 Rocky Linux를 비롯한 Linux 서버를 기준으로 디스크 관리와 파일시스템 운영 방법을 실무 중심으로 살펴보겠습니다.
Linux에서는 하드디스크나 SSD와 같은 저장장치를 파일 형태의 장치로 인식합니다.
대표적인 장치 이름은 다음과 같습니다.
/dev/sda
/dev/sdb
/dev/nvme0n1
/dev/nvme1n1
SATA 계열 디스크는 일반적으로 다음과 같은 형태로 표시될 수 있습니다.
/dev/sda
/dev/sda1
/dev/sda2
여기서 /dev/sda는 전체 디스크이고 /dev/sda1, /dev/sda2는 해당 디스크의 파티션입니다.
NVMe SSD는 일반적인 SATA 디스크와 이름 체계가 조금 다릅니다.
/dev/nvme0n1
/dev/nvme0n1p1
/dev/nvme0n1p2
따라서 시스템 엔지니어라면 디스크 이름만 보고도 물리 디스크와 파티션을 구분할 수 있어야 합니다.
서버에 어떤 디스크가 연결되어 있는지 확인하려면 lsblk 명령어를 가장 먼저 사용하는 것이 좋습니다.
lsblk
파일시스템 정보까지 확인하려면 다음과 같이 사용할 수 있습니다.
lsblk -f
예를 들어 다음과 같은 결과가 나올 수 있습니다.
NAME FSTYPE SIZE MOUNTPOINT
sda 100G
├─sda1 xfs 1G /boot
└─sda2 xfs 99G /
sdb 500G
이 정보를 통해 다음을 빠르게 파악할 수 있습니다.
디스크 크기
파티션 구조
파일시스템 종류
마운트 위치
서버에 새로운 디스크를 추가했는데 Linux에서 인식되는지 확인할 때도 lsblk는 가장 먼저 사용하는 명령어 중 하나입니다.
서버 운영에서 가장 많이 사용하는 명령어 중 하나가 df입니다.
df -h
-h는 사람이 읽기 쉬운 단위로 출력하라는 의미입니다.
예를 들어 다음과 같이 표시될 수 있습니다.
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 99G 72G 27G 73% /
여기서 가장 중요한 값은 Use%입니다.
만약 다음과 같이 표시된다면 문제가 발생할 가능성이 높습니다.
/dev/sda2 99G 98G 1G 99% /
디스크 사용량이 100%에 가까워지면 로그 기록, 데이터 저장, 애플리케이션 실행 등에 문제가 발생할 수 있습니다.
디스크가 부족할 때 단순히 파일을 삭제해서는 안 됩니다.
먼저 어느 디렉터리가 많은 공간을 사용하는지 확인해야 합니다.
대표적인 명령어는 du입니다.
du -sh /*
특정 디렉터리를 자세히 확인할 수도 있습니다.
du -sh /var/*
예를 들어 /var/log가 매우 크다면 로그 파일이 디스크를 많이 사용하고 있을 가능성이 있습니다.
du -sh /var/log/*
이러한 방식으로 용량을 많이 사용하는 디렉터리를 단계적으로 좁혀갈 수 있습니다.
Linux 서버에서 초보자가 자주 혼동하는 부분입니다.
디스크 자체의 용량과 파일시스템에서 사용할 수 있는 용량은 같은 개념이 아닙니다.
예를 들어 1TB 디스크가 있다고 해서 반드시 사용자가 1TB 전체를 하나의 파일시스템으로 사용하는 것은 아닙니다.
디스크는 다음과 같이 구성될 수 있습니다.
물리 디스크
↓
파티션
↓
LVM
↓
Logical Volume
↓
파일시스템
↓
마운트
↓
파일
이 구조를 이해하면 Linux 서버의 저장장치 관리가 훨씬 쉬워집니다.
파일시스템은 저장장치에 데이터를 파일과 디렉터리 형태로 관리하기 위한 구조입니다.
대표적인 Linux 파일시스템에는 다음과 같은 종류가 있습니다.
XFS
EXT4
Btrfs
Rocky Linux와 같은 RHEL 계열 서버에서는 XFS가 많이 사용됩니다.
파일시스템은 단순히 파일을 저장하는 것뿐만 아니라 다음과 같은 정보를 관리합니다.
파일 이름
파일 위치
파일 크기
권한
소유자
시간 정보
파일 데이터
메타데이터
따라서 파일시스템에 문제가 발생하면 저장된 파일에 접근하지 못하거나 서버 서비스에 장애가 발생할 수 있습니다.
Linux 서버에서 자주 접하게 되는 파일시스템이 XFS와 EXT4입니다.
XFS는 대용량 파일과 대규모 파일시스템 환경에서 강점을 가지고 있으며 RHEL 계열 서버에서 널리 사용됩니다.
특히 대규모 서버 환경에서 안정적인 성능과 확장성을 제공하는 것이 장점입니다.
EXT4는 Linux에서 오랫동안 널리 사용되어 온 파일시스템입니다.
범용성이 좋고 다양한 Linux 환경에서 사용할 수 있다는 장점이 있습니다.
두 파일시스템의 세부적인 차이를 이해하는 것도 중요하지만, 실무에서는 현재 운영체제와 서비스 요구사항에 맞는 파일시스템을 선택하는 것이 중요합니다.
하나의 물리 디스크를 여러 영역으로 나누어 사용하는 것을 파티셔닝이라고 합니다.
예를 들어 1TB 디스크를 다음과 같이 구성할 수 있습니다.
/dev/sda
├─ /dev/sda1 /boot
├─ /dev/sda2 /
└─ /dev/sda3 /data
이렇게 구성하면 운영체제 영역과 데이터 영역을 분리할 수 있습니다.
서버에서는 데이터 영역을 별도로 구성하면 운영체제 영역의 장애가 데이터 영역에 미치는 영향을 줄이는 데 도움이 될 수 있습니다.
파티션을 구성할 때 MBR과 GPT라는 개념을 만나게 됩니다.
MBR은 오래된 파티션 방식이며 일반적으로 2TB 이하의 디스크와 4개의 Primary Partition이라는 제한이 있습니다.
GPT는 최신 시스템에서 널리 사용되는 방식으로 대용량 디스크와 많은 파티션을 보다 유연하게 관리할 수 있습니다.
최근 서버 환경에서는 특별한 호환성 요구사항이 없다면 GPT를 사용하는 경우가 많습니다.
Linux 서버에서 디스크를 관리할 때 매우 중요한 기술이 **LVM(Logical Volume Manager)**입니다.
일반적인 파티션 방식에서는 디스크 구조를 변경하기가 상대적으로 어렵습니다.
반면 LVM을 사용하면 저장공간을 논리적인 볼륨으로 관리할 수 있습니다.
기본 구조는 다음과 같습니다.
Physical Disk
↓
Partition
↓
Physical Volume(PV)
↓
Volume Group(VG)
↓
Logical Volume(LV)
↓
Filesystem
↓
Mount Point
예를 들어 여러 디스크를 하나의 Volume Group으로 구성하고 필요한 만큼 Logical Volume을 만들어 사용할 수 있습니다.
LVM의 가장 큰 장점은 스토리지 관리의 유연성입니다.
예를 들어 /data 영역이 부족해졌다고 가정해 보겠습니다.
추가 디스크를 서버에 장착한 후 LVM 구조에 편입시키고 Logical Volume을 확장하여 공간을 늘리는 방식으로 운영할 수 있습니다.
대규모 서버 환경에서는 이런 유연성이 매우 중요합니다.
다만 LVM은 구조가 복잡해지는 만큼 PV, VG, LV의 관계를 정확하게 이해해야 합니다.
LVM 환경에서는 다음 명령어가 중요합니다.
Physical Volume 확인:
pvs
Volume Group 확인:
vgs
Logical Volume 확인:
lvs
상세한 구조를 확인하려면
lsblk
와 함께 사용하는 것이 좋습니다.
예를 들어 다음과 같은 구조를 볼 수 있습니다.
sdb
└─sdb1
└─vg_data-lv_data
이 경우 /dev/sdb1이 LVM의 PV로 사용되고 있으며 Logical Volume이 그 위에 구성되어 있다는 것을 알 수 있습니다.
Linux에서 파일시스템을 사용하려면 특정 디렉터리에 연결해야 합니다.
이 과정을 Mount라고 합니다.
예를 들어 새로운 데이터 디스크를 /data에 연결할 수 있습니다.
mount /dev/sdb1 /data
이후 /data에 파일을 생성하면 해당 파일시스템에 데이터가 저장됩니다.
마운트 상태는 다음 명령어로 확인할 수 있습니다.
mount
또는
findmnt
실무에서는 findmnt가 현재 파일시스템의 구조를 확인하는 데 매우 편리합니다.
서버를 재부팅하면 수동으로 실행했던 mount 설정이 사라질 수 있습니다.
따라서 부팅할 때 자동으로 파일시스템을 마운트하도록 /etc/fstab에 설정합니다.
예를 들어 다음과 같은 구조가 있을 수 있습니다.
UUID=xxxx-xxxx /data xfs defaults 0 0
여기서 중요한 점은 장치 이름보다 UUID를 사용하는 것이 일반적으로 더 안전하다는 것입니다.
디스크 장치 이름 /dev/sdb 등은 환경에 따라 변경될 가능성이 있기 때문입니다.
UUID는 다음과 같이 확인할 수 있습니다.
blkid
또는
lsblk -f
/etc/fstab은 서버 부팅 과정과 직접 관련되어 있기 때문에 잘못 설정하면 부팅에 문제가 발생할 수 있습니다.
따라서 설정을 변경한 뒤에는 반드시 테스트해야 합니다.
예를 들어 다음 명령어를 사용할 수 있습니다.
mount -a
오류가 발생하는지 확인합니다.
또한
findmnt
으로 실제 마운트 상태를 확인하는 것이 좋습니다.
운영 서버에서는 /etc/fstab을 수정하기 전에 반드시 기존 설정을 백업하는 습관을 들이는 것이 좋습니다.
디스크 용량이 충분한데도 파일을 생성할 수 없는 상황이 발생할 수 있습니다.
이때 확인해야 하는 것이 inode입니다.
Linux 파일시스템은 파일의 메타데이터를 관리하기 위해 inode를 사용합니다.
inode 사용량은 다음 명령어로 확인할 수 있습니다.
df -i
예를 들어
Filesystem Inodes IUsed IFree IUse%
/dev/sda2 65536 65520 16 100%
처럼 나온다면 디스크 공간이 남아 있더라도 새로운 파일을 생성하지 못할 수 있습니다.
작은 파일이 매우 많이 생성되는 시스템에서 특히 주의해야 합니다.
예를 들어 애플리케이션 로그나 임시 파일이 비정상적으로 많이 생성되면 inode가 빠르게 소진될 수 있습니다.
디스크 용량뿐만 아니라 디스크 성능도 중요합니다.
서버가 느려졌을 때 CPU 사용률과 메모리 사용량이 정상인데도 응답 속도가 느리다면 디스크 I/O가 병목일 가능성이 있습니다.
다음과 같은 도구를 사용할 수 있습니다.
iostat
일반적으로 sysstat 패키지에 포함되어 있습니다.
예를 들어
iostat -xz 1
을 이용하면 디스크 I/O 상태를 지속적으로 확인할 수 있습니다.
특히 다음과 같은 지표를 확인하는 것이 중요합니다.
util
await
r/s
w/s
rkB/s
wkB/s
디스크가 지속적으로 높은 사용률을 보이거나 await가 높다면 I/O 병목을 의심할 수 있습니다.
서버에서 디스크 문제가 발생하면 먼저 운영체제가 디스크를 정상적으로 인식하고 있는지 확인해야 합니다.
lsblk
다음으로 커널 로그를 확인합니다.
dmesg | tail -50
또는 시스템 로그를 확인합니다.
journalctl -k
디스크 오류와 관련된 메시지에는 다음과 같은 키워드가 나타날 수 있습니다.
I/O error
Buffer I/O error
reset
timeout
failed
filesystem error
이런 메시지가 반복적으로 발생한다면 단순한 파일 문제인지 물리 디스크 또는 스토리지 계층의 문제인지 구분해야 합니다.
운영 서버에서는 모든 데이터를 / 하나에 저장하는 것보다 서비스 특성에 따라 영역을 분리하는 것이 관리 측면에서 유리할 수 있습니다.
예를 들어 다음과 같은 구조를 생각할 수 있습니다.
/
├── boot
├── etc
├── var
├── home
├── data
└── backup
데이터베이스 서버라면 데이터 영역을 별도의 스토리지로 구성하는 방법도 고려할 수 있습니다.
예를 들어
/
/var
/data
/backup
등을 서비스 요구사항에 따라 분리할 수 있습니다.
이렇게 구성하면 특정 영역의 용량 증가가 다른 영역에 미치는 영향을 줄일 수 있습니다.
다만 무조건 많은 파티션을 만드는 것이 좋은 것은 아닙니다. 운영 환경과 서비스 특성에 맞춰 설계해야 합니다.
실제 운영 환경에서 매우 자주 발생하는 장애를 하나 살펴보겠습니다.
사용자로부터 다음과 같은 문의가 들어왔다고 가정합니다.
“웹 서버에 파일 업로드가 되지 않습니다.”
먼저 파일시스템 사용량을 확인합니다.
df -h
만약 /가 100%라면 어느 디렉터리가 용량을 사용하는지 확인합니다.
du -xhd1 / | sort -h
예를 들어 /var가 크다면 다시 확인합니다.
du -xhd1 /var | sort -h
그리고 /var/log가 크다면 로그 파일을 조사합니다.
du -sh /var/log/*
이 과정에서 중요한 것은 무작정 로그 파일을 삭제하는 것이 아니라 어떤 서비스가 로그를 비정상적으로 많이 생성했는지 원인을 먼저 확인하는 것입니다.
Linux 운영에서 상당히 중요한 장애 사례입니다.
어떤 대용량 로그 파일을 삭제했는데도 df -h의 사용량이 줄어들지 않는 경우가 있습니다.
프로세스가 삭제된 파일을 계속 열고 있기 때문입니다.
이 경우 다음 명령어를 사용할 수 있습니다.
lsof +L1
삭제되었지만 프로세스가 계속 열고 있는 파일을 확인할 수 있습니다.
이런 상황에서는 해당 파일을 사용하는 프로세스를 확인하고 서비스를 적절하게 재시작하거나 로그 처리 방식을 조정해야 합니다.
운영 서버에서 이 원리를 모르면 “파일을 삭제했는데 왜 디스크가 그대로인가?“라는 문제를 해결하지 못할 수 있습니다.
서버의 디스크를 관리할 때는 몇 가지 기본 원칙을 지켜야 합니다.
첫째, 장치 이름을 잘못 확인하지 않아야 합니다.
다음 명령어를 먼저 확인하는 습관을 들이는 것이 좋습니다.
lsblk
둘째, 운영 중인 파티션을 무작정 포맷하지 않아야 합니다.
mkfs
는 파일시스템을 생성하는 명령어이며 기존 데이터가 사라질 수 있습니다.
셋째, /etc/fstab을 수정할 때 주의해야 합니다.
잘못된 설정은 부팅 문제로 이어질 수 있습니다.
넷째, 디스크 장애가 의심되면 로그부터 확인해야 합니다.
dmesg
journalctl
다섯째, 중요한 데이터는 반드시 별도의 백업 정책을 가져야 합니다.
RAID는 백업이 아닙니다.
RAID는 디스크 장애에 대한 가용성을 높이는 기술이지 실수로 삭제한 파일이나 랜섬웨어까지 복구해 주는 백업 시스템은 아닙니다.
Linux 서버 운영에서 다음 명령어는 반드시 익혀두는 것이 좋습니다.
lsblk
df -h
df -i
du -sh
blkid
findmnt
mount
umount
fdisk
parted
pvs
vgs
lvs
iostat
dmesg
journalctl
lsof
각 명령어의 역할을 간단히 정리하면 다음과 같습니다.
|
명령어 |
주요 용도 |
|---|---|
|
lsblk |
디스크와 파티션 구조 확인 |
|
df |
파일시스템 사용량 확인 |
|
du |
디렉터리와 파일 용량 확인 |
|
df -i |
inode 사용량 확인 |
|
blkid |
UUID와 파일시스템 확인 |
|
findmnt |
마운트 구조 확인 |
|
mount |
파일시스템 마운트 |
|
umount |
파일시스템 언마운트 |
|
fdisk |
파티션 관리 |
|
parted |
파티션 관리 |
|
pvs |
LVM Physical Volume 확인 |
|
vgs |
LVM Volume Group 확인 |
|
lvs |
LVM Logical Volume 확인 |
|
iostat |
디스크 I/O 분석 |
|
dmesg |
커널 메시지 확인 |
|
journalctl |
시스템 로그 분석 |
|
lsof |
열린 파일 및 프로세스 확인 |
Linux 서버에서 디스크와 파일시스템 관리는 단순히 저장공간을 추가하는 작업이 아닙니다.
시스템 엔지니어는 다음과 같은 전체 구조를 이해해야 합니다.
물리 디스크
↓
파티션
↓
LVM
↓
Logical Volume
↓
파일시스템
↓
Mount
↓
디렉터리
↓
파일
그리고 장애가 발생했을 때는 다음과 같은 순서로 접근하는 것이 좋습니다.
1. df -h
↓
파일시스템 용량 확인
2. df -i
↓
inode 확인
3. du
↓
용량을 많이 사용하는 위치 확인
4. lsblk
↓
디스크 및 파티션 구조 확인
5. findmnt
↓
마운트 상태 확인
6. pvs / vgs / lvs
↓
LVM 구성 확인
7. iostat
↓
디스크 I/O 성능 확인
8. dmesg / journalctl
↓
커널 및 디스크 오류 확인
9. lsof
↓
삭제된 파일 또는 열린 파일 확인
이러한 과정을 반복해서 실습하면 단순한 Linux 명령어 암기를 넘어 실제 서버에서 발생하는 디스크 Full, inode 부족, 마운트 오류, LVM 용량 부족, 디스크 I/O 병목, 파일시스템 장애를 체계적으로 분석할 수 있게 됩니다.
특히 시스템 엔지니어에게 중요한 것은 “명령어를 알고 있다”는 것보다 왜 이 명령어를 실행하는지, 결과가 무엇을 의미하는지, 다음에 무엇을 확인해야 하는지를 판단하는 능력입니다.