동일한 용량의 NVMe 드라이브(256GB)에 실제 사용 데이터가 약 8GB임에도 불구하고, Macrium Reflect 같은 툴로 백업했을 때 백업 파일 크기가 어떤 서버는 10GB, 어떤 서버는 120GB나 되는 현상은 파일 시스템 구조, 디스크의 사용 상태, 압축 효율, 빈 블록의 처리 방식 등 여러 요인에 의해 발생한다.
목차
파일 시스템의 차이 (ext4, xfs, btrfs 등)
Reflect는 섹터 단위로 이미지를 생성하기 때문에, 사용 데이터만 복사하는 것이 아니라 파일 시스템의 메타데이터나 예약 영역도 포함될 수 있다.
- 예시:
ext4는 기본적으로 디스크의 약 5%를 예약 블록으로 할당한다.xfs는 메타데이터가 많이 분산되어 있어 압축 효율이 낮을 수 있다.
➡️ 즉, 파일 시스템 종류와 설정에 따라 “실제 사용량 8GB”라도 백업 이미지에서 차이가 발생한다.
빈 블록(Zero Block) 처리 방식
Reflect는 백업 시 빈 섹터(값이 0인 블록)를 자동으로 감지해 스킵하거나 압축한다.
- 어떤 서버에서는 Reflect가 TRIM/UNMAP 명령을 통해 “빈 섹터”로 인식한 부분을 제외할 수 있음.
- 하지만 다른 서버에서는 SSD 컨트롤러나 커널 설정 문제로 빈 섹터를 사용 중으로 인식할 수 있다.
➡️ 결과적으로 “사용량은 8GB로 보이지만 실제 백업에서는 120GB의 섹터가 복제”되는 상황이 생긴다.
압축 옵션 차이
Reflect의 백업 설정에서 압축 수준(없음 / 중간 / 고압축)에 따라 결과가 달라진다.
- 고압축: 8GB 사용 시 약 6~9GB 정도의 이미지 예상
- 압축 없음: 동일한 데이터라도 1:1 섹터 이미지로 생성되어 수십 GB 가능
➡️ 서버별로 Reflect 설정(압축, 스냅샷 모드 등)이 다르다면 크기가 크게 달라질 수 있다.
스왑(Swap), 로그, 임시 파티션 포함 여부
Reflect가 전체 디스크 백업(디스크 이미지) 으로 동작한다면, /swap, /var/log, /tmp, 심지어 /boot 영역까지 포함한다.
- 한 서버에서는 swap이 8GB이지만 실제로 거의 비어 있어서 압축 후 0.5GB 정도만 됨.
- 다른 서버에서는 swap이나 log 파티션이 남은 공간까지 쓰레기 데이터(garbage data)로 채워져 압축 효율이 매우 낮음.
➡️ 따라서 두 서버 모두 “사용 데이터 8GB”처럼 보여도, 백업 시 swap/log에 따라 100GB 이상 차이 날 수 있다.
TRIM / UNMAP 수행 여부
Reflect가 백업 전, SSD에서 TRIM이 제대로 수행되지 않은 상태라면, 비어 있는 블록이 실제로는 쓰레기 값으로 남아 있는 공간으로 인식된다.
fstrim -av명령으로 수동 TRIM 수행 후 다시 백업하면, 크기가 확 줄어드는 경우가 많다.
요약 정리
| 원인 | 백업 크기 증가 요인 | 해결 방법 |
|---|---|---|
| 파일시스템 메타데이터 | 예약 블록, inode 정보 | 예약 블록 조정 (tune2fs -m 0 /dev/nvme0n1pX) |
| 빈 섹터 인식 불가 | TRIM 미적용 | fstrim -av 실행 후 백업 |
| 압축 설정 차이 | 압축 미적용 또는 낮음 | Reflect 압축 옵션 “고압축” 사용 |
| Swap/Log 포함 | 불필요한 파티션 포함 | 파티션 단위 백업 설정 |
| SSD 컨트롤러 문제 | Zero-block 최적화 미지원 | Reflect에서 “Intelligent sector copy” 옵션 활성화 |
원하신다면, 네가 실제 사용하는 Reflect 백업 옵션(예: “Intelligent sector copy”, “Auto verify”, 압축 수준 등)을 알려주면 구체적으로 어떤 조합에서 크기 차이가 발생했는지 더 정확히 분석해줄 수 있다.
Reflect 백업 시 어떤 설정으로 실행했는지 알려줄 수 있을까?
fstrim -av 명령은 리눅스에서 SSD의 미사용(빈) 블록을 실제로 정리하는 명령어다.
좀 더 구체적으로 설명하면, 파일 시스템이 “삭제되었다”고 표시한 공간을 SSD 컨트롤러에게 “이 부분은 진짜로 비어 있다”고 알려주는 작업을 수행한다.
명령어 구조 분석
fstrim -av
fstrim: TRIM 명령을 실행하는 도구 (파일시스템 수준에서 SSD에게 빈 블록을 통보)-a: 모든 마운트된 파일시스템에 대해 TRIM 수행-v: verbose 모드, 즉 얼마나 많은 데이터가 해제되었는지 출력
예시 출력:
/: 5.8 GiB (6233645056 bytes) trimmed on /dev/nvme0n1p2
/boot: 23.5 MiB (24674304 bytes) trimmed on /dev/nvme0n1p1
⚙️ 동작 원리 요약
- 리눅스에서 파일을 삭제하면 실제로 데이터는 지워지지 않고 파일시스템의 메타데이터에서만 ‘삭제됨’으로 표시된다.
- SSD 입장에서는 그 공간이 여전히 데이터가 있는 블록으로 보인다.
fstrim을 실행하면 커널이 SSD 컨트롤러에게 “이 블록들은 진짜로 비어 있음”을 알려준다.- SSD는 해당 블록을 완전히 초기화하고, 이후 백업 도구(예: Reflect)는 이 영역을 0으로 인식하거나 스킵할 수 있게 된다.
백업과의 관계
Reflect 같은 백업 프로그램이 섹터 단위 이미지를 만들 때,
- TRIM이 수행되지 않은 SSD는 삭제된 파일의 흔적 데이터를 그대로 포함하므로 백업 용량이 커진다.
- TRIM을 수행하면 빈 섹터들이 “제로 블록(0-filled)”로 인식되어 백업 시 압축률이 급격히 향상된다.
따라서, 백업 전에 아래 순서로 작업하면 효율적이다:
sudo fstrim -av
# 이후 Reflect 백업 실행- 대부분의 최신 리눅스 배포판에서는
fstrim이 자동으로 주 1회 systemd 타이머(fstrim.timer) 를 통해 수행된다.
확인 명령:systemctl status fstrim.timer - 수동으로 수행하는 것은 대규모 파일 삭제 후나 백업 전이 특히 유용하다.