개발자 루카의 3-2-1 백업: 외장하드와 NAS로 개인 데이터 지키기 (feat. 시행착오)

안녕하세요, IT와 테크 지식을 공부하고 기록하는 루카(Luka)입니다.

제 인생에서 가장 아찔했던 순간 중 하나는 갓 졸업한 신입 시절, 수년간 작업했던 개인 프로젝트 파일들이 담긴 외장하드가 갑자기 인식 불능 상태가 되었을 때였습니다. 다행히 복구 업체에 맡겨 80% 정도는 건졌지만, 그 과정에서 겪었던 정신적 스트레스와 금전적 손실은 다시는 경험하고 싶지 않은 기억입니다. 그때부터 "데이터는 자산이다!"라는 생각으로 3-2-1 백업 전략을 맹신하게 되었고, 이 지옥 같은 경험이 저를 오늘 이 글을 쓰게 만들었습니다.

오늘은 제가 직접 외장하드와 NAS를 구축하고, 클라우드 서비스를 연동하며 겪었던 시행착오와 그 과정에서 얻은 실질적인 팁들을 바탕으로 '개인 데이터 3-2-1 백업 전략 가이드'를 공유해 보려 합니다. 단순히 이론적인 설명이 아니라, 제가 직접 부딪히고 해결했던 경험들이 여러분의 소중한 데이터를 지키는 데 도움이 되기를 바랍니다.

왜 3-2-1 백업인가? 저의 아찔했던 경험

제가 겪었던 데이터 손실 사건은 단순한 하드웨어 고장 때문이었습니다. 하지만 랜섬웨어, 실수로 인한 삭제, 자연재해(화재, 침수), 도난 등 데이터 손실을 유발하는 요인은 너무나 많습니다. "하나의 복사본은 존재하지 않는 것과 같다"는 말처럼, 중요한 데이터는 여러 곳에 분산하여 저장해야 합니다.

3-2-1 백업 전략은 이 원칙을 가장 효과적으로 구현하는 방법으로 알려져 있습니다:

3개의 데이터 복사본: 원본 데이터 외에 최소 2개의 백업본을 만듭니다.
2가지 다른 저장 매체: 서로 다른 종류의 저장 장치에 보관합니다 (예: 내장 HDD/SSD, 외장 HDD, NAS, 클라우드).
1개의 원격지 백업본: 물리적으로 떨어진 다른 장소에 최소 1개의 백업본을 보관합니다.

이 전략을 따름으로써 저는 하드웨어 고장, 집안 화재, 랜섬웨어 감염 등 어떤 재앙에도 데이터를 안전하게 보호할 수 있다는 확신을 갖게 되었습니다. 이제 제가 어떻게 이 전략을 제 환경에 맞춰 구축했는지 단계별로 설명해 드릴게요.

Step 1: 외장하드를 활용한 로컬 백업 (가장 기본적인 첫걸음)

3-2-1 백업의 첫 단계는 원본 데이터 외에 두 번째 데이터 복사본을 로컬에 보관하는 것입니다. 저는 주로 업무용 노트북과 개인 데스크톱을 사용하는데, 이 데이터들을 주기적으로 외장하드에 백업하고 있습니다.

저의 구성: * 메인 PC (Windows 11) / MacBook Pro (macOS Sonoma) * 외장하드: WD My Passport 4TB (USB 3.0) 2개 (하나만 쓰면 안 됩니다!)

처음에는 단순히 파일 탐색기로 드래그 앤 드롭 방식을 사용했습니다. 하지만 변경된 파일만 동기화하고, 원본에서 삭제된 파일을 백업에서도 삭제하는 등의 복잡한 작업을 수동으로 하려니 시간도 오래 걸리고 실수할 확률도 높았습니다. 그래서 저는 스크립트 기반의 자동화를 선택했습니다.

제가 직접 설정해 본 백업 스크립트 (macOS/Linux - rsync):

#!/bin/bash

SOURCE_DIR="/Users/luka/Documents/Projects/"
TARGET_DIR="/Volumes/LukaBackupDrive/Projects_Backup/"
LOG_FILE="/Users/luka/logs/backup_projects_$(date +%Y%m%d_%H%M%S).log"

echo "=== 백업 시작: $(date) ===" > "$LOG_FILE"
echo "원본 디렉토리: $SOURCE_DIR" >> "$LOG_FILE"
echo "대상 디렉토리: $TARGET_DIR" >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

# rsync 명령 실행 (변경 사항만 동기화, 원본에 없는 파일은 대상에서도 삭제)
rsync -avh --delete --stats "$SOURCE_DIR" "$TARGET_DIR" 2>&1 | tee -a "$LOG_FILE"

if [ $? -eq 0 ]; then
    echo "=== 백업 성공: $(date) ===" >> "$LOG_FILE"
else
    echo "=== 백업 실패: $(date) ===" >> "$LOG_FILE"
    echo "자세한 내용은 $LOG_FILE 파일을 확인하세요." >> "$LOG_FILE"
fi

echo "백업 로그 파일: $LOG_FILE"

실행 결과 예시:

$ bash ~/scripts/backup_projects.sh
백업 로그 파일: /Users/luka/logs/backup_projects_20240726_103000.log

$ cat /Users/luka/logs/backup_projects_20240726_103000.log
=== 백업 시작: 금 7월 26 10:30:00 KST 2024 ===
원본 디렉토리: /Users/luka/Documents/Projects/
대상 디렉토리: /Volumes/LukaBackupDrive/Projects_Backup/

sending incremental file list
./
project_A/
project_A/main.py
project_A/requirements.txt
project_B/
project_B/data.csv
deleting old_project_files/

Number of files: 213 (delta 5)
Number of created files: 0
Number of deleted files: 1
Number of regular files transferred: 2 (delta 2)
Total file size: 1.25G (delta 15.3M)
Literal data: 15.3M
Matched data: 0
File list size: 4.88K
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 15.3M
Total bytes received: 212

sent 15.3M bytes  received 212 bytes  1.56M bytes/sec
total size is 1.25G  speedup is 81.99
=== 백업 성공: 금 7월 26 10:30:01 KST 2024 ===

설명: rsync -avh --delete --stats 명령어를 사용해 원본(SOURCE_DIR)과 대상(TARGET_DIR)을 동기화합니다. -a는 아카이브 모드로 권한, 시간 정보 등을 보존하고, -v는 자세한 진행 상황을, -h는 용량을 사람이 읽기 쉽게 표시합니다. --delete는 원본에 없는 파일을 대상에서도 삭제하므로 주의해서 사용해야 합니다. 첫 500GB 초기 백업 시 약 4시간이 소요되었고, 이후 매일 10GB 내외의 변경 데이터는 위 예시처럼 1~2분 이내에 동기화됩니다.

저의 시행착오: 처음엔 외장하드를 하나만 사용했습니다. 하지만 그 외장하드마저 고장 나면 3-2-1 전략이 깨진다는 것을 깨닫고, 같은 데이터를 백업할 외장하드를 2개 구매해 번갈아 사용하거나, 하나는 주 백업, 다른 하나는 중요한 데이터만 선별하여 보관하는 방식으로 변경했습니다. 또한, --delete 옵션을 잘못 사용하여 중요한 파일을 날릴 뻔한 경험이 있어, 스크립트 실행 전 dry-run 옵션(-n)으로 미리 결과를 확인하는 습관을 들였습니다.

Step 2: NAS 구축으로 로컬 이중화 및 접근성 확보

로컬 외장하드 백업은 간편하지만, 수동으로 연결하고 실행해야 한다는 단점이 있습니다. 또한, 항상 켜져 있는 것은 아니므로 실시간 백업이 어렵고, 가족 구성원과 데이터를 공유하기도 불편합니다. 그래서 저는 3-2-1 백업의 세 번째 데이터 복사본과 두 번째 저장 매체(네트워크 저장 장치)를 위해 NAS(Network Attached Storage)를 구축했습니다.

저의 NAS 구성: * NAS: Synology DS920+ * HDD: Western Digital Red Plus 4TB 2개 (RAID1 구성) * 네트워크: 1Gbps 유선 LAN (Cat.6 케이블 사용)

NAS 구축은 처음에는 비용 부담이 있었지만, 데이터 접근성, 안정성, 확장성을 고려했을 때 장기적으로는 훨씬 효율적인 선택이라고 생각합니다. 특히 RAID1로 구성하면 하나의 하드디스크가 고장 나도 데이터를 안전하게 보존할 수 있어 심리적 안정감이 큽니다.

NAS로의 자동 백업 설정 (macOS/Linux - crontab): 저는 NAS를 네트워크 드라이브로 마운트한 뒤, crontab을 이용해 매일 새벽에 자동으로 백업이 실행되도록 설정했습니다.

# rsync_to_nas.sh 스크립트 내용 (위의 rsync 스크립트와 유사)
#!/bin/bash
SOURCE_DIR="/Users/luka/ImportantFiles/"
TARGET_DIR="/Volumes/LukaNAS/Backup_LukaImportantFiles/" # NAS 마운트 경로
LOG_FILE="/Users/luka/logs/nas_backup_$(date +%Y%m%d_%H%M%S).log"
# ... rsync 명령 및 로그 부분은 Step 1과 동일 ...

crontab 설정:

$ crontab -e # 편집기에서 다음 줄 추가

# 매일 새벽 3시 30분, NAS로 중요한 폴더 백업
30 3 * * * /bin/bash /Users/luka/scripts/rsync_to_nas.sh >> /Users/luka/logs/cron_rsync_output.log 2>&1

설명: 위 설정은 매일 새벽 3시 30분에 /Users/luka/scripts/rsync_to_nas.sh 스크립트를 실행하고, 그 결과를 /Users/luka/logs/cron_rsync_output.log 파일에 기록합니다.

저의 시행착오: * 네트워크 속도 문제: 처음에는 오래된 Cat5 케이블을 사용했는데, NAS로 1TB 데이터를 초기 백업하는 데 무려 15시간 이상이 걸렸습니다. 파일 전송 속도가 20MB/s를 넘지 못했죠. Cat6 케이블로 교체하고 나니 전송 속도가 110MB/s 이상으로 안정화되었고, 동일한 1TB 백업이 약 2시간 30분으로 줄었습니다. (이후 NAS의 Link Aggregation을 설정하여 대역폭을 2Gbps로 늘리면서 이론상으로는 더 빨라졌지만, 실제 단일 연결 전송은 크게 차이 없었습니다.) * 권한 문제: NAS 공유 폴더에 쓰기 권한이 없어 백업 스크립트가 계속 실패했습니다. NAS 관리자 페이지에서 제 계정에 해당 폴더에 대한 읽기/쓰기 권한을 명확히 부여하고 나서야 문제가 해결되었습니다. * 스마트폰 사진 백업: Synology Moments (현재 Photos) 앱을 사용하니 스마트폰 사진이 자동으로 NAS로 백업되어 편리합니다. 약 200GB의 사진/영상 데이터가 초기 동기화되는 데 약 20시간이 걸렸습니다.

외장하드 vs. NAS 비교표:

특징	외장하드	NAS (네트워크 저장 장치)
비용	저렴 (하드디스크 가격 + 케이스)	초기 비용 높음 (NAS 본체 + 하드디스크)
편의성	수동 연결 필요, 이동성 좋음	네트워크 연결 시 항시 접근 가능, 자동화 용이
접근성	연결된 기기에서만 접근	네트워크 내 모든 기기에서 접근, 외부 접근 가능 (DDNS 등)
안정성	단일 드라이브 고장 시 데이터 손실 위험 높음	RAID 구성으로 하드웨어 고장 대비 가능, 이중화/삼중화 가능
확장성	제한적 (단일 드라이브 또는 허브 사용)	베이 추가, 볼륨 확장 등 유연한 확장 가능
백업 용도	개인 로컬 백업, 이동식 저장	상시 자동 백업, 중앙 집중식 파일 서버, 미디어 서버

Step 3: 클라우드를 활용한 원격지 백업 (재난 대비의 마지막 보루)

3-2-1 전략의 마지막, 그리고 가장 중요한 단계는 원격지 백업입니다. 로컬에 아무리 백업을 잘 해두었어도, 화재, 도난, 침수와 같은 물리적인 재난이 발생하면 모든 데이터가 사라질 수 있습니다. 저는 이 문제를 해결하기 위해 클라우드 서비스를 활용하고 있습니다.

저의 클라우드 서비스 선택: Backblaze B2 (S3 호환 오브젝트 스토리지)

처음에는 Google Drive, Dropbox 같은 일반 클라우드 드라이브를 고려했지만, 대용량 데이터를 장기간 보관하는 비용이 만만치 않았습니다. Backblaze B2는 테라바이트(TB) 단위의 데이터를 저렴하게 보관할 수 있어 저의 목적에 가장 부합했습니다.

NAS에서 Backblaze B2로 백업 설정: 저는 Synology NAS의 기본 앱인 Hyper Backup을 사용하여 NAS 데이터를 Backblaze B2로 백업하고 있습니다.

Hyper Backup 설치 및 실행: 패키지 센터에서 Hyper Backup을 설치합니다.
데이터 백업 작업 생성: "데이터 백업 작업 생성"을 선택하고 "S3 Storage"를 선택합니다.
서비스 제공자 선택: "Backblaze B2"를 선택하고, Endpoint (예: s3.us-west-001.backblazeb2.com), Access Key ID, Secret Access Key를 입력하여 연결합니다. (B2 웹사이트에서 API 키 생성 필요)
백업 소스 및 스케줄 설정: NAS의 어떤 공유 폴더를 백업할지 선택하고, 매일 새벽에 증분 백업을 수행하도록 스케줄을 설정합니다.
버전 관리 및 압축/암호화: 저는 실수로 인한 파일 삭제에 대비하여 30일간의 버전 관리를 설정하고, 보안을 위해 클라이언트 측 암호화를 활성화했습니다.

저의 시행착오: * API 키 관리: Backblaze B2의 API 키를 잘못 생성하거나 권한 설정을 제대로 하지 않아 연결에 실패하는 경우가 잦았습니다. 최소한의 버킷(Bucket) 권한만 부여하여 보안을 강화하는 것이 중요합니다. * 초기 업로드 시간: NAS의 총 500GB에 달하는 사진과 영상 데이터를 처음 Backblaze B2로 업로드하는 데 약 3일이 걸렸습니다. 이때는 NAS의 네트워크 트래픽이 거의 포화 상태가 되어 다른 작업을 하기 어려웠습니다. 대용량 초기 업로드 시에는 충분한 시간을 확보하고, 인터넷 회선에 무리가 가지 않도록 대역폭 제한을 설정하는 것을 추천합니다. * 월별 요금 확인: Backblaze B2는 저장 용량, 다운로드 용량에 따라 요금이 부과됩니다. 저는 월 평균 2.5달러 (약 3,500원) 정도로 500GB 데이터를 보관하고 있습니다. 예상치 못한 요금 폭탄을 피하기 위해 주기적으로 대시보드에서 사용량을 확인하는 것이 좋습니다.

자주 겪는 문제와 해결법

제가 직접 3-2-1 백업 시스템을 구축하고 운영하면서 가장 자주 겪었던 문제점들과 그 해결책을 공유합니다.

1. `rsync` 권한 문제: "Permission denied (13)" 에러

문제 상황: 백업 스크립트 실행 시 rsync: send_files failed to open "file": Permission denied (13) 또는 Permission denied (13) 에러가 발생하며 특정 파일/폴더가 백업되지 않습니다.
발생 원인:
1. 원본 파일/폴더에 스크립트 실행 사용자(또는 rsync 프로세스)가 읽기 권한이 없는 경우.
2. 대상 백업 위치에 스크립트 실행 사용자에게 쓰기 권한이 없는 경우. 특히 NAS 공유 폴더에 백업할 때 흔합니다.
해결법:
- 원본 권한 확인 (ls -l): bash $ ls -l /Users/luka/ProtectedDocs/secret_file.pdf -rw------- 1 root staff 10240 Jul 25 10:00 /Users/luka/ProtectedDocs/secret_file.pdf # 위 예시처럼 소유자가 'root'이고 다른 사용자는 접근 불가인 경우 sudo rsync ...를 사용하거나, chown 또는 chmod로 권한을 조정해야 합니다. 초보자는 sudo 사용에 주의해야 합니다. 불필요한 파일까지 시스템 권한으로 수정할 수 있습니다.
- 대상 권한 확인 (NAS 공유 폴더): NAS 관리자 페이지 (예: Synology DSM)에서 해당 공유 폴더에 접근하는 사용자 계정에 "읽기/쓰기" 권한이 부여되어 있는지 확인하고 적용합니다. 터미널에서 마운트된 NAS 경로의 권한을 확인하는 것도 도움이 됩니다: ls -ld /Volumes/NAS_Share/
- 제 경험: NAS 공유 폴더에 제 사용자 계정 권한이 "읽기 전용"으로 설정되어 있어 백업이 계속 실패했던 적이 있습니다. NAS 설정에서 권한을 "읽기/쓰기"로 변경하니 바로 해결되었습니다.

2. NAS 네트워크 속도 저하 문제

문제 상황: NAS로 파일을 전송할 때, 혹은 NAS에서 파일을 가져올 때 예상보다 훨씬 느린 속도(예: 10~20MB/s 미만)가 나옵니다.
발생 원인:
1. 오래된 네트워크 케이블: Cat5 또는 불량 케이블 사용.
2. 네트워크 혼잡: 동일 네트워크 내 다른 기기들의 트래픽이 많을 때.
3. 네트워크 장비 성능: 오래된 공유기/스위치가 기가비트를 지원하지 않거나, 성능이 저하되었을 때.
4. PC 또는 NAS의 네트워크 어댑터 문제: 드라이버 문제 또는 하드웨어 불량.
해결법:
- 케이블 교체: 모든 네트워크 케이블을 최소 Cat6 이상으로 교체하는 것이 가장 효과적입니다. 제가 Cat5에서 Cat6로 교체했을 때 전송 속도가 20MB/s에서 110MB/s로 5배 이상 빨라지는 것을 직접 경험했습니다.
- 기가비트 지원 장비 확인: 사용 중인 공유기, 스위치, PC/NAS의 LAN 포트가 모두 기가비트(1Gbps)를 지원하는지 확인합니다.
- 네트워크 설정 최적화: NAS와 PC의 네트워크 설정(예: 점보 프레임 Jumbo Frame)을 최적화할 수 있지만, 일반 사용자는 기본 설정으로도 충분한 경우가 많습니다.
- 제 경험: 공유기-NAS, PC-공유기를 잇는 모든 케이블을 Cat6으로 교체하고, 공유기 설정에서 QoS(Quality of Service) 설정을 검토한 결과, 100MB/s 이상의 안정적인 속도를 얻을 수 있었습니다.

3. 외장하드/NAS 용량 부족 예측 실패

문제 상황: 백업을 진행하던 도중 "대상 디스크 용량 부족" 경고가 뜨거나, 백업이 중간에 멈춥니다.
발생 원인:
1. 원본 데이터 증가율 과소평가: 생각보다 데이터가 빠르게 증가하여 백업 공간이 부족해지는 경우.
2. 버전 관리 기능 활성화: 백업 소프트웨어나 NAS의 버전 관리 기능이 과거 버전들을 저장하여 실제 데이터 용량보다 더 많은 공간을 차지하는 경우.
3. 임시 파일/로그 파일 누적: 백업 대상에 불필요한 임시 파일이나 용량이 큰 로그 파일이 포함된 경우.
해결법:
- 정기적인 용량 모니터링: df -h 명령(Linux/macOS)이나 디스크 관리자(Windows), NAS의 저장소 관리자에서 정기적으로 디스크 사용량을 확인합니다.
- 백업 용량 넉넉히 확보: 저는 항상 현재 데이터 용량의 1.5배 ~ 2배 정도를 백업 공간으로 확보한다고 생각하고 시작합니다. 최소한 1년 정도의 데이터 증가량을 예상해서 여유를 두는 것이 좋습니다.
- 오래된 백업 삭제/정리: NAS의 Hyper Backup이나 클라우드 서비스의 버전 관리 설정에서 오래된 백업 버전을 주기적으로 정리하거나, 보관 기간을 적절하게 설정하여 불필요한 공간 낭비를 줄입니다.
- 불필요한 파일 제외: rsync 명령어 사용 시 --exclude 옵션을 사용하여 백업에서 제외할 파일이나 폴더를 지정합니다 (예: *.tmp, node_modules/, log/).
- 제 경험: Synology Hyper Backup의 버전 관리를 "모든 버전 보존"으로 설정했다가, 예상보다 빠르게 클라우드 용량이 차오른 적이 있습니다. 이후 "스마트 휴지통(최소 7개 버전 보존)" 기능으로 변경하여 최적화했습니다.

마치며: 데이터는 나의 자산, 지키는 것은 나의 몫

개인 데이터는 단순한 파일이 아닙니다. 그것은 소중한 추억이자, 오랜 시간의 노력이 담긴 결과물이며, 때로는 미래의 기회를 위한 씨앗이 될 수도 있습니다. 데이터를 잃는다는 것은 이러한 가치들을 한순간에 상실하는 것과 같습니다.

3-2-1 백업 전략은 처음에는 복잡하고 귀찮게 느껴질 수 있습니다. 하지만 저의 경험처럼 한 번의 아찔한 순간을 겪고 나면 그 중요성을 절실히 깨닫게 될 것입니다. 모든 것을 한 번에 완벽하게 구축하려 하지 말고, 우선 외장하드에 중요한 파일을 복사하는 것부터 시작해 보세요. 그 작은 첫걸음이 여러분의 소중한 데이터를 안전하게 지키는 튼튼한 방패가 될 것입니다.

데이터 백업은 '사고가 났을 때' 하는 것이 아니라 '사고가 나기 전에' 해야 하는 필수적인 작업입니다. 이 글이 여러분의 데이터 보안에 작은 도움이 되기를 바라며, 궁금한 점이 있다면 언제든지 댓글로 문의해주세요.

안전하고 즐거운 테크 생활을 응원합니다! 루카였습니다.

핵심 요약

3-2-1 백업은 데이터 손실에 대한 가장 효과적인 방어 전략입니다: 원본 포함 3개의 복사본, 2가지 다른 매체, 1개의 원격지 보관.
외장하드, NAS, 클라우드를 조합하여 하드웨어 고장, 실수, 랜섬웨어, 자연재해 등 모든 유형의 데이터 손실에 대비할 수 있습니다.
자동화된 스크립트와 정기적인 검증, 그리고 예상치 못한 문제에 대한 대비를 통해 백업 시스템의 안정성을 유지하는 것이 중요합니다.

자주 묻는 질문 (FAQ)

Q1: 개인 사용자에게 NAS 구축이 정말 필요한가요? A1: 데이터 양과 활용 목적에 따라 다릅니다. 사진/영상 등 대용량 데이터를 가족과 공유하거나, 미디어 서버를 운영하고 싶거나, 24시간 상시 자동 백업이 필요한 경우 NAS는 매우 강력한 솔루션입니다. 하지만 단순히 소량의 중요 문서만 백업한다면 외장하드와 클라우드만으로도 충분할 수 있습니다. 개인의 필요성과 예산을 고려하여 결정하는 것이 좋습니다.

Q2: 백업 스크립트 대신 상용 백업 소프트웨어를 사용해도 될까요? A2: 물론입니다. 개인의 기술 수준과 편의성에 따라 선택하세요. 상용 백업 소프트웨어(예: Acronis True Image, Veeam Agent 등)는 사용자 친화적인 GUI와 강력한 스케줄링, 버전 관리 기능을 제공하여 편리합니다. 저는 세부적인 제어와 자동화, 그리고 특정 환경에 맞춘 커스터마이징을 위해 스크립트를 선호하지만, 익숙하지 않다면 상용 소프트웨어부터 시작하는 것도 좋은 방법입니다.

Q3: RAID가 백업을 대체할 수 있나요? A3: 아닙니다. RAID는 하드웨어 장애(예: 하드디스크 고장)로부터 데이터의 '가용성'을 높여주는 기술이지만, '백업'과는 목적이 다릅니다. 실수로 인한 파일 삭제, 랜섬웨어 공격, 바이러스 감염, 또는 화재/도난과 같은 물리적 재난으로부터는 RAID가 데이터를 보호해주지 못합니다. RAID는 시스템의 연속성을 위한 것이고, 백업은 데이터 복구를 위한 것이므로, RAID 구성과는 별개로 반드시 3-2-1 백업 전략을 준수해야 합니다.