리눅스 마운트 꿀팁: 재부팅했는데 마운트 포인트에 데이터가 없다면?

서버를 재부팅했는데 /data에 넣어 둔 데이터가 감쪽같이 사라졌다면 누구나 당황한다. 하지만 이런 경우 대부분은 데이터가 지워진 것이 아니다. 마운트(mount)가 제대로 되지 않아서, 지금 SSD가 아니라 루트 디스크 안의 빈 디렉터리를 보고 있는 것이다. 이 글에서는 리눅스 마운트의 기본 개념부터, 가려진 데이터를 확인하는 바인드 마운트, 이런 상황을 확인하고 해결하는 방법, 그리고 마운트 포인트에 데이터가 루트 디스크로 쓰이는 것을 막는 chattr +i 활용법까지 정리한다.

결론: 재부팅 후 데이터가 보이지 않으면 findmnt /data로 마운트부터 확인하자. 출력이 없다면 마운트가 안 된 것이고, 마운트 문제라면 SSD의 데이터는 그대로 있다.

 

1. 마운트(mount)란?

윈도우는 디스크마다 C:, D: 같은 드라이브 문자를 부여한다. 반면 리눅스는 최상위 루트 디렉터리(/) 하나에서 시작하는 단일 디렉터리 트리를 사용한다. 그래서 다른 저장 장치를 쓰려면 그 장치의 파일 시스템(file system)을 트리 안의 특정 디렉터리에 연결해야 한다.

• 마운트(mount)는 저장 장치의 파일 시스템을 디렉터리 트리에 연결하는 작업이다.
• 마운트 포인트(mount point)는 파일 시스템이 연결되는 디렉터리다. 예를 들어 /data에 SSD를 연결하면 /data가 마운트 포인트다.

 

2. 서버 구축 시 새 디스크는 반드시 마운트해야 한다

윈도우, 맥, 리눅스 데스크톱(GUI) 환경에서는 마운트를 몰라도 디스크를 쓸 수 있다. USB나 외장 SSD를 물리적으로 연결하면 장치 인식과 마운트까지 한 번에 자동으로 처리되기 때문이다. 윈도우는 드라이브 문자를 자동으로 부여하고, 맥은 /Volumes 아래에, 리눅스 데스크톱은 보통 /media 또는 /run/media 아래에 자동으로 붙여 준다. 마운트가 필요 없어진 것이 아니라, 운영체제가 사용자 대신 해 주고 있는 것이다.

참고: GUI 환경에서도 파티션과 파일 시스템이 없는 새 디스크는 자동으로 마운트되지 않는다. 윈도우는 디스크 관리, 맥은 디스크 유틸리티 같은 도구로 먼저 초기화(포맷)해야 사용할 수 있다.

반면 서버 같은 리눅스 CUI 환경은 GUI 없이 명령어로 운영하기 때문에 이런 자동 처리를 기대하기 어렵다. 디스크를 포트에 물리적으로 연결하면 리눅스는 장치를 인식하는 데까지만 해 준다. 인식된 장치는 /dev/sdb 같은 장치 파일로 나타나고 lsblk로 확인할 수 있지만, 마운트는 되지 않은 상태다. 인식과 마운트는 별개의 단계이므로, 마운트하기 전에는 디렉터리 트리 안에서 사용할 수 없고 반드시 직접 마운트를 해 줘야 한다.

lsblk
# NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
# sda      8:0    0 476.9G  0 disk
# └─sda1   8:1    0 476.9G  0 part /
# sdb      8:16   0 931.5G  0 disk              <- 새 SSD는 인식되었지만 MOUNTPOINTS가 비어 있음

핫플러그를 지원하지 않는 내장 디스크는 전원을 끄고 연결한 뒤 부팅하면 인식된다. 재부팅 후에도 같은 위치에 유지되게 하려면 fstab 등록까지 직접 해야 한다. 새 디스크를 서버에 붙이는 기본 흐름은 다음과 같다.

# 1) 장치 확인
lsblk
 
# 2) 파티션 생성 (fdisk 또는 parted)
sudo fdisk /dev/sdb
 
# 3) 파일 시스템 생성 (기존 데이터가 지워지므로 장치명 반드시 재확인)
sudo mkfs.ext4 /dev/sdb1
 
# 4) 마운트 포인트 생성
sudo mkdir -p /data
 
# 5) 마운트
sudo mount /dev/sdb1 /data
 
# 6) 확인
df -h /data

위처럼 수동으로 마운트하면 재부팅 후 사라진다. 부팅할 때마다 자동으로 마운트되게 하려면 /etc/fstab에 등록해야 한다. 장치 이름(/dev/sdb1)은 재부팅이나 디스크 추가 시 바뀔 수 있으므로 UUID로 등록하는 것이 안전하다.

# UUID 확인
sudo blkid /dev/sdb1
 
# /etc/fstab 에 추가
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /data  ext4  defaults,nofail  0  2
 
# fstab 문법 오류가 없는지 테스트 겸 적용
sudo mount -a

 

3. 사람들이 가장 많이 놓치는 함정

마운트 포인트는 마운트하지 않으면 그냥 평범한 디렉터리다.

마운트 포인트는 결국 루트 파일 시스템 위에 만들어 둔 디렉터리일 뿐이다. 그래서 마운트가 되어 있지 않으면 리눅스는 이 디렉터리를 다른 디렉터리와 똑같이 취급한다. 이런 상황이 실제로 자주 벌어진다.

• SSD 인식 실패나 fstab 오류로 마운트가 안 된 채 서버가 부팅되거나, 수동으로 umount한 뒤 다시 마운트하는 것을 잊은 채 서비스가 시작된다.
• DB, 도커, 로그, 백업 스크립트가 /data에 아무 경고 없이 쓰기를 시작한다.
• 데이터는 SSD가 아니라 루트 디스크에 쌓이고, 루트 용량이 가득 차서 서버 전체 장애로 번질 수 있다.
• 나중에 SSD를 마운트하면 그 위로 새 파일 시스템이 덮어씌워져, 그동안 쌓인 파일이 사라진 것처럼 보인다. 실제로 삭제된 것은 아니고 가려져 있을 뿐이며, 루트 디스크 용량은 계속 차지한다.

 

지금 이 경로가 실제로 마운트된 상태인지는 아래 명령어로 확인할 수 있다.

# 마운트 여부 확인 (출력이 없으면 마운트되지 않은 상태)
findmnt /data

# 마운트 포인트인지 직접 확인
mountpoint /data

# 이 경로가 어느 파일 시스템을 쓰고 있는지 확인
# (마운트가 안 되어 있으면 루트(/) 파일 시스템이 표시됨)
df -h /data

이미 마운트된 상태에서 SSD에 가려진 원래 디렉터리의 파일을 확인하는 방법은 다음 장에서 다룬다.

 

4. 바인드 마운트(bind mount)로 가려진 데이터 확인하기

앞 장에서 본 것처럼 마운트 포인트에 SSD가 마운트되면, 원래 그 디렉터리에 있던 루트 디스크 쪽 데이터는 가려진다. 이미 서비스가 SSD를 쓰고 있어서 umount를 하기 곤란할 때도 있다. 이럴 때는 마운트를 그대로 둔 채 바인드 마운트로 가려진 데이터를 확인할 수 있다.

리눅스는 자기 자신도 마운트할 수 있다. 루트 디스크(/)를 다른 디렉터리에 연결해서 한 번 더 볼 수 있다.

 

일반적인 마운트가 디스크 같은 장치를 디렉터리에 연결하는 것이라면, 바인드 마운트(bind mount)는 이미 존재하는 디렉터리를 다른 경로에 연결하는 것이다. 루트 디렉터리(/)를 다른 경로에 바인드 마운트하면 루트 파일 시스템이 그 경로에서도 똑같이 보인다.

# 1) 루트 디스크를 볼 경로를 만들고 바인드 마운트
sudo mkdir -p /mnt/rootfs
sudo mount --bind / /mnt/rootfs

# 2) SSD에 가려져 있던, 루트 디스크 쪽 /data 내용 확인
ls -la /mnt/rootfs/data

# 3) 이 데이터가 루트 디스크 용량을 얼마나 차지하는지 확인
du -sh /mnt/rootfs/data

# 4) 확인이 끝나면 반드시 해제
sudo umount /mnt/rootfs

 

이 방법이 통하는 이유는 --bind가 하위 마운트까지 따라오지 않기 때문이다. /data에 마운트된 SSD는 /mnt/rootfs 아래로 따라오지 않으므로, /mnt/rootfs/data는 SSD에 가려지기 전의 루트 디스크 쪽 /data 디렉터리를 그대로 보여 준다. 참고로 /data 자체를 du로 확인하면 SSD 기준 용량만 나오기 때문에, 마운트를 유지한 채 루트 디스크에 숨은 용량을 확인하려면 이 방법이 필요하다.

 

주의할 점

• --rbind는 하위 마운트까지 함께 연결하므로 SSD가 다시 보인다. 이 목적에는 --bind를 사용해야 한다.
• /mnt/rootfs 아래에서 파일을 지우면 실제 루트 디스크의 파일이 지워진다. 정리할 때는 경로를 정확히 확인하자.
• 확인이 끝나면 umount로 해제해 두어야 실수를 막을 수 있다.

바인드 마운트는 이 외에도 같은 디렉터리를 다른 경로에서 보이게 할 때 널리 쓰인다. 도커에서 호스트 디렉터리를 컨테이너에 연결하는 -v /호스트경로:/컨테이너경로 옵션이 대표적인 예다.

 

5. 재부팅했는데 마운트 포인트에 데이터가 없다면

3장에서는 마운트되지 않은 상태에서 쓰기가 루트 디스크로 새는 문제를 다뤘다. 같은 원인에서 나오는 또 다른 증상이 바로 이 글의 제목과 같은 상황이다. 재부팅 후 /data를 열었더니 분명 넣어 둔 데이터가 보이지 않는 경우다. 이때도 대부분은 데이터가 사라진 것이 아니다. 마운트가 제대로 되지 않아서, 지금 SSD가 아니라 루트 디스크 안에 있는 /data 디렉터리를 보고 있는 것이고, SSD의 데이터는 그대로 남아 있다.

데이터가 없다면 데이터를 의심하기 전에 마운트부터 확인하자.

 

확인 순서

# 1) 마운트 여부 확인 (출력이 없으면 마운트되지 않은 상태)
findmnt /data

# 2) 어떤 파일 시스템을 보고 있는지 확인
#    루트(/) 파일 시스템이 표시되면 마운트에 실패한 것
df -h /data

# 3) 디스크가 인식되었는지 확인
lsblk

# 4) 마운트 유닛의 상태와 오류 로그 확인
#    (경로가 /mnt/data 라면 유닛 이름은 mnt-data.mount)
systemctl status data.mount
sudo journalctl -b -u data.mount

 

자주 있는 원인

• fstab의 UUID가 틀렸거나, 디스크를 교체하거나 다시 포맷해서 UUID가 바뀐 경우
• 디스크가 인식되지 않은 경우 (케이블, 전원, BIOS 설정 문제 등)
• nofail 옵션 때문에 마운트에 실패해도 부팅이 그대로 진행된 경우
• 파일 시스템 손상 등으로 마운트에 실패한 경우

 

조치 방법

1. DB, 도커, 로그를 쓰는 서비스부터 중지한다. 마운트되지 않은 상태에서 계속 쓰면 루트 디스크에 데이터가 쌓인다.
2. 위 확인 순서로 원인을 찾아 해결한 뒤 sudo mount -a 또는 sudo mount /data로 마운트한다.
3. findmnt /data로 마운트 상태를 다시 확인한다. 데이터가 보이면 정상이다.
4. 마운트 전에 루트 디스크 쪽에 파일이 쌓였다면, 4장의 바인드 마운트 방식으로 확인한 뒤 필요한 것만 SSD로 옮기고 루트 쪽은 정리한다.

 

마운트가 정상인데도 데이터가 비어 있다면 그때 디스크나 파일 시스템 자체의 문제를 의심하면 된다. 또 다음 장에서 소개하는 chattr +i를 걸어 두면, 마운트가 안 된 상태에서 서비스가 조용히 루트 디스크에 쓰지 않고 오류를 내기 때문에 문제를 훨씬 빨리 알아챌 수 있다.

 

6. chattr +i 로 마운트 포인트에 루트 디스크 쓰기 차단하기

chattr +i는 마운트 실패를 막는 방법이 아니다. 마운트가 안 된 상태에서 마운트 포인트에 데이터가 마운트 디스크(SSD)가 아닌 루트 디스크에 쓰이는 것을 막는 방법이다.

 

마운트되지 않은 상태의 마운트 포인트 디렉터리에 불변 속성(immutable attribute)을 걸면, 이 속성이 걸린 디렉터리에는 root 사용자도 파일을 만들거나 지울 수 없다. 마운트가 풀린 상태에서 서비스가 실수로 쓰기를 시도해도 오류로 막히므로, 데이터가 루트 디스크에 조용히 쌓이는 일이 없다. 마운트가 실패하는 원인 자체는 그대로 남아 있으니, 오류가 났다면 5장의 확인 순서로 원인을 찾아 해결해야 한다.

 

주의: 속성을 거는 명령어는 chattr +i이고, chattr -i는 속성을 해제하는 명령어다. 헷갈리기 쉬우니 주의하자.

# 1) 반드시 마운트가 해제된 상태에서 진행
sudo umount /data

# 2) (혹시 쌓인 파일이 있다면 정리한 뒤) 불변 속성 설정
sudo chattr +i /data

# 3) 속성 확인 - 'i' 플래그가 보이면 성공
lsattr -d /data
# ----i---------e------- /data

# 4) 마운트 해제 상태에서 쓰기 시도 -> 차단됨
touch /data/test
# touch: cannot touch '/data/test': Operation not permitted

# 5) 다시 마운트하면 SSD에는 정상적으로 쓰기 가능
sudo mount /data     # fstab에 등록되어 있는 경우
touch /data/test

 

마운트하면 정상적으로 쓸 수 있는 이유는 간단하다. 불변 속성은 아래에 깔려 있는 루트 파일 시스템의 /data 디렉터리에 걸려 있고, 마운트하면 그 위에 SSD 파일 시스템의 루트 디렉터리가 덮어씌워지기 때문이다. SSD 쪽 디렉터리에는 이 속성이 없으므로 평소처럼 읽고 쓸 수 있다.

 

알아둘 점

• 속성은 반드시 마운트가 해제된 상태에서 걸어야 한다. 마운트된 상태에서 걸면 아래 디렉터리가 아니라 SSD 파일 시스템의 루트 디렉터리에 걸린다.
• 불변 속성이 걸린 디렉터리는 이름 변경이나 삭제(rmdir)도 되지 않는다. 마운트 포인트를 실수로 지우는 것도 함께 막아 준다.
• 해제하려면 마운트를 푼 상태에서 sudo chattr -i /data를 실행한다.
• 루트 파일 시스템이 ext4, XFS, Btrfs처럼 chattr 속성을 지원하는 종류여야 하고, 설정에는 root 권한이 필요하다.

 

7. 함께 알아두면 좋은 팁

• fstab에 nofail 옵션을 주면 디스크가 없거나 마운트에 실패해도 부팅이 계속 진행된다. nofail이 없으면 마운트 실패 시 부팅이 긴급 모드(emergency mode)로 빠질 수 있다. 대신 서비스가 마운트 안 된 경로에 쓰는 위험이 생기므로 chattr +i와 짝으로 쓰면 좋다.
• systemd 서비스라면 유닛 파일의 [Unit] 섹션에 RequiresMountsFor=/data를 지정해 두자. 해당 경로가 마운트된 뒤에만 서비스가 시작된다.
• fstab을 수정한 뒤에는 재부팅하기 전에 sudo mount -a로 오류가 없는지 먼저 확인하는 습관을 들이자.

 

정리

• 마운트는 리눅스를 다룬다면 반드시 알아야 하는 개념이다.
• 윈도우, 맥, 리눅스 GUI 환경에서는 디스크를 물리적으로 연결하면 장치 인식과 마운트가 한 번에 자동으로 처리된다.
• 반면 리눅스 CUI 환경(서버)에서는 반드시 직접 마운트를 해 줘야 한다. 서버 구축 시 SSD 같은 새 저장 장치를 연결했다면 파티션, 파일 시스템 생성, 마운트, fstab 등록까지 직접 해야 비로소 사용할 수 있다.
• 마운트 포인트는 마운트되지 않으면 일반 디렉터리와 똑같이 동작하므로, 데이터가 엉뚱한 곳(루트 디스크)에 쌓일 수 있다.
• 이미 마운트 중인 상태에서 SSD에 가려진 루트 디스크 쪽 데이터를 보고 싶다면, 리눅스가 자기 자신(/)도 마운트할 수 있다는 점을 이용해 루트 디스크를 바인드 마운트해서 확인한다.
• 재부팅 후 마운트 포인트에 데이터가 없다면 데이터가 사라진 것이 아니라 마운트가 안 되어 루트 디스크의 디렉터리를 보고 있는 것일 수 있으니, 가장 먼저 마운트 상태를 확인한다.
• 마운트가 안 된 상태의 마운트 포인트에 chattr +i를 걸어 두면 마운트 디스크가 아닌 루트 디스크에 데이터가 쓰이는 것을 막을 수 있다. 마운트 실패 자체를 막는 방법은 아니므로, 오류가 나면 원인을 찾아 해결해야 한다.