지난 회차에서 우리는 파일 시스템 내부를 정밀하게 추적하는 find 명령어와 시스템 파일의 변조 여부를 과학적으로 증명하는 sha256sum 무결성 검증 기술에 대해 알아보았습니다. 시스템 내부의 주요 자원을 식별하고 안전성을 확보했다면, 이제는 인프라 운영의 영원한 숙제인 '데이터 백업과 전송 효율화'를 위한 파일 아카이브 및 압축 기술을 마스터할 차례입니다.
리눅스 서버 환경에서는 무수한 로그 파일, 개발 소스코드, 데이터베이스 덤프 파일이 매일같이 쏟아집니다. 이 파일들을 개별적으로 보관하거나 네트워크를 통해 원격지 서버로 전송하는 것은 대단히 비효율적입니다. 파일 하나를 전송할 때마다 파일 시스템 인덱싱과 네트워크 세션 연결 비용이 발생하기 때문입니다.
따라서 수많은 파일을 하나로 묶어주는 아카이브(Archive) 기술과, 데이터의 크기를 줄여주는 압축(Compression) 기술을 유기적으로 결합하여 다룰 줄 알아야 합니다. 이번 12회차에서는 리눅스 데이터 관리의 표준 도구인 tar 명령어의 메커니즘과 실무 백업 예제를 상세히 살펴보겠습니다.
초보 엔지니어들이 가장 많이 겪는 혼선 중 하나는 '묶는 것'과 '압축하는 것'을 동일하게 생각하는 점입니다. 리눅스 환경에서는 두 행위가 명확하게 분리되어 작동합니다.
아카이브(Archive): 수많은 파일과 디렉토리 구조, 소유권, 권한 등의 메타데이터를 그대로 유지하면서 단 하나의 파일로 덩어리째 묶는 행위를 뜻합니다. 용량은 줄어들지 않습니다. 리눅스의 표준 도구는 tar입니다.
압축(Compression): 압축 알고리즘을 적용하여 파일 내부의 중복 데이터를 제거하고 물리적인 용량을 줄이는 행위를 뜻합니다. 리눅스의 대표적 도구로 gzip, bzip2, xz 등이 있습니다.
실무에서는 tar 명령어가 이 두 가지 과정을 옵션 하나로 동시에 처리해 주기 때문에, 대개 tar를 이용해 '아카이브와 압축'을 한 번에 수행합니다.
tar(Tape Archive) 명령어는 과거 테이프 백업 장치에 파일을 저장하던 시절부터 이어져 온 역사 깊은 도구입니다. 대시(-) 기호 없이 옵션을 붙여 써도 작동하는 독특한 문법 구조를 가지고 있습니다.
c (Create): 새로운 아카이브(.tar) 파일을 생성합니다.
x (eXtract): 기존 아카이브 파일의 묶음을 해제하거나 압축을 풉니다.
t (List): 아카이브를 풀지 않고, 내부에 어떤 파일들이 들어있는지 목록만 확인합니다.
v (Verbose): 작업 진행 과정을 화면에 실시간으로 상세히 출력합니다.
f (File): 반드시 지정해야 하는 옵션으로, 아카이브 파일의 이름을 정의합니다. 이 옵션 바로 뒤에는 항상 결과물 파일명이 와야 합니다.
어떤 압축 도구를 연계할지에 따라 확장자와 서버 자원 소모율이 달라집니다.
| 옵션 | 연계 알고리즘 | 결과 확장자 | 특징 |
z |
gzip | .tar.gz / .tgz |
압축 속도가 매우 빠르고 자원을 적게 소모함 (실무 표준) |
j |
bzip2 | .tar.bz2 |
gzip보다 압축률이 우수하지만, 연산 시간이 조금 더 걸림 |
J |
xz | .tar.xz |
최상의 압축률을 자랑하나, 압축 시 CPU 자원을 많이 소모함 |
-czvf)운영 중인 웹 서비스 디렉토리 /var/www/myapp 전체를 가장 범용적인 gzip 알고리즘을 사용해 하나의 파일로 압축 백업하는 상황입니다.
Bash
# /backup 디렉토리에 오늘 날짜 명칭으로 웹 소스 아카이브 압축 파일 생성
tar czvf /backup/myapp_backup_20260624.tar.gz /var/www/myapp
실무 팁: 옵션을 조합할 때 f 옵션은 반드시 파일명 바로 앞에 와야 하므로 czvf 또는 zcvf 형태로 쓰는 것이 정석입니다. czfv와 같이 쓰면 v를 파일 이름으로 인식하여 에러가 발생합니다.
-xzvf와 -C)원격지 서버나 백업 스토리지로부터 전달받은 .tar.gz 파일의 압축을 해제하되, 현재 위치가 아닌 특정 타깃 디렉토리(/data/deploy)를 강제 지정하여 안전하게 소스를 복원하는 시나리오입니다.
Bash
# -C (Change directory) 옵션을 사용하여 목적지 경로를 변경 후 압축 해제
tar xzvf myapp_backup_20260624.tar.gz -C /data/deploy/
주의점: tar는 기본적으로 절대 경로의 맨 앞 슬래시(/)를 제거하고 압축을 묶습니다. 이를 '상대 경로 전환'이라고 하는데, 압축을 풀 때 현재 엉뚱한 디렉토리의 파일들을 덮어쓰는 대형 참사를 방지하기 위한 커널 수준의 안전장치입니다.
-tvf)수십 기가바이트(GB)에 달하는 백업 파일의 압축을 무작정 풀었다가 디스크 용량이 고갈되는 낭패를 볼 수 있습니다. 압축을 풀기 전, 내부에 내가 찾고자 하는 설정 파일이 제대로 들어있는지 목록만 안전하게 선별 검증하는 기법입니다.
Bash
# 압축을 풀지 않고 내부 리스트만 추출하여 grep으로 특정 파일 구비 여부 확인
tar tvf myapp_backup_20260624.tar.gz | grep "config.env"
대용량 데이터베이스 덤프 파일(.sql)이나 텍스트 로그 파일의 경우, 장기 보관 목적으로 디스크 공간을 극한으로 아껴야 할 때가 있습니다. 이때는 속도가 조금 느리더라도 압축률이 압도적인 xz 알고리즘(J 옵션)을 사용하는 것이 좋습니다.
Bash
# 1. xz 알고리즘을 적용하여 초고압축 아카이브 파일 생성
tar Cjvf /backup/db_huge_dump.tar.xz /data/db/
# 2. xz 압축 아카이브 해제
tar Xjvf /backup/db_huge_dump.tar.xz -C /data/restore/
비교 성능: 동일한 10GB 텍스트 데이터를 압축할 때, gzip이 용량을 2GB로 줄인다면 xz는 1GB 미만으로 줄여줄 수 있습니다. 단, 인프라 운영 중 CPU 사용률이 이미 높은 피크 시간대에는 xz 압축이 서버에 부담을 줄 수 있으므로 야간 배치를 통해 수행하는 것이 현명합니다.
증분 백업(Incremental Backup) 검토:
매번 전체 디렉토리를 통째로 tar 압축하면 백업 스토리지 낭비가 심해집니다. tar 명령어의 --listed-incremental 옵션을 사용하면 변경된 파일만 골라내어 백업하는 효율적인 백업 파이프라인을 구축할 수 있습니다.
백업 파일 이름 규칙 자동화:
파일명에 날짜와 시간이 자동으로 들어가도록 셸 스크립트를 자산화해야 관리의 연속성이 보장됩니다.
Bash
# 스크립트 내부 적용 예시
BACKUP_DATE=$(date +%Y%m%d_%H%M%S)
tar czvf /backup/log_${BACKUP_DATE}.tar.gz /var/log/nginx/
무결성 검증 결합:
압축이 완료된 뒤에는 반드시 지난 회차에서 배운 해시 함수를 이용해 지문 파일을 함께 생성해 두십시오. 나중에 복원할 때 압축 파일 자체의 깨짐(Corruption) 여부를 즉각 판별할 수 있습니다.
리눅스 시스템 인프라의 영속성을 수호하고 재해 복구(DR) 체계를 확립하기 위해서는 파일 묶음과 압축 메커니즘을 자유자재로 통제할 수 있어야 합니다.
대용량 폴더 구조와 메타데이터를 원본 그대로 유지하며 묶을 때는 tar를 전면에 가동하고,
일반적인 웹 소스 배포 및 빠른 전송 속도가 필요할 때는 범용적인 gzip (z) 옵션을 조합하며,
장기 보관용 로그나 스토리지 절약이 극단적으로 요구될 때는 CPU 자원을 투자하여 최상의 압축률을 내는 xz (J) 알고리즘을 배치해야 합니다.
압축 해제 전에는 언제나 -tvf로 안전지대를 확보하는 습관을 지녀야 합니다.
이 아카이브 및 압축 기술을 능숙하게 구사하게 되면 대규모 인프라 이전, 동적 소스 배포, 그리고 정교한 데이터 백업 스크립트 설계를 완벽하게 주도할 수 있습니다. 다음 13회차에서는 이러한 일련의 점검 작업과 백업 명령들을 엔지니어가 매번 수동으로 입력하지 않고, 커널이 정해진 시간과 주기에 맞춰 스스로 실행하도록 만드는 '인프라 자동화의 핵심 비서, Crontab 스케줄러 정복' 기술에 대해 자세히 알아보겠습니다.