13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] 데이터 복구

  • [Proxmox] Proxmox ZFS 스토리지, 흔한 문제와 해결책: 안정적인 운영 노하우

    [Proxmox] Proxmox ZFS 스토리지, 흔한 문제와 해결책: 안정적인 운영 노하우

    목차

    [가상화] Proxmox ZFS 스토리지, 흔한 문제와 해결책

    홈랩이나 사내 가상화 환경을 운영하다 보면 Proxmox ZFS 문제는 생각보다 빨리 한 번쯤 만나게 됩니다. 처음엔 VM만 잘 뜨면 끝인 줄 알았는데, 실제로 써보니까 스토리지가 흔들리면 전체 운영이 같이 흔들리더라고요. 특히 ZFS(File System, 체크섬과 복구 기능이 강한 파일 시스템) 기반으로 Proxmox VE(가상화 플랫폼)를 굴릴 때는 디스크 상태, 메모리 여유, 풀(pool) 구성, 스냅샷 관리가 다 연결되어 있습니다. 저도 처음엔 이게 뭔가 싶었는데, 에러 메시지는 짧고 증상은 묘하게 길게 이어져서 삽질 좀 했습니다 ㅎㅎ

    이번 글에서는 제가 홈랩과 테스트 서버에서 직접 부딪히며 정리한 Proxmox 스토리지 운영 팁을 기준으로, 자주 보이는 ZFS 에러, 성능 저하, 풀 손상 징후, 그리고 데이터 복구 접근 순서를 정리해보겠습니다. 단순히 명령어만 던지는 글이 아니라, 왜 이런 문제가 생기고 어떤 순서로 확인해야 덜 망가지는지까지 같이 보실 수 있게 구성했습니다.

    Proxmox 호스트, ZFS 풀, VM 디스크, 백업 저장소의 관계를 한눈에 보여주는 개요 이미지입니다.

    1. 왜 Proxmox ZFS 문제가 자주 체감될까요?

    쉽게 말해 ZFS는 그냥 디스크 묶음이 아니라, 스토리지 관리자 + 파일 시스템 + 무결성 검사기 역할을 같이 합니다. 그래서 장점이 큽니다. 체크섬(checksum, 데이터 변조나 손상 여부를 확인하는 값) 기반으로 데이터 무결성을 챙기고, 스냅샷(snapshot, 특정 시점 상태 저장)도 편하고, 미러(mirror)나 RAIDZ 같은 구성도 안정적으로 가져갈 수 있거든요.

    근데 여기서 중요한 포인트가 있습니다. ZFS는 문제를 숨기기보다 드러내는 편입니다. 디스크가 애매하게 고장 나기 시작하면 ext4 같은 단순 파일 시스템에서는 조용히 지나갈 수도 있는 이상 징후를 ZFS가 읽기/쓰기 오류로 먼저 드러내는 경우가 있었습니다. 운영자 입장에서는 무섭죠. 하지만 길게 보면 이게 오히려 안전합니다.

    • 디스크 자체 불량: SATA 케이블, HBA(Host Bus Adapter, 스토리지 연결 카드), SSD 펌웨어 문제까지 포함됩니다.
    • 메모리 부족: ARC(Adaptive Replacement Cache, ZFS 메모리 캐시)가 압박을 받으면 체감 성능이 떨어집니다.
    • 풀 용량 과다 사용: 여유 공간이 적으면 쓰기 성능이 급격히 흔들릴 수 있습니다.
    • 과도한 스냅샷: 삭제 정책 없이 쌓아두면 관리도 복잡해지고 공간 회수도 꼬입니다.
    • 불균형한 풀 설계: VM 랜덤 I/O와 백업 대용량 쓰기를 같은 풀에 몰아넣으면 병목이 생깁니다.

    저는 예전에 테스트한다고 VM 이미지, ISO, 백업, 템플릿을 한 풀에 다 넣었다가 야간 백업 시간만 되면 지연(latency, 응답 지연)이 튀는 걸 겪었습니다. 처음엔 네트워크 문제인 줄 알았는데, 결국 스토리지 쪽이더라고요.

    2. ZFS 핵심 개념, 운영자가 꼭 알아야 하는 것만

    2-1. pool, vdev, dataset 차이

    처음 ZFS를 접하면 용어부터 헷갈립니다. 저도 그랬습니다. 쉽게 말해 아래처럼 이해하시면 됩니다.

    용어 쉽게 설명 운영 포인트
    pool 전체 저장소 묶음 실제 사용량, 상태, 장애 여부를 먼저 보는 대상
    vdev 풀을 구성하는 디스크 그룹 미러, RAIDZ 구조에 따라 성능과 복구 특성이 달라짐
    dataset 풀 안의 논리 단위 파일 시스템 압축, 쿼터, 스냅샷 정책을 나눠 적용하기 좋음
    zvol 블록 디바이스처럼 쓰는 볼륨 VM 디스크 저장에 자주 사용

    2-2. scrub와 resilver는 다릅니다

    scrub은 전체 데이터를 읽으면서 손상 여부를 검사하는 작업이고, resilver는 디스크 교체 후 필요한 데이터를 다시 맞춰 넣는 작업입니다. 이름이 비슷해서 초반엔 헷갈리는데, 역할이 다릅니다. 운영 중에는 scrub 결과를 주기적으로 확인하는 습관이 정말 중요합니다.

    2-3. ZFS는 여유 공간이 성능입니다

    이 부분은 경험상 진짜 중요합니다. 풀 사용률이 높아질수록 메타데이터 처리와 쓰기 패턴이 불리해져서, 같은 SSD라도 체감이 확 달라집니다. 그래서 저는 실서비스든 홈랩이든 풀 여유 공간을 충분히 남겨두는 것을 우선 원칙으로 둡니다.

    3. 실전 점검: Proxmox 스토리지 기본 진단 순서

    Proxmox ZFS 문제가 생겼을 때 제일 위험한 건, 원인도 모른 채 디스크를 막 빼거나 재부팅부터 하는 겁니다. 실제로 써보니까 순서가 중요하더라고요. 저는 보통 아래 순서로 갑니다.

    1. 현재 풀 상태 확인
    2. 읽기/쓰기/체크섬 오류 확인
    3. 디스크 식별 정보와 SMART 상태 점검
    4. 용량, 압축, 스냅샷 과다 여부 확인
    5. Proxmox 작업 로그와 커널 메시지 확인
    6. 필요하면 scrub 또는 교체 작업 진행

    3-1. 가장 먼저 볼 명령어

    zpool status -v
zpool list
zfs list
zfs get compressratio,used,available,mountpoint -r rpool

    zpool status -v는 거의 출발점입니다. 여기에 읽기 오류(read errors), 쓰기 오류(write errors), 체크섬 오류(checksum errors), DEGRADED 상태, OFFLINE 디스크, 최근 scrub 결과가 다 모여 있거든요.

    예를 들어 상태가 아래처럼 나오면 디스크 이상을 의심해볼 수 있습니다.

    pool: tank
state: DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
action: Replace the device using 'zpool replace'.
scan: scrub repaired 0B in 02:11:00 with 0 errors on Sun Aug 10 02:11:00 2026
config:

    NAME        STATE     READ WRITE CKSUM
    tank        DEGRADED     0     0     0
      mirror-0  DEGRADED     0     0     0
        sda     ONLINE       0     0     0
        sdb     UNAVAIL      0     0     0

    이런 경우 저는 먼저 “진짜 디스크 고장인가, 연결 문제인가”를 분리해서 봅니다. SATA 환경에서는 케이블 불량이 생각보다 자주 있습니다.

    3-2. 디스크 식별과 SMART 확인

    ls -l /dev/disk/by-id/
smartctl -a /dev/sda
smartctl -a /dev/sdb

    가능하면 /dev/sdX보다 /dev/disk/by-id/ 기준으로 실제 장치를 확인하는 게 좋습니다. 재부팅 후 장치명이 바뀌는 경우가 있거든요. 여기서 재할당 섹터, 미디어 오류, 인터페이스 오류, 온도 이상 같은 징후를 같이 봅니다.

    Proxmox ZFS 문제 점검을 위한 디스크 상태 확인 이미지

    ZFS 풀 상태 확인과 디스크 오류 진단 흐름을 보여주는 예시 이미지입니다.

    3-3. Proxmox 쪽 로그도 같이 봐야 합니다

    journalctl -b | grep -i zfs
journalctl -b | grep -Ei 'ata|scsi|nvme|i/o error'
dmesg | grep -Ei 'zfs|ata|nvme|reset|error'
pvesm status

    여기서 ATA reset, I/O error, device timeout 같은 메시지가 보이면 ZFS 자체보다 하드웨어 경로 문제일 확률도 높습니다. 특히 HBA 패스스루(pass-through, 장치를 직접 넘기는 방식) 환경에서는 케이블, 백플레인(backplane), 전원 안정성까지 봐야 하더라고요.

    4. 흔한 ZFS 에러와 해결책

    4-1. 풀 상태가 DEGRADED로 바뀐 경우

    이건 가장 많이 보는 유형 중 하나입니다. 미러 구성에서는 한 디스크가 빠져도 서비스는 계속 돌아가지만, 그 상태로 오래 두면 다음 장애 때 복구 여지가 줄어듭니다.

    • 케이블 재장착 후 다시 인식되는지 확인
    • SMART 상태가 나쁘면 디스크 교체
    • 교체 후 zpool replace로 resilver 진행
    zpool replace tank old-disk-id new-disk-id
zpool status -v

    처음엔 단순히 새 디스크만 꽂으면 끝나는 줄 알았는데, 실제로는 기존 디스크 식별자를 정확히 잡는 게 중요했습니다. 잘못 잡으면 엉뚱한 장치 건드릴 수 있으니 꼭 by-id 기준으로 확인하세요.

    4-2. checksum error가 누적되는 경우

    ZFS 에러 중에서 운영자를 가장 찝찝하게 만드는 게 체크섬 오류입니다. 데이터가 읽히긴 읽히는데 무결성 문제가 감지되는 거라서, 디스크 자체뿐 아니라 케이블이나 컨트롤러도 의심해봐야 합니다.

    • 특정 디스크에만 집중되는지 확인
    • scrub 실행 후 오류 증가 여부 확인
    • 다른 포트나 케이블로 바꿔서 재검증
    zpool scrub tank
zpool status -v

    제 경험상 checksum error가 꾸준히 늘어나는데 SMART는 멀쩡한 경우, 케이블이나 포트 문제였던 적이 꽤 있었습니다. 디스크만 의심하면 오히려 늦어집니다.

    4-3. 성능 저하가 갑자기 심해진 경우

    성능 저하는 원인이 하나가 아닙니다. ZFS는 캐시, 압축, 동기식 쓰기, 스냅샷, 풀 사용률이 서로 영향을 줍니다.

    • 풀 사용률이 지나치게 높은지 확인
    • 백업 작업이나 scrub가 겹치는 시간인지 확인
    • 스냅샷이 과도하게 쌓였는지 확인
    • 랜덤 I/O가 많은 VM과 대용량 백업이 같은 풀인지 확인
    zfs list -t snapshot | wc -l
zpool iostat -v 2

    zpool iostat -v 2는 체감이 안 좋을 때 꼭 한 번 보게 됩니다. 어느 vdev에서 병목이 걸리는지 흐름이 보이거든요. 드디어 원인 잡았을 때 그 시원함, 아시는 분은 아실 겁니다.

    4-4. 스냅샷 때문에 공간이 안 돌아오는 것처럼 보일 때

    삭제했는데도 공간이 안 늘어나는 경우가 있죠. 이건 대개 스냅샷이 이전 블록을 붙잡고 있어서 그렇습니다. VM 디스크를 자주 지우고 만들었다면 더 눈에 띕니다.

    zfs list -t snapshot -o name,used,creation -s creation
zfs destroy tank/vmdata@old-snapshot

    다만 스냅샷은 복구 안전망이기도 하니까 무작정 지우면 안 됩니다. 저는 운영 환경에서는 보존 주기를 먼저 정하고 자동화하는 쪽을 권합니다.

    5. 데이터 복구 접근은 이렇게 하시는 게 안전합니다

    데이터 복구는 속도보다 순서가 중요합니다. 이건 정말 강조하고 싶습니다. 풀 상태가 불안정한데 이것저것 쓰기 작업부터 해버리면 상황이 더 꼬일 수 있거든요.

    1. 먼저 현재 상태를 기록합니다. zpool status -v, zpool history, SMART 출력 저장.
    2. 자동 작업을 잠시 멈춥니다. 대량 백업, 복제(replication), 불필요한 VM 작업 중지.
    3. 읽기 우선으로 접근합니다. 필요한 데이터부터 다른 저장소로 백업합니다.
    4. 하드웨어 문제와 논리 문제를 구분합니다.
    5. 교체 후 resilver, 또는 백업 복원 순서로 갑니다.
    zpool history tank
zfs snapshot tank/vmdata@pre-recovery
zfs send tank/vmdata@pre-recovery | mbuffer | zfs receive backup-pool/vmdata

    물론 위 전송 예시는 대상 풀과 네트워크 환경이 준비되어 있어야 합니다. 핵심은 “문제 풀이 아니라 데이터 보존이 먼저”라는 점입니다. 저도 예전에 에러 잡는다고 로그만 보다가, 정작 중요한 VM 백업을 늦게 떠서 식은땀 흘린 적이 있습니다.

    Proxmox ZFS 문제 발생 시 데이터 복구 흐름도 이미지

    장애 발생 후 점검, 백업, 교체, 복구 순서를 정리한 흐름도 이미지입니다.

    6. 운영하면서 미리 해두면 좋은 Proxmox ZFS 안정화 팁

    6-1. 역할이 다른 워크로드를 분리하세요

    가능하면 VM 운영 풀과 백업 저장소 성격을 분리하는 게 좋습니다. 같은 SSD 풀에 모든 걸 몰면 평소엔 괜찮아 보여도, 백업 시간이나 대량 복제 시간에 병목이 확 옵니다.

    6-2. scrub 주기와 결과 확인 습관

    scrub를 주기적으로 돌리고 결과를 눈으로 확인하세요. 자동으로 돌았다고 끝이 아닙니다. “repaired 0B with 0 errors” 같은 결과가 쌓이는 게 안심 포인트거든요.

    6-3. 스냅샷 정책은 짧고 명확하게

    스냅샷은 많다고 무조건 좋은 게 아닙니다. 운영 편의성과 공간 회수 사이 균형이 필요합니다. 저는 보통 아래처럼 생각합니다.

    대상 권장 방향 이유
    중요 VM 짧은 간격 + 짧은 보존 복구 시점 확보
    테스트 VM 작업 전 수동 스냅샷 위주 불필요한 누적 방지
    백업 데이터셋 정책 단순화 공간 추적 용이

    6-4. 모니터링 포인트를 정해두세요

    • 풀 상태 변화: ONLINE, DEGRADED, FAULTED
    • 읽기/쓰기/체크섬 오류 카운트
    • 사용률과 여유 공간
    • 디스크 온도와 SMART 경고
    • 백업 시간대 I/O 급증 여부

    여기서 중요한 포인트! 문제가 터진 뒤 로그를 모으는 것보다, 평소 정상 상태를 알고 있는 게 훨씬 강합니다.

    7. 검증: 문제 해결 후 무엇을 확인해야 할까요?

    조치가 끝났다고 바로 안심하긴 이릅니다. 저도 처음엔 디스크 교체 후 ONLINE만 보고 끝냈었는데, 실제로 써보니까 이후 검증이 더 중요했습니다.

    1. zpool status -v에서 모든 장치가 ONLINE인지 확인
    2. 최근 scrub 결과에 추가 오류가 없는지 확인
    3. VM 디스크 읽기/쓰기 테스트와 실제 부팅 확인
    4. 백업 작업을 한 번 수동 실행해 병목이 줄었는지 확인
    5. 이벤트 로그에 추가 I/O error가 없는지 재확인
    zpool status -v
zpool iostat -v 2
qm list
pvesm status

    체감상 가장 좋은 검증은 “평소 하던 작업을 다시 돌려보는 것”입니다. VM 마이그레이션, 백업, 스냅샷 생성, 복원 테스트까지 한 번 해보면 진짜 안정화됐는지 감이 옵니다.

    Proxmox ZFS 문제 해결 후 정상 상태를 보여주는 검증 이미지

    복구 이후 ZFS 풀이 정상 ONLINE 상태로 돌아오고 성능 지표가 안정된 모습을 보여주는 이미지입니다.

    8. 자주 묻는 질문 정리

    Q1. scrub 중인데 서버가 느려졌습니다. 중단해야 할까요?

    상황에 따라 다릅니다. 서비스 영향이 크면 시간대를 조정하는 게 낫습니다. 다만 손상 의심 상황이라면 너무 오래 미루는 것도 좋지 않습니다.

    Q2. ZFS 에러가 0이어도 체감이 느릴 수 있나요?

    그렇습니다. 에러 카운트가 없어도 풀 사용률, 스냅샷 누적, 백업 동시 수행, 느린 디스크 혼합 구성 때문에 성능 저하는 충분히 생깁니다.

    Q3. 데이터 복구 전에 scrub부터 돌려도 되나요?

    무조건 그렇진 않습니다. 불안정한 하드웨어 상태에서는 먼저 중요한 데이터를 다른 곳으로 옮기는 쪽이 더 안전할 수 있습니다.

    Q4. Proxmox 스토리지는 ZFS 하나로 끝내도 될까요?

    작은 환경에서는 충분히 좋습니다. 다만 백업 저장소 성격까지 한 풀에 몰아넣기보다는, 역할 분리를 고민해보시는 게 운영이 편합니다.

    9. 마무리: 결국 안정성은 구조와 습관에서 나옵니다

    Proxmox ZFS 문제는 단순히 명령어 몇 줄로 끝나는 경우도 있지만, 실제로는 구조와 습관의 문제인 경우가 많습니다. 케이블 하나, 스냅샷 정책 하나, 여유 공간 관리 하나가 나중에 큰 차이를 만들더라고요. 저도 처음엔 ZFS가 너무 예민한 거 아닌가 싶었는데, 오래 운영해보니 예민한 게 아니라 정확한 쪽에 가깝다는 생각이 들었습니다.

    정리하면 이렇습니다. ZFS 에러는 메시지 자체보다 맥락을 봐야 하고, Proxmox 스토리지는 평소 설계가 반입니다. 그리고 데이터 복구는 원인 분석보다 보존이 먼저입니다. 이 세 가지만 잡아도 운영 안정성이 꽤 달라집니다.

    다음 글에서는 Proxmox 백업 저장소 분리 전략과 스냅샷/복제 운영 패턴도 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 네트워크 분리 구성과 함께 보시면 더 이해가 잘 되실 거예요.

    운영 전 점검, 장애 대응, 복구 후 검증까지 한 장으로 정리한 요약 인포그래픽 이미지입니다.

  • [Nas] rclone을 활용한 NAS-클라우드 백업, 치명적인 설정 실수와 복구 사례 연구

    [Nas] rclone을 활용한 NAS-클라우드 백업, 치명적인 설정 실수와 복구 사례 연구

    목차

    [백업] rclone NAS 백업, 치명적인 설정 실수와 복구 사례

    NAS를 오래 굴리다 보면 결국 한 번은 rclone NAS 백업을 진지하게 보게 됩니다. 저도 홈랩에서 사진, 문서, 설정 파일을 NAS에 몰아두고 쓰다가 어느 날 디스크 알림을 보고 식은땀이 나더라고요. 그래서 클라우드로 2차 백업을 붙였는데, 문제는 백업 도구보다 설정 방향이 더 무섭다는 점이었습니다. 특히 rclone은 강력한 만큼 실수했을 때 결과도 큽니다. 오늘은 제가 실제로 겪었던 클라우드 동기화 삽질과, 그 뒤에 어떻게 데이터 복구를 했는지 사례 중심으로 정리해보겠습니다.

    혹시 ‘백업 한 줄 알았는데 동기화가 삭제를 전파했다’ 같은 경험 있으신가요? 이 글은 그런 분들을 위해 쓰는 글입니다. 처음엔 저도 이게 뭔가 싶었는데, 구조를 이해하고 나니까 왜 사고가 났는지 보이더라고요.

    NAS와 클라우드 백업 전체 아키텍처 다이어그램

    NAS 원본 데이터, rclone 작업 경로, 클라우드 백업 저장소의 관계를 보여주는 개요 이미지입니다.

    1. 왜 rclone NAS 백업에서 사고가 자주 나는가

    rclone은 여러 스토리지 간 파일을 복사하고 동기화하는 CLI(Command Line Interface, 명령줄 인터페이스) 도구입니다. 쉽게 말해 NAS와 클라우드 사이에 짐을 옮기는 숙련된 기사님 같은 역할이죠. 문제는 기사님이 너무 성실해서, 제가 잘못 시키면 잘못된 작업도 아주 정확하게 해낸다는 겁니다 ㅎㅎ

    여기서 중요한 포인트는 두 가지입니다.

    • copy는 보통 원본을 대상에 복사합니다. 대상에 없는 파일을 채우는 쪽에 가깝습니다.
    • sync는 원본 상태를 대상에 맞춥니다. 즉, 원본에서 사라진 파일은 대상에서도 제거될 수 있습니다.

    백업 실패 사례 대부분은 성능 문제가 아니라, copy와 sync의 의미를 다르게 이해한 상태에서 운영에 넣는 것에서 시작하더라고요.

    2. rclone 설정 전에 꼭 알아야 할 핵심 개념

    2-1. Source(소스, 원본)와 Destination(대상지)의 방향

    rclone 명령은 항상 앞이 원본, 뒤가 대상입니다. 말로 들으면 쉬운데 실제로 새벽에 급하게 치다 보면 여기서 사고가 납니다. 저도 처음엔 경로만 맞으면 되겠지 싶었는데, 딱 여기서 한 번 크게 미끄러졌습니다.

    2-2. 동기화와 보관은 같은 말이 아닙니다

    항목 copy sync
    주요 목적 복사, 누락분 채우기 원본 상태와 동일화
    삭제 전파 위험 상대적으로 낮음 높음
    초기 백업 용도 적합 주의 필요
    운영 난이도 낮음 높음

    그래서 저는 요즘 초기 적재(initial seed, 첫 데이터 적재)에는 copy, 검증이 끝난 뒤 제한적으로만 sync를 씁니다.

    3. 실전 구성: 안전한 rclone NAS 백업 기본 뼈대

    제가 홈랩에서 많이 쓰는 방식은 단순합니다. NAS의 특정 공유 폴더를 클라우드 리모트(remote, 원격 저장소)에 백업하고, 삭제 파일은 바로 날리지 않고 별도 보관 폴더로 밀어넣는 구조입니다. 이게 조금 번거로워 보여도, 사고 한 번 막아주면 본전 뽑고도 남습니다.

    1. NAS에서 백업 대상 폴더를 분리합니다. 예: `/volume1/data`
    2. rclone 리모트를 생성합니다. 예: `cloudbackup:`
    3. 처음에는 반드시 `lsf`, `size`, `sync –dry-run`으로 확인합니다.
    4. 운영 전에는 `–backup-dir` 같은 안전장치를 붙입니다.

    아래는 실제로 제가 비슷한 방식으로 정리해두는 명령 예시입니다.

    rclone lsf cloudbackup:
rclone size /volume1/data
rclone size cloudbackup:nas-backup

rclone sync /volume1/data cloudbackup:nas-backup \
  --dry-run \
  --progress \
  --checkers=8 \
  --transfers=4

    –dry-run은 진짜 중요합니다. 실행은 안 하고, 무슨 일이 벌어질지만 보여주거든요. 귀찮아도 이 단계는 건너뛰지 마세요.

    3-1. 운영용으로 조금 더 안전하게 만들기

    rclone sync /volume1/data cloudbackup:nas-backup \
  --progress \
  --log-file=/var/log/rclone-nas-backup.log \
  --log-level=INFO \
  --backup-dir=cloudbackup:nas-deleted/$(date +%F) \
  --check-first

    이 설정의 핵심은 삭제되거나 교체되는 파일을 바로 증발시키지 않고, backup-dir(백업 보관 디렉터리)로 보내는 것입니다. 완전한 스냅샷(snapshot, 시점 보관)은 아니지만, 실수 복구용 안전망으로 꽤 유용합니다.

    rclone 설정 흐름과 sync/copy 분기 다이어그램

    초기 copy, 검증, 운영 sync, backup-dir 적용까지 이어지는 안전한 설정 흐름을 설명하는 이미지입니다.

    4. 제가 실제로 겪은 치명적인 설정 실수

    이제 본론입니다. 어느 날 백업 정책을 손보다가 원래는 아래처럼 실행해야 했습니다.

    rclone sync /volume1/data cloudbackup:nas-backup

    그런데 실제로는 반대로 쳤습니다.

    rclone sync cloudbackup:nas-backup /volume1/data

    짧은 명령 한 줄인데 파괴력은 엄청났습니다. 클라우드 쪽이 일부만 올라가 있던 상태였거든요. 결과적으로 NAS 쪽이 클라우드 상태에 맞춰지면서 파일이 사라지기 시작했습니다. 처음엔 로그가 빨리 지나가서 몰랐는데, 폴더 개수가 줄어드는 걸 보고 그때 ‘아, 잘못됐다’ 싶더라고요. 진짜 등골이 서늘했습니다.

    이런 백업 실패 사례가 무서운 이유는, 사용자는 ‘백업 중’이라고 생각하지만 실제로는 ‘정리 작업’이 진행될 수 있다는 점입니다. 특히 자동화 스케줄러(cron, 작업 예약)에 등록해두면 반복 피해까지 생길 수 있습니다.

    4-1. 사고 직후 가장 먼저 한 일

    1. 실행 중인 rclone 작업을 즉시 중단했습니다.
    2. 자동 실행 스케줄을 비활성화했습니다.
    3. NAS 원본 경로에 추가 쓰기를 멈췄습니다.
    4. rclone 로그와 최근 삭제 파일 목록을 확보했습니다.

    여기서 중요한 건 당황해서 다시 sync를 돌리지 않는 것입니다. 덮어쓰기 한 번 더 들어가면 복구 범위가 더 줄어들 수 있거든요.

    5. 복구 과정: 데이터 복구는 어떻게 접근했나

    복구는 ‘뭘 믿을 수 있느냐’부터 따져야 합니다. 저는 아래 순서로 확인했습니다.

    1. 클라우드 저장소에 삭제 보관함이나 버전 관리 기능이 있는지 확인
    2. 이전 백업 로그와 파일 목록 비교
    3. 남아 있는 클라우드 데이터부터 읽기 전용으로 점검
    4. 복구 대상만 별도 경로에 copy

    예를 들어 클라우드 쪽에 아직 파일이 살아 있다면, 바로 원위치로 덮어쓰지 말고 임시 복구 폴더로 먼저 가져오는 게 안전합니다.

    mkdir -p /volume1/recovery-restore

rclone copy cloudbackup:nas-backup /volume1/recovery-restore \
  --progress \
  --ignore-existing \
  --log-file=/var/log/rclone-recovery.log \
  --log-level=INFO

    그다음 NAS 원본과 임시 복구본을 비교했습니다.

    rclone check /volume1/recovery-restore /volume1/data \
  --one-way \
  --combined=/tmp/rclone-compare.txt

    이 단계가 좋았던 이유는, 복구를 바로 반영하지 않고 차이를 먼저 볼 수 있었기 때문입니다. 실제로 써보니까 조급함만 버려도 성공 확률이 올라가더라고요.

    만약 평소에 아래 같은 형태로 운영했다면 훨씬 쉬웠을 겁니다.

    rclone sync /volume1/data cloudbackup:nas-backup \
  --backup-dir=cloudbackup:nas-deleted/2026-06-29

    그러면 삭제되거나 바뀐 파일이 따로 남아 있어서, 필요한 것만 다시 복사하면 됩니다. 결국 복구 난이도는 사고 순간이 아니라 사고 전에 어떤 안전장치를 걸어뒀는가에서 갈리더라고요.

    6. 트러블슈팅: 다시는 같은 사고를 내지 않기 위한 rclone 설정

    • ⚠️ 운영 전 명령을 스크립트로 고정하고, 수동 타이핑을 줄입니다.
    • ⚠️ 첫 실행은 반드시 `–dry-run`과 `rclone lsf`로 방향을 확인합니다.
    • ⚠️ `sync`가 꼭 필요하지 않으면 `copy`부터 검토합니다.
    • ⚠️ 삭제 대응이 필요하면 `–backup-dir` 또는 저장소의 버전 관리 기능을 함께 씁니다.
    • 💡 로그 파일은 꼭 남기세요. 복구 때 생각보다 큰 힌트가 됩니다.

    제가 지금은 아예 아래처럼 래퍼 스크립트(wrapper script, 실행 감싸기 스크립트)를 써서 실수를 줄입니다.

    #!/usr/bin/env bash
set -euo pipefail

SRC='/volume1/data'
DST='cloudbackup:nas-backup'
STAMP=$(date +%F)

rclone sync "$SRC" "$DST" \
  --dry-run \
  --progress \
  --backup-dir="cloudbackup:nas-deleted/$STAMP"

    처음엔 이 스크립트가 너무 보수적인가 싶었는데, 몇 번 운영해보니 이런 게 결국 사람을 살립니다.

    7. 검증과 결과: 백업은 성공 로그보다 복구 테스트가 더 중요합니다

    백업이 잘 됐는지는 파일 몇 개 올라간 걸로 판단하면 안 됩니다. 저는 최소한 아래 세 가지를 확인합니다.

    1. 원본과 대상의 파일 수, 용량 추세가 크게 어긋나지 않는지
    2. 샘플 파일을 실제로 복구했을 때 열리는지
    3. 삭제 시나리오에서 backup-dir 또는 버전 관리가 동작하는지
    rclone size /volume1/data
rclone size cloudbackup:nas-backup
rclone lsf cloudbackup:nas-deleted/$(date +%F) | head

    이 과정을 거치고 나서야 비로소 ‘백업이 있다’고 말할 수 있더라고요. 단순 복사는 끝났을지 몰라도, 데이터 복구가 검증되지 않으면 진짜 백업이라고 보기 어렵습니다.

    복구 검증 결과와 로그 확인 대시보드

    백업 로그, 파일 수 비교, 샘플 복구 성공 여부를 한눈에 확인하는 검증 화면 이미지입니다.

    8. 자주 묻는 질문과 정리

    8-1. copy만 써도 되나요?

    많은 경우 됩니다. 특히 초기 구축이나 보수적 운영에서는 오히려 더 안전합니다. sync는 강력하지만 삭제 전파 위험을 이해한 뒤 써야 합니다.

    8-2. 클라우드 동기화와 백업은 같은 말인가요?

    아닙니다. 클라우드 동기화는 상태를 맞추는 데 가깝고, 백업은 복원 가능성을 보장하는 데 더 가깝습니다. 이름은 비슷한데 목표가 다릅니다.

    8-3. 어떤 점이 가장 중요했나요?

    저는 세 가지였습니다. 첫째, 방향 확인. 둘째, 삭제 보관. 셋째, 복구 테스트. 이 세 개만 챙겨도 rclone 설정 사고 확률이 꽤 줄어듭니다.

    운영 전 점검해야 할 dry-run, backup-dir, 로그, 복구 테스트 항목을 요약한 체크리스트 이미지입니다.

    9. 마무리: rclone NAS 백업은 도구보다 운영 습관이 더 중요합니다

    rclone NAS 백업 자체는 정말 훌륭합니다. 저도 지금은 아주 만족하면서 쓰고 있습니다. 다만 이 도구는 친절한 GUI(Graphical User Interface, 그래픽 인터페이스)보다 명확한 명령에 충실한 타입이라, 운영자가 방향을 잘못 잡으면 그대로 따라갑니다. 저도 처음엔 헷갈렸고, 삽질 좀 했습니다 ㅎㅎ 그런데 그 덕분에 지금은 백업 설계를 할 때 무조건 복구 시나리오부터 생각하게 됐습니다.

    정리하면 이렇습니다. rclone NAS 백업을 할 때는 처음부터 sync를 믿고 달리지 말고, 작은 범위에서 dry-run으로 검증하고, 삭제 보관 장치를 켜고, 반드시 복구 테스트까지 해보세요. 이거 진짜 편하더라고요. 다음 글에서는 `rclone mount`와 미디어 아카이브 운영 팁도 다뤄볼 예정입니다. 이전 글에서 다룬 스냅샷 백업 전략과 함께 보시면 더 도움이 될 겁니다. 🎉

  • [Nas] NAS 디스크 교체 후 SMART 모니터링 심층 분석: 숨겨진 문제 진단과 예방

    [Nas] NAS 디스크 교체 후 SMART 모니터링 심층 분석: 숨겨진 문제 진단과 예방

    목차

    NAS 디스크 교체 후 SMART 모니터링 심층 분석: 숨겨진 문제 진단과 예방

    안녕하세요, 13년차 서버실 주인장입니다. 홈랩을 운영하다 보면 장비들을 직접 만지고 관리하는 일이 잦은데요. 특히 NAS(Network Attached Storage)는 제 소중한 데이터들을 보관하는 금고나 마찬가지라서, 하드디스크(HDD) 관리에 신경을 곤두세우고 있습니다. 얼마 전, 제 NAS에 사용하던 HDD 하나에 수명이 다 된 것 같다는 느낌을 받고 교체를 진행했는데요. 새 디스크를 장착하고 나서 그냥 쓰기만 하면 안 되겠죠? 오늘은 바로 이 NAS 디스크 교체 후 SMART 모니터링을 통해 숨겨진 문제를 진단하고 예방하는 방법에 대해 제 경험을 바탕으로 자세히 이야기해 보려고 합니다. 혹시 여러분도 NAS 디스크를 교체하거나, 현재 사용 중인 디스크의 건강 상태가 궁금하신가요? 그렇다면 이 글이 도움이 될 겁니다.

    NAS 시스템 개요 및 디스크 모니터링 중요성을 보여주는 다이어그램

    NAS 시스템 개요 및 디스크 모니터링의 중요성을 보여주는 다이어그램

    1. SMART, 도대체 뭘까요? (NAS 디스크 건강의 나침반)

    먼저 SMART(Self-Monitoring, Analysis and Reporting Technology)가 뭔지 간단히 설명해 드릴게요. 쉽게 말해, 하드디스크나 SSD 같은 저장 장치가 스스로 자신의 상태를 진단하고 기록하는 기술이에요. 마치 우리 몸이 아프면 열이 나거나 통증을 느끼는 것처럼, 디스크도 스스로 이상 징후를 감지하고 SMART 값을 통해 알려주는 거죠. 이 SMART 데이터에는 디스크의 온도, 읽기/쓰기 오류 횟수, 재할당 섹터 수 등 다양한 정보가 포함되어 있습니다. NAS SMART 모니터링은 이 값들을 주기적으로 확인해서 디스크에 문제가 생기기 전에 미리 파악하는 정말 중요한 과정입니다.

    2. 새 디스크 장착, 그리고 SMART 값 확인의 시작

    제가 사용 중인 NAS는 Synology 제품인데요. DSM(DiskStation Manager)이라는 운영체제를 통해 SMART 값을 쉽게 확인할 수 있습니다. 기존 HDD를 새 HDD로 교체하고, DSM에서 디스크를 인식시킨 후 가장 먼저 한 일은 바로 SMART 테스트를 실행하는 것이었습니다. 보통 ‘빠른 테스트(Quick Test)’와 ‘확장 테스트(Extended Test)’ 두 가지가 있는데, 저는 새 디스크의 초기 상태를 확실히 확인하기 위해 확장 테스트를 먼저 돌렸어요. 이 과정은 시간이 꽤 걸리지만, 디스크의 모든 섹터를 꼼꼼하게 읽고 쓰면서 잠재적인 불량 섹터(Bad Sector)를 찾아내거든요. 제 경험상, 새 디스크라고 해서 무조건 완벽한 건 아니더라고요.

    확장 테스트를 기다리는 동안, 저는 NAS의 다른 설정들도 함께 점검했습니다. RAID 구성은 제대로 되었는지, 볼륨 상태는 정상인지 등을 확인했죠. 새 디스크가 추가되면서 RAID 어레이 재구축(Rebuilding) 과정이 백그라운드에서 진행될 수 있기 때문에, 이 부분도 신경 써야 합니다. 특히, 여러 개의 디스크로 RAID를 구성했을 경우, 하나의 디스크에 문제가 생기면 나머지 디스크들도 영향을 받을 수 있거든요.

    Synology DSM에서 SMART 확장 테스트를 실행하는 화면 스크린샷

    3. SMART 데이터 해석, 무엇을 봐야 할까? (핵심 지표 분석)

    SMART 데이터는 수많은 값으로 이루어져 있어서 처음 보면 좀 복잡하게 느껴질 수 있습니다. 하지만 몇 가지 핵심 지표만 잘 살펴봐도 디스크의 건강 상태를 파악하는 데 큰 도움이 됩니다. 제가 주로 확인하는 항목들은 다음과 같아요.

    • Reallocated Sectors Count (재할당 섹터 수): 디스크 표면의 일부 영역(섹터)에 오류가 발생하여 더 이상 데이터를 읽거나 쓸 수 없을 때, 해당 섹터를 사용하지 않고 미리 준비된 예비 섹터로 대체하는 횟수입니다. 이 값이 0이 아니거나 계속 증가 추세를 보인다면 매우 위험 신호에요. 새 디스크의 경우, 초기 테스트에서 간혹 1~2개 정도 잡히는 경우가 있긴 하지만, 그 이후로 계속 늘어난다면 디스크 불량 가능성이 높습니다.
    • Current Pending Sector Count (현재 대기 섹터 수): 읽기 오류가 발생하여 아직 정상 섹터로 대체되지 않고, 다음 쓰기 작업 시 대체될 가능성이 있는 섹터 수입니다. 이 값 역시 0이 아니거나 증가 추세를 보이면 주의해야 해요.
    • Uncorrectable Errors (수정 불가능한 오류): 읽기/쓰기 과정에서 발생한 오류 중 수정할 수 없는 횟수입니다. 당연히 이 값은 0이어야 합니다.
    • Spin Retry Count (스핀 재시도 횟수): 디스크 플래터가 정상 속도로 회전하지 못해 재시도한 횟수예요. 이 값이 높으면 모터나 베어링 쪽에 문제가 있을 수 있습니다.
    • Power-On Hours (전원 켜진 시간): 디스크가 작동한 총 시간입니다. 이를 통해 디스크의 사용량을 가늠할 수 있어요.
    • Temperature (온도): 디스크의 현재 온도입니다. 너무 높거나 낮으면 디스크 수명에 좋지 않습니다.

    💡 팁: 보통 NAS 제조사 소프트웨어에서는 이 값들을 ‘좋음(Good)’, ‘주의(Warning)’, ‘나쁨(Bad)’ 등으로 표시해주기도 합니다. 하지만 저는 가장 신뢰할 수 있는 것은 각 항목의 RAW 값(실제 수치)이라고 생각해요. 제조사에서 제공하는 상태 표시는 때로는 너무 관대하거나, 혹은 너무 민감하게 반응할 때도 있거든요. RAW 값을 직접 보고 판단하는 것이 훨씬 정확합니다.

    4. 실제 겪은 문제와 해결 과정: ‘Pending Sector’의 함정

    제가 이번에 디스크를 교체하고 나서 확장 테스트를 돌렸는데, 모든 항목이 ‘좋음’으로 나왔습니다. 그래서 안심하고 데이터를 옮기기 시작했죠. 그런데 며칠 뒤, DSM에서 디스크에 문제가 있다는 알림이 뜨는 거예요! 😱 처음엔 이게 뭔가 싶었습니다. 분명 SMART 테스트도 통과했는데 말이죠. 다시 SMART 정보를 자세히 보니, ‘Current Pending Sector Count’ 항목에 아주 작은 값이 잡혀 있더라고요. (정확한 수치는 기억이 안 나지만, 1~2개 수준이었습니다.)

    이게 무슨 말이냐면, 디스크를 읽는 과정에서 아주 잠깐 오류가 발생했지만, 아직 ‘재할당’될 정도로 심각한 상황은 아니라는 뜻입니다. 하지만 이 ‘대기 중인 섹터’들이 나중에 쓰기 작업을 하거나, 디스크에 부하가 걸렸을 때 실제 불량으로 이어질 가능성이 있다는 거죠. 즉, SMART 테스트 통과가 끝이 아니라는 걸 깨달았거든요. 새 디스크라도 초기에는 이런 ‘숨겨진’ 문제들이 있을 수 있어요.

    ⚠️ 해결 과정:

    1. 데이터 백업 재확인: 혹시 모를 상황에 대비해, 이미 옮겨둔 데이터의 백업을 다시 한번 확인했습니다. (가장 중요!)
    2. 디스크 재검사: DSM에서 제공하는 ‘데이터 무결성 검사(Data Scrubbing)’ 기능을 실행했습니다. 이 기능은 RAID 볼륨 전체의 데이터를 읽어 무결성을 검사하고, 필요한 경우 오류를 수정하는 과정입니다. SMART 확장 테스트와는 또 다른 차원에서 디스크를 점검해 줍니다.
    3. 추가 모니터링: 데이터 무결성 검사가 완료된 후에도 ‘Current Pending Sector Count’ 값이 계속 유지되는지, 혹은 다른 SMART 항목에 변화가 없는지 며칠간 더 주의 깊게 모니터링했습니다.

    결과적으로, 제 경우에는 데이터 무결성 검사를 진행한 후 해당 값이 사라졌어요. 아마도 검사 과정에서 해당 섹터에 대한 쓰기 작업이 이루어지면서 정상화되었거나, 혹은 오류가 없는 것으로 최종 판정된 것 같습니다. 하지만 만약 이 값이 계속 유지되거나 다른 문제로 이어진다면, 저는 그 디스크를 즉시 교체했을 겁니다. 데이터 손실 방지를 위해서는 조금이라도 의심스러운 부분은 그냥 넘어가지 않는 것이 정말 중요하거든요.

    주요 SMART 항목별 의미와 중요도를 나타내는 비교표

    주요 SMART 항목별 의미와 중요도를 나타내는 비교표

    5. NAS SMART 모니터링, 꾸준함이 답이다

    디스크 교체 후 초기 점검도 중요하지만, NAS 디스크의 건강을 오랫동안 유지하기 위해서는 꾸준한 SMART 모니터링이 정말 중요해요. 대부분의 NAS 운영체제는 SMART 정보를 주기적으로 자동 검사하고, 이상이 감지되면 알림을 보내주는 기능을 제공합니다. 이 알림 기능을 반드시 활성화해 두세요. 저는 개인적으로 일주일에 한 번 정도 수동으로 SMART 상태를 확인하는 습관을 들이고 있습니다.

    NAS 제조사들은 대부분 ‘데이터 무결성 검사(Data Scrubbing)’ 또는 ‘디스크 검사’와 같은 정기적인 자동 점검 기능을 지원합니다. 이 기능을 활성화하여 매달 혹은 분기별로 주기적으로 실행하도록 설정해두는 것을 강력히 추천합니다. 이 과정에서 물리적인 디스크 오류뿐만 아니라, 파일 시스템 오류까지도 점검하고 복구할 수 있어요. 제 경험상, 이 자동 점검 기능 덕분에 디스크에 문제가 생기기 전에 미리 경고를 받아본 적이 여러 번 있었습니다. 🎉

    6. 마무리하며: 예방적 관리의 중요성

    오늘은 NAS 디스크 교체 후 SMART 모니터링에 대해 제 경험을 바탕으로 이야기해 보았습니다. 새 디스크를 장착하는 것도 중요하지만, 그 이후의 철저한 관리 없이는 소중한 데이터를 잃을 수도 있다는 걸 다시 한번 느꼈습니다. SMART 데이터는 디스크의 건강 상태를 파악하는 데 있어 가장 기본적인 도구이며, 이를 꾸준히 모니터링하고 정기적인 검사를 수행하는 것이 하드디스크 건강을 지키고 데이터 손실 방지를 위한 핵심입니다.

    앞으로는 SMART 데이터의 특정 값들에 더 주목하고, ‘Pending Sector’와 같은 잠재적 문제에 대해서도 좀 더 주의를 기울여야겠다는 다짐을 했습니다. 여러분도 NAS를 사용하신다면, SMART 모니터링을 습관화하시고 정기적인 디스크 검사를 꼭 챙기시길 바랍니다. 혹시 SMART 데이터 해석이나 NAS 관리 관련해서 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 저도 계속 배우고 경험하면서 여러분과 함께 성장하고 싶습니다! 다음 글에서는 NAS의 RAID 구성 방식에 따른 장단점과 어떤 상황에 어떤 RAID를 선택해야 하는지에 대해 더 자세히 다뤄보도록 하겠습니다.

    NAS 관리 및 데이터 백업 전략을 요약한 인포그래픽

    NAS 관리 및 데이터 백업 전략을 요약한 인포그래픽

  • [Proxmox] Proxmox Backup Server (PBS) 완벽 가이드: 설치부터 백업/복구 전략까지

    [Proxmox] Proxmox Backup Server (PBS) 완벽 가이드: 설치부터 백업/복구 전략까지

    [Proxmox] Proxmox Backup Server (PBS) 완벽 가이드: 설치부터 백업/복구 전략까지

    13년차 인프라 엔지니어의 Proxmox Backup Server (PBS) 삽질 & 활용기

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 Proxmox Backup Server (PBS), 줄여서 PBS에 대한 이야기를 해보려고 합니다. 사실 인프라 엔지니어에게 백업(Backup)은 아무리 강조해도 지나치지 않은 핵심 업무 중 하나잖아요? 저도 수많은 시스템을 운영하면서 “아차!” 싶었던 순간이 한두 번이 아니었습니다. 특히 홈랩에서 Proxmox VE(Virtual Environment)를 쓰면서 가상 머신(VM)이나 컨테이너(Container) 백업이 늘 고민이었는데, 이 PBS를 만나고 나서 드디어 마음의 평화를 찾았지 뭐예요? 🎉

    Proxmox VE를 사용하시는 분들이라면 기본적으로 제공되는 백업 기능도 꽤 유용하다는 걸 아실 거예요. 근데 이게 스케일이 커지거나, 데이터 중복 제거(Deduplication)나 증분 백업(Incremental Backup) 같은 고급 기능이 필요해지면 한계에 부딪히거든요. 그때 PBS가 진가를 발휘합니다. 오늘은 제가 직접 PBS를 설치하고, Proxmox VE와 연동해서 백업/복구 전략까지 세워본 경험을 솔직하게 공유해 드릴게요. 삽질 과정과 해결 팁도 아낌없이 풀어놓을 테니, 끝까지 함께해 주시면 분명 큰 도움이 되실 겁니다!

    Proxmox Backup Server의 전체 아키텍처는 Proxmox VE에서 PBS로 데이터를 보내고, PBS가 중복 제거 및 압축하여 백업 스토리지에 저장하는 과정을 시각적으로 보여줍니다.

    Proxmox Backup Server (PBS)란 무엇인가요?

    Proxmox Backup Server (PBS)는 Proxmox VE 환경에 최적화된 엔터프라이즈급 백업 솔루션입니다. 쉽게 말해, Proxmox VE 위에 돌아가는 수많은 VM이나 컨테이너의 데이터를 효율적으로 저장하고 관리하기 위해 태어난 녀석이라고 보시면 됩니다. 단순히 데이터를 복사해서 저장하는 것을 넘어, 여러 가지 똑똑한 기능들을 제공하죠.

    • 데이터 중복 제거 (Deduplication): 이게 PBS의 가장 강력한 기능 중 하나인데요. 동일한 데이터 블록이 여러 백업 이미지에 존재하더라도, PBS는 딱 한 번만 저장하고 나머지는 참조만 합니다. 덕분에 저장 공간을 엄청나게 절약할 수 있어요. 제가 직접 써보니, 특히 비슷한 OS 이미지로 여러 VM을 돌릴 때 그 효과가 대단하더라고요!
    • 증분 백업 (Incremental Backup): 첫 백업 이후에는 변경된 데이터 블록만 백업합니다. 이는 백업 시간을 단축시키고, 다시 한 번 저장 공간 효율성을 높여줍니다.
    • 데이터 무결성 검증 (Data Integrity Verification): 백업된 데이터가 손상되지 않았는지 정기적으로 검사할 수 있습니다. 백업은 저장하는 것만큼 ‘제대로 저장되었는지’ 확인하는 게 중요하잖아요? 이 기능 덕분에 안심하고 데이터를 맡길 수 있습니다.
    • 클라이언트-사이드 암호화 (Client-side Encryption): 백업 데이터는 클라이언트(Proxmox VE)에서 암호화되어 PBS로 전송됩니다. 덕분에 민감한 데이터도 안전하게 보관할 수 있죠.
    • 원격 동기화 (Remote Sync): 백업 데이터를 다른 PBS 서버로 동기화할 수 있어, 재해 복구(Disaster Recovery) 전략을 수립하는 데 아주 유용합니다.

    처음엔 그냥 NAS에 백업하면 되지 않나 싶었는데, PBS의 이런 기능들을 경험하고 나니 왜 전용 백업 솔루션이 필요한지 절실히 깨달았네요. 특히 중복 제거는 진짜 혁명적입니다. 💡

    Proxmox Backup Server 설치하기

    자, 그럼 이제 본격적으로 PBS를 설치해 볼까요? 저는 별도의 물리 서버나 가상 머신에 Proxmox Backup Server ISO 파일을 이용해서 설치하는 방법을 선호합니다. 안정적이고 깔끔하거든요. 여기서는 ISO를 이용한 설치 과정을 간략하게 설명해 드릴게요. (Proxmox VE 위에 컨테이너로 설치하는 방법도 있지만, 안정성을 위해 전용 OS 설치를 추천합니다.)

    1. ISO 다운로드 및 부팅: Proxmox 공식 웹사이트에서 PBS ISO 이미지를 다운로드하고, USB에 굽거나 VM에 마운트하여 부팅합니다.
    2. 설치 마법사 진행: 부팅 후 나타나는 설치 마법사를 따라 진행합니다.
      • Target Harddisk (대상 하드디스크): PBS가 설치될 디스크를 선택합니다. 저는 보통 OS용으로 작은 SSD 하나, 백업 데이터 저장용으로 큰 HDD/SSD를 따로 구성합니다.
      • Country (국가), Time zone (시간대): 대한민국, 서울을 선택해 줍니다.
      • Root Password (루트 비밀번호) & Email address (이메일 주소): 관리자 비밀번호를 설정하고, 알림을 받을 이메일 주소를 입력합니다.
      • Management Network Configuration (네트워크 설정): IP 주소, 넷마스크, 게이트웨이, DNS 서버를 설정합니다. 나중에 Proxmox VE에서 접근해야 하니, 고정 IP로 설정하는 것이 좋습니다.
    3. 설치 완료 및 재부팅: 모든 설정이 끝나면 설치가 시작되고, 완료되면 재부팅하라는 메시지가 나옵니다. 재부팅 후에는 웹 인터페이스에 접속할 수 있습니다.

    웹 인터페이스는 https://[PBS 서버 IP]:8007로 접속할 수 있습니다. 사용자 이름은 root이고, 비밀번호는 설치 시 설정한 비밀번호를 사용하면 됩니다. 처음 접속하면 왠지 모르게 뿌듯하더라고요! 🎉

    Proxmox Backup Server 웹 인터페이스에 로그인한 후의 대시보드 화면입니다. 시스템 상태와 저장소 현황을 한눈에 확인할 수 있습니다.

    Proxmox VE와 PBS 연동하기

    PBS를 설치했으니, 이제 Proxmox VE에서 이 녀석을 백업 저장소로 추가해야겠죠? 이 과정도 정말 간단합니다.

    1. Proxmox VE 웹 인터페이스 접속: 평소처럼 Proxmox VE 웹 관리 화면에 로그인합니다.
    2. 데이터센터(Datacenter) > 스토리지(Storage) 이동: 왼쪽 메뉴에서 Datacenter를 클릭하고, 그 아래의 Storage 탭으로 이동합니다.
    3. ‘추가(Add)’ 버튼 클릭 > ‘Proxmox Backup Server’ 선택: ‘Add’ 드롭다운 메뉴에서 ‘Proxmox Backup Server’를 선택합니다.
    4. 정보 입력: 다음 정보를 입력해 줍니다.
      • ID: 이 저장소의 이름을 지정합니다. (예: pbs-backup-storage)
      • Server: PBS 서버의 IP 주소 또는 도메인 이름을 입력합니다.
      • Username: root@pam (PBS의 기본 관리자 계정)
      • Password: PBS 설치 시 설정한 root 비밀번호
      • Datastore: PBS에서 생성된 데이터스토어 이름을 입력합니다. 기본값은 datastore1입니다. (PBS 웹 인터페이스의 ‘Datastore’ 메뉴에서 확인할 수 있습니다.)
      • Fingerprint (지문): PBS 서버의 SSH 지문입니다. 처음 연결할 때 자동으로 채워지거나, PBS 웹 인터페이스에서 확인할 수 있습니다. 보안을 위해 꼭 확인해 주세요.
    5. ‘추가(Add)’ 버튼 클릭: 모든 정보를 입력하고 ‘Add’ 버튼을 누르면 끝!

    제대로 연결되었다면, Proxmox VE의 스토리지 목록에 PBS가 나타나고, ‘Status’가 ‘Active’로 표시될 거예요. 이제 Proxmox VE의 VM이나 컨테이너를 백업할 때, 대상 저장소로 PBS를 선택할 수 있게 됩니다. ✅

    Proxmox VE에 Proxmox Backup Server를 스토리지로 추가하는 설정 화면입니다. Server IP, Username, Datastore 등의 정보를 입력하는 창이 보입니다.

    백업 전략 수립 및 실행

    저장소를 연결했으니, 이제 어떤 VM을 언제, 어떻게 백업할지 전략을 세울 차례입니다. Proxmox VE에서는 백업 스케줄을 아주 유연하게 설정할 수 있습니다.

    1. Datacenter > Backup (백업) 메뉴 이동: Proxmox VE 웹 인터페이스에서 ‘Datacenter’를 클릭하고 ‘Backup’ 탭으로 이동합니다.
    2. ‘Add (추가)’ 버튼 클릭: 새로운 백업 작업을 생성합니다.
    3. 백업 작업 설정:
      • Storage (저장소): 방금 추가한 PBS 저장소를 선택합니다. (예: pbs-backup-storage)
      • Schedule (스케줄): 백업이 실행될 시간을 설정합니다. 매일 새벽 2시, 매주 일요일 자정 등 원하는 대로 설정할 수 있습니다. (예: daily, weekly)
      • VMs (VM 선택): 백업할 VM이나 컨테이너를 선택합니다. ‘All’을 선택하거나 특정 VM ID를 지정할 수 있습니다.
      • Mode (모드): Snapshot을 선택하는 것이 일반적입니다. (VM이 실행 중인 상태에서 일관성 있는 백업을 생성할 수 있습니다.)
      • Compression (압축): 백업 데이터의 압축 방식을 선택합니다. 저는 보통 Zstandard (ZSTD)를 사용합니다. 빠르고 효율적이거든요.
      • Retention (보존 정책): 백업본을 얼마나 오래 보관할지 설정합니다. 예를 들어, ‘Keep last 7’로 설정하면 최근 7개의 백업본만 유지하고 오래된 것은 자동으로 삭제됩니다. 이 정책은 데이터스토어 용량 관리에도 아주 중요합니다.
      • Email notification (이메일 알림): 백업 성공/실패 여부를 이메일로 받아볼 수 있습니다. 중요한 기능이니 꼭 설정해 두세요!
    4. ‘Create (생성)’ 버튼 클릭: 백업 작업이 생성됩니다.

    이렇게 설정해두면, 정해진 시간에 PBS로 자동 백업이 진행됩니다. PBS 웹 인터페이스의 ‘Tasks’ 메뉴나 Proxmox VE의 ‘Task Log’에서 백업 진행 상황을 확인할 수 있습니다. 처음 백업이 성공했을 때의 그 쾌감이란! 💪

    데이터 복구, 이젠 걱정 마세요!

    백업은 언제나 ‘만약의 사태’를 대비하는 것이죠. 가장 중요한 건 백업된 데이터를 성공적으로 복구(Restore)할 수 있느냐입니다. PBS는 복구 과정도 직관적이고 빠릅니다.

    1. Proxmox VE 웹 인터페이스 접속: 복구할 VM이 있던 Proxmox VE 노드에 접속합니다.
    2. VM 선택 및 ‘백업(Backup)’ 탭 이동: 복구할 VM을 선택한 다음, ‘Backup’ 탭으로 이동합니다.
    3. 복구할 백업본 선택: PBS에 저장된 백업 목록이 나타납니다. 복구하고자 하는 특정 날짜와 시간의 백업본을 선택합니다.
    4. ‘복원(Restore)’ 버튼 클릭: 복원 옵션 대화 상자가 나타납니다.
      • Storage (저장소): 복원될 VM의 디스크가 저장될 Proxmox VE 스토리지(예: local-lvm)를 선택합니다.
      • VM ID: 기존 VM ID로 복원하거나, 새로운 VM ID를 지정하여 복원할 수 있습니다. 기존 VM이 손상된 경우 같은 ID로 복원하고, 테스트 목적으로 복원할 경우 새로운 ID로 복원하는 것이 일반적입니다.
      • Overwrite (덮어쓰기): 기존 VM이 있을 경우 덮어쓸지 여부를 결정합니다. 주의해서 사용해야 합니다!
    5. ‘복원(Restore)’ 버튼 클릭: 복구가 시작됩니다.

    복구 작업이 완료되면, 해당 VM이 Proxmox VE 목록에 나타나고, 정상적으로 부팅되는 것을 확인할 수 있습니다. 제가 실제로 몇 번 복구 테스트를 해봤는데, 정말 빠르고 안정적이더라고요. 특히 중복 제거 덕분에 복구 시간도 단축되는 느낌이었습니다. 👏

    ⚠️ 삽질 경험 & 트러블슈팅 팁

    제가 PBS를 사용하면서 겪었던 몇 가지 삽질 경험과 그 해결 팁을 공유해 드릴게요. 여러분은 저처럼 고생하지 마시라고요! ㅎㅎ

    • 방화벽 문제: Proxmox VE와 PBS가 서로 통신하려면 8007번 포트가 열려있어야 합니다. PBS 서버에 UFW(Uncomplicated Firewall)나 다른 방화벽이 설치되어 있다면, 꼭 8007번 포트를 허용해 주세요. 
      sudo ufw allow 8007/tcp
sudo ufw enable
sudo ufw status

      저는 처음에 포트 열어주는 걸 깜빡해서 “왜 연결이 안 되지?” 하고 한참 헤맸거든요. 😅

    • Datastore(데이터스토어) 설정 오류: PBS 설치 후 Datastore를 생성하지 않거나, Proxmox VE에서 입력하는 Datastore 이름이 PBS의 Datastore 이름과 다르면 연결이 안 됩니다. PBS 웹 인터페이스에서 ‘Datastore’ 메뉴를 확인하고 정확한 이름을 입력해야 합니다. 기본값은 datastore1이지만, 직접 이름을 바꿨다면 그 이름을 써야 해요.
    • 스토리지 용량 부족: 아무리 중복 제거가 뛰어나도 백업본이 쌓이면 결국 용량이 부족해집니다. PBS 웹 인터페이스에서 ‘Datastore’ > ‘Prune & GC’ 탭을 활용하여 가지치기(Prune)와 가비지 컬렉션(Garbage Collection) 스케줄을 설정해 주세요. Prune은 오래된 백업본을 삭제하는 정책이고, GC는 삭제된 데이터 블록을 실제로 정리해서 공간을 회수하는 작업입니다. 이걸 안 해주면 삭제된 백업본이 실제 공간을 계속 차지하고 있을 수 있습니다.
    • 네트워크 대역폭 문제: 동시에 여러 VM을 백업하거나, 대용량 VM을 백업할 경우 네트워크 대역폭이 충분하지 않으면 백업 시간이 엄청나게 길어질 수 있습니다. 1Gbps 네트워크 환경이라면 큰 문제가 없지만, 가능하다면 백업 전용 네트워크를 구성하거나 10Gbps 네트워크를 고려해볼 만합니다.

    Proxmox Backup Server의 주요 기능인 데이터 중복 제거, 압축, 암호화, 데이터 무결성 검증을 시각적으로 요약한 인포그래픽입니다.

    마무리하며: PBS, 인프라 엔지니어의 든든한 동반자

    오늘은 Proxmox Backup Server (PBS)에 대해 설치부터 Proxmox VE 연동, 백업/복구 전략, 그리고 제가 겪었던 삽질 경험까지 자세히 이야기해 드렸습니다. 13년차 인프라 엔지니어로서 여러 백업 솔루션을 경험해 봤지만, Proxmox 환경에서는 PBS만큼 효율적이고 안정적인 솔루션은 찾기 힘들다고 생각합니다.

    특히 데이터 중복 제거와 증분 백업 기능은 저장 공간을 아끼는 데 큰 도움이 되었고, 직관적인 웹 인터페이스 덕분에 관리도 정말 편했습니다. 여러분도 Proxmox VE를 사용하고 계시다면, PBS 도입을 적극적으로 고려해 보시길 강력히 추천합니다. 처음엔 좀 낯설게 느껴질 수도 있지만, 한 번 세팅해두면 든든한 백업 시스템이 될 거예요. 든든한 백업 시스템 구축으로 여러분의 소중한 데이터를 지켜내시길 바랍니다!

    다음번에는 PBS의 원격 동기화(Remote Sync) 기능을 활용한 재해 복구(DR) 전략에 대해 더 깊이 다뤄볼까 합니다. 기대해 주세요! 😉

  • [Proxmox VE] VM 백업 및 복구 완벽 가이드: 데이터 손실 방지 전략

    [Proxmox VE] VM 백업 및 복구 완벽 가이드: 데이터 손실 방지 전략

    목차

    [Proxmox VE] VM 백업 및 복구 완벽 가이드: 데이터 손실 방지 전략

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 Proxmox VE(Virtual Environment) 환경에서 VM(Virtual Machine) 백업과 복구에 대한 이야기를 좀 해볼까 합니다. 서버실에서 13년을 굴러보니, 데이터만큼 중요한 게 없더라고요. 한 번의 실수로 데이터가 날아가면 정말 아찔하죠. 특히 홈랩(Home Lab)을 운영하면서 이것저것 실험하다 보니 백업의 중요성을 뼈저리게 느끼게 됩니다. 😱

    저도 예전에 백업을 소홀히 했다가 중요한 설정 파일이나 프로젝트 데이터가 통째로 날아간 경험이 있거든요. 그때의 허탈함이란… 그래서 Proxmox VE VM 백업은 선택이 아니라 필수라고 항상 강조합니다. 오늘은 제가 직접 홈랩에서 Proxmox를 운영하며 겪었던 경험을 바탕으로, 어떻게 하면 안전하게 Proxmox 백업을 설정하고, 위기 상황에서 VM 복구를 할 수 있는지, 그 데이터 손실 방지 전략을 완벽하게 알려드릴게요. 저와 함께 Proxmox 스냅샷을 포함한 다양한 데이터 보호 방법을 알아봅시다!

    Proxmox VE VM 백업 및 복구 전체 아키텍처 다이어그램

    Proxmox 백업, 진짜 왜 중요할까요? (개념 설명)

    쉽게 말해, Proxmox VE 환경에서 VM 백업은 우리 집의 귀한 물건들을 금고에 넣어두는 것과 같습니다. 언제든 문제가 생기면 금고에서 다시 꺼내 쓸 수 있도록 말이죠. Proxmox는 기본적으로 아주 강력한 백업 기능을 제공하고 있거든요.

    VZDump: Proxmox의 핵심 백업 도구

    Proxmox에는 vzdump라는 백업 툴이 내장되어 있습니다. 이 툴로 VM(QEMU/KVM)과 LXC 컨테이너를 효율적으로 백업할 수 있거든요. 백업 시점에 VM의 모든 상태(디스크 이미지, 설정 파일 등)를 하나의 파일로 만들어주고, 나중에 복구할 때 사용하죠.

    스냅샷(Snapshot)과 백업(Backup)의 차이

    여기서 많은 분들이 헷갈리시는 게 스냅샷과 백업입니다. 저도 처음엔 이게 뭔가 싶었거든요. 간단히 비유하자면:

    • 스냅샷(Snapshot): 책갈피 같은 거예요. 특정 시점의 VM 상태를 빠르게 저장하고, 문제가 생겼을 때 그 시점으로 되돌아갈 수 있게 해줍니다. 하지만 스냅샷은 원본 VM과 같은 스토리지에 존재하기 때문에, 스토리지 자체가 손상되면 스냅샷도 같이 날아갈 위험이 있어요.
    • 백업(Backup): 책 전체를 복사해서 다른 안전한 장소에 보관하는 거라고 생각하시면 됩니다. 원본 VM과는 완전히 분리된 별도의 백업 스토리지에 저장되므로, 원본 VM이 손상되더라도 안전하게 복구할 수 있죠.

    결론적으로, 스냅샷은 빠른 롤백(Rollback)에 좋고, 백업은 데이터 손실 방지와 재해 복구(Disaster Recovery, DR)에 필수적입니다.

    어떤 백업 스토리지를 사용할까?

    Proxmox는 다양한 백업 스토리지를 지원하거든요. 제가 홈랩에서 주로 쓰는 방식은 NFS(Network File System)나 SMB/CIFS(Server Message Block/Common Internet File System) 공유 스토리지를 사용하는 겁니다. 아니면 Proxmox Backup Server(PBS)를 구축해서 쓰는 방법도 있는데, 이건 정말 끝판왕이라고 할 수 있죠.

    Proxmox VE VM 백업 및 복구 실전 구현 (단계별 가이드)

    자, 이제 실전입니다. 제가 직접 쓰는 방법들을 단계별로 보여드릴게요. Proxmox 웹 GUI를 주로 활용하겠지만, CLI(Command Line Interface) 명령어 몇 가지도 함께 알아두시면 좋습니다.

    1단계: 백업 스토리지 추가하기 (NFS 예시)

    가장 먼저 백업 파일을 저장할 공간을 Proxmox에 연결해야 합니다. 저는 NAS(Network Attached Storage)에 NFS 공유 폴더를 만들어서 사용하고 있거든요.

    1. Proxmox 웹 GUI에 접속합니다.
    2. 좌측 메뉴에서 Datacenter > Storage로 이동합니다.
    3. Add 버튼을 클릭하고 NFS를 선택합니다.

    4. 다음 정보를 입력합니다:

      • ID: backup-nfs (원하는 이름)
      • Server: 192.168.1.100 (NAS IP 주소)
      • Export: /volume1/proxmox-backup (NAS의 NFS 공유 경로)
      • Content: VZDump backup file (필수!)
    5. Add 버튼을 눌러 추가를 완료합니다.

    CLI로 직접 마운트하는 방법도 있어요. 예를 들어, /etc/fstab에 추가해서 부팅 시 자동 마운트되도록 설정할 수 있습니다.

    
# /etc/fstab
192.168.1.100:/volume1/proxmox-backup /mnt/pve/backup-nfs nfs defaults 0 0

    그리고 mount -a 명령어로 바로 적용해줍니다. 그 후 Proxmox GUI에서 Storage를 추가하면 되는데, 이 방법이 좀 더 안정적이더라고요.

    Proxmox VE 웹 GUI 백업 작업 설정 화면

    2단계: 백업 작업 생성 및 스케줄링

    스토리지를 연결했으니 이제 Proxmox 백업 작업을 만들어볼까요?

    1. Datacenter > Backup으로 이동합니다.
    2. Add 버튼을 클릭하여 새 백업 작업을 생성합니다.

    3. 백업 설정:

      • Node: 백업할 VM이 있는 Proxmox 노드 선택 (All도 가능)
      • Storage: 1단계에서 추가한 backup-nfs 선택
      • Schedule: Daily (매일), Weekly (매주) 등 원하는 주기로 설정합니다. 저는 새벽 2시에 매일 돌리도록 설정해놓았어요.
      • VMs: 백업할 VM 선택 (All 또는 특정 VM ID)
      • Mode: Snapshot (가장 권장하는 방식입니다. VM 운영 중에도 백업 가능)
      • Compression: Zstd (최신 알고리즘으로 압축률과 속도 모두 좋습니다)
      • Email notification: 백업 결과 알림을 받을 이메일 주소 설정 (필수!)
      • Retention: 백업본 유지 기간. 저는 보통 7일로 설정해서 일주일치 백업본을 가지고 있습니다.
    4. Create 버튼을 눌러 백업 작업을 완료합니다.

    이렇게 하면 설정한 스케줄에 따라 자동으로 Proxmox VE VM 백업이 진행돼요. 정말 편하더라고요!

    3단계: VM 복구하기

    불의의 사고로 VM이 날아갔다거나, 특정 시점으로 되돌리고 싶을 때 VM 복구는 필수입니다. Proxmox는 복구도 아주 간단하게 할 수 있게 해줍니다.

    1. 좌측 메뉴에서 Datacenter > Storage > backup-nfs (백업 스토리지를 선택)로 이동합니다.
    2. 중앙 패널에서 백업된 파일 목록을 볼 수 있어요. 복구하려는 VM의 백업 파일을 선택합니다.
    3. Restore 버튼을 클릭합니다.

    4. 복구 설정:

      • Target Storage: VM이 복구될 스토리지 선택 (예: local-lvm)
      • VM ID: 새 VM ID를 지정하거나, 기존 VM ID로 덮어쓸 수 있습니다. 기존 ID로 덮어쓸 경우 기존 VM은 삭제되니 주의하세요!
      • Start after restore: 복구 완료 후 바로 VM을 시작할지 여부
    5. Restore 버튼을 눌러 복구를 시작합니다.

    CLI로 복구하는 방법도 있어요. 만약 웹 GUI에 접근할 수 없는 상황이라면 유용하겠죠?

    
# 백업 파일 경로 확인 (예: /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2023_10_26-02_00_01.vma.zst)
# 새 VM ID 101로 복구 (기존 VM ID와 겹치지 않게)
qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2023_10_26-02_00_01.vma.zst 101 --storage local-lvm

# 만약 기존 VM ID 100에 덮어쓰려면 (기존 VM 삭제 후)
# qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2023_10_26-02_00_01.vma.zst 100 --storage local-lvm --force

    --force 옵션은 기존 VM을 삭제하고 복구하는 거라서 정말 신중하게 사용해야 합니다!

    ⚠️ 주의사항 및 트러블슈팅: 삽질 경험 공유

    제가 13년 동안 삽질하면서 배웠던 Proxmox 데이터 보호에 대한 몇 가지 팁과 주의사항을 공유합니다. 홈랩이든 실제 서버든 똑같더라고요.

    백업 스토리지 용량 부족

    저도 처음엔 무작정 백업 돌렸다가 백업 스토리지가 꽉 차서 난리 났었죠. 😅 정기적으로 백업 스토리지 용량을 확인하고, Retention 정책을 잘 설정해서 오래된 백업본은 자동으로 삭제되도록 해야 합니다. 아니면 Proxmox Backup Server(PBS)를 쓰면 중복 제거(Deduplication) 기능 덕분에 용량 효율이 훨씬 좋아지더라고요. 이건 나중에 기회가 되면 더 자세히 다뤄볼게요.

    백업 일관성 (Consistency) 문제

    Snapshot 모드로 백업하면 VM이 실행 중인 상태에서 백업이 이루어지기 때문에 편리해요. 하지만 이 방식은 파일 시스템 일관성(Filesystem-consistent)은 보장하지만, 애플리케이션 일관성(Application-consistent)은 보장하지 못할 수 있거든요. 예를 들어, 데이터베이스 서버 같은 경우 백업 시점에 트랜잭션이 진행 중이었다면, 복구 후 데이터베이스에 문제가 생길 수도 있습니다. 중요한 서비스라면 백업 전에 잠시 서비스를 중단하거나, VM 내부에서 VSS(Volume Shadow Copy Service) 등을 활용하는 방법을 고려해야 합니다.

    네트워크 대역폭과 복구 시간

    백업이나 복구 시 네트워크 대역폭이 충분하지 않으면 시간이 오래 걸릴 수 있어요. 특히 대용량 VM을 복구할 때는 정말 답답하더라고요. 10GbE(기가비트 이더넷) 같은 고속 네트워크를 구축해두면 훨씬 쾌적합니다.

    VM ID 충돌

    복구 시 새 VM ID를 지정하지 않고, 이미 사용 중인 ID로 복구하려고 하면 에러가 발생해요. qmrestore 명령어를 쓸 때는 반드시 기존에 사용하지 않는 VM ID를 지정하거나, 정말 덮어써야 할 경우에만 --force 옵션을 사용해야 합니다.

    백업 및 복구 결과 확인 (검증)

    백업이 잘 됐는지, 복구된 VM이 제대로 작동하는지 확인하는 게 진짜 중요해요. 저는 예전에 백업은 잘 했는데, 복구 테스트를 안 해봤다가 나중에 문제가 생겨서 애먹었던 적이 있거든요. 백업만큼이나 복구 검증도 필수입니다!

    1. 백업 로그 확인: Proxmox 웹 GUI의 Datacenter > Task Log에서 백업 작업의 성공 여부를 확인할 수 있습니다. 오류가 발생했다면 로그를 자세히 살펴보세요.
    2. 복구된 VM 정상 작동 확인: 복구된 VM을 시작하고, 서비스가 정상적으로 올라오는지, 네트워크 연결은 잘 되는지, 데이터는 모두 유효한지 꼼꼼히 확인해야 합니다. 가능하다면 주기적으로 복구 테스트를 진행해보는 게 좋습니다.

    Proxmox VE 백업 작업 로그 및 성공 기록 확인 화면

    Proxmox 백업 모드별 장단점 비교

    Proxmox에서 VM 백업 시 선택할 수 있는 주요 모드들의 장단점을 정리해봤습니다. 어떤 상황에 어떤 모드를 쓰는 게 좋을지 판단하는 데 도움이 되실 거예요.

    백업 모드 (Mode) 설명 장점 단점
    Snapshot VM이 실행 중인 상태에서 스냅샷을 찍고 백업합니다. VM 서비스 중단 없음, 가장 편리함. 애플리케이션 일관성 보장 어려움, 스냅샷 생성/삭제 오버헤드.
    Suspend VM을 잠시 일시 중지(Suspend)한 후 백업합니다. 파일 시스템 일관성 보장, 스냅샷보다 안전. VM 서비스가 잠시 중단됨 (수 초 ~ 수십 초).
    Stop VM을 완전히 중지(Stop)한 후 백업합니다. 가장 높은 데이터 일관성 보장. VM 서비스가 백업 시간 동안 완전히 중단됨.

    대부분의 홈랩이나 중요도가 아주 높지 않은 서비스는 Snapshot 모드로도 충분해요. 하지만 금융 시스템처럼 데이터 일관성이 절대적으로 중요한 곳에서는 Stop 모드를 고려하거나, VM 내부에서 정교한 백업 스크립트를 돌려야 하겠죠.

    Proxmox VE 백업 모드별 장단점 비교 인포그래픽

    마무리: 데이터 보호는 기본 중의 기본입니다!

    오늘은 Proxmox VE 환경에서 VM 백업 및 복구에 대해 자세히 알아봤습니다. 제가 13년간 서버실에서 일하며 느낀 점은, 기술이 아무리 발전해도 데이터 보호의 중요성은 변치 않는다는 거예요. 백업은 주기적으로, 복구는 빠르게! 이 두 가지 원칙만 잘 지키면 소중한 데이터를 안전하게 지킬 수 있습니다.

    오늘 다룬 내용이 여러분의 Proxmox 환경 데이터 보호 전략을 세우는 데 큰 도움이 되었기를 바랍니다. 다음번에는 Proxmox Backup Server(PBS)를 활용한 더 강력한 백업 전략이나, Proxmox 클러스터 구성에 대한 이야기로 찾아올게요. 혹시 궁금한 점이나, 제가 겪었던 삽질 경험 중 더 듣고 싶은 이야기가 있다면 언제든 댓글로 남겨주세요! 😊

  • [Nas] NAS RAID 설정 트러블슈팅: 문제 진단부터 데이터 복구까지 완벽 가이드

    목차

    NAS RAID 문제, 언제 터질지 아무도 모릅니다

    새벽 2시, 갑자기 NAS에서 삐~ 소리가 납니다. 이메일 알림이 쏟아지고, “RAID degraded” 메시지가 화면을 가득 채웁니다. 13년 동안 인프라를 관리해오면서 이런 상황을 몇 번이나 겪었는지 모릅니다. 처음엔 손이 덜덜 떨리더니, 지금은 “아, 또 왔네” 하면서 커피 한 잔 내리고 시작합니다 ㅎㅎ

    NAS RAID 문제 해결은 제때 대응하면 데이터를 살릴 수 있지만, 잘못 건드리면 멀쩡한 디스크까지 날릴 수 있는 위험한 작업입니다. 이 글에서는 제가 직접 겪었던 RAID 설정 오류 상황들과 그 해결 과정을 솔직하게 풀어드리려고 합니다. 혹시 지금 NAS 화면에 빨간 경고등이 켜져 있다면, 일단 침착하게 이 글을 읽어보세요.

    ▲ NAS RAID 구성과 트러블슈팅 흐름도 — 디스크 오류 감지부터 데이터 복구까지의 전체 과정

    RAID가 뭔지 다시 한번 짚고 갑시다

    RAID(Redundant Array of Independent Disks, 독립 디스크 중복 배열)는 쉽게 말해 여러 개의 하드디스크를 하나처럼 묶어서 사용하는 기술입니다. 홈랩에서 Synology나 QNAP NAS를 쓰시는 분들은 대부분 이미 RAID를 사용 중이시죠.

    NAS에서 자주 쓰는 RAID 레벨을 표로 정리해봤습니다:

    RAID 레벨 최소 디스크 특징 허용 고장 디스크 수
    RAID 0 2개 스트라이핑, 성능 최우선 0개 (하나라도 고장 시 전멸)
    RAID 1 2개 미러링, 완전 복제 1개
    RAID 5 3개 패리티 분산, 균형잡힌 선택 1개
    RAID 6 4개 이중 패리티, 안전성 강화 2개
    RAID 10 4개 미러링 + 스트라이핑 각 미러 그룹에서 1개씩

    홈랩에서는 RAID 5나 RAID 1을 많이 쓰시는데, 저도 홈 NAS는 RAID 5로, 중요한 백업 NAS는 RAID 6으로 운영하고 있습니다. RAID 6는 디스크 2개가 동시에 나가도 버티거든요. 비용이 좀 더 들지만 마음이 훨씬 편해요.

    이런 증상이 보이면 RAID에 문제가 생긴 겁니다

    NAS RAID 오류는 보통 세 가지 형태로 나타납니다. 제가 경험했던 증상들을 솔직하게 정리해봤어요.

    1. Degraded 상태 (성능 저하 상태)

    가장 흔한 케이스입니다. 디스크 하나가 고장났지만 아직 RAID는 동작 중인 상태예요. RAID 5 기준으로 디스크 1개가 빠진 거죠. 이 상태에선 데이터는 멀쩡히 접근되는데, 지금 당장 추가 디스크 고장이 나면 데이터 전멸이라는 공포 속에 살게 됩니다.

    증상: NAS 관리 페이지에서 노란색/주황색 경고등, 이메일 알림, 느려진 전송 속도

    2. Failed 상태 (완전 실패 상태)

    RAID 어레이 자체가 죽어버린 상태입니다. RAID 5에서 디스크 2개 이상이 나가거나, RAID 1에서 2개 모두 나간 경우예요. 이럴 땐 데이터에 접근 자체가 안 됩니다. 처음 이 상황을 겪었을 때 솔직히 멍하더라고요 ㅎㅎ

    3. Rebuild 중 추가 오류 (최악의 시나리오)

    새 디스크로 RAID를 복구(리빌드)하는 중에 또 다른 디스크가 나가는 케이스. 제가 경험한 것 중에 가장 심장이 쫄깃했던 상황이었습니다. 리빌드 중에는 I/O가 엄청 늘어나서 이미 약해진 디스크에 스트레스를 더 주거든요.

    NAS RAID 트러블슈팅 단계별 가이드

    자, 이제 본격적으로 RAID 설정 문제를 어떻게 해결하는지 단계별로 알아보겠습니다. 급한 마음에 막 건드리다가 더 큰 일 납니다. 순서대로 차근차근 따라오세요.

    ▲ Synology NAS 스토리지 매니저에서 확인하는 RAID 어레이 상태 및 디스크 health 정보 화면

    Step 1: 현재 상태 정확히 파악하기

    먼저 NAS CLI(명령줄 인터페이스)에 접속해서 현재 RAID 상태를 정확히 봐야 합니다. Linux 기반 NAS라면 대부분 mdadm(MD RAID 관리 도구)을 사용합니다.

    # 현재 RAID 어레이 상태 확인
cat /proc/mdstat

# 특정 어레이 상세 정보
mdadm --detail /dev/md0

# 모든 어레이 스캔
mdadm --detail --scan

    cat /proc/mdstat 결과를 보면 이런 식으로 나와요:

    Personalities : [raid5] [raid6]
md0 : active raid5 sda1[0] sdc1[2] sdd1[3]
      [3/4] [UUU_]    # 언더스코어(_)가 문제 디스크 위치!

# U = 정상, _ = 고장/누락

    이 출력에서 [UUU_]처럼 언더스코어가 보이면, 그 위치의 디스크에 문제가 생긴 겁니다. 여기선 sdb가 빠진 거죠.

    Step 2: 디스크 S.M.A.R.T. 진단 실행

    SMART(Self-Monitoring, Analysis and Reporting Technology, 자가 모니터링 기술)로 각 디스크의 건강 상태를 체크합니다. 이걸 먼저 봐야 어떤 디스크가 진짜 고장인지, 아니면 일시적 오류인지 파악할 수 있어요.

    # SMART 빠른 테스트 (2~5분 소요)
smartctl -t short /dev/sdb

# 테스트 결과 확인
smartctl -a /dev/sdb | grep -E "SMART|Reallocated|Pending|Uncorrectable"

# 전체 상세 정보 출력
smartctl -a /dev/sdb

    주목해야 할 SMART 항목들:

    • Reallocated Sectors Count: 재할당된 섹터 수. 이게 높으면 디스크가 슬슬 죽어가는 중
    • Pending Sectors: 아직 재할당 대기 중인 불량 섹터
    • Uncorrectable Errors: 수정 불가능한 오류. 0이어야 정상
    • Power On Hours: 누적 가동 시간. 너무 오래됐으면 교체 고려

    Step 3: 오류 로그 분석

    시스템 로그에서 디스크 오류의 흔적을 찾아봅니다.

    # 시스템 로그에서 디스크 관련 오류 검색
dmesg | grep -E "error|failed|I/O" | tail -50

# syslog에서 RAID 관련 이벤트
grep -E "md|raid|disk" /var/log/syslog | tail -100

    여기서 찾아야 할 것: I/O error, read error, medium error 같은 메시지들. 이 오류들이 특정 디스크(sdb, sdc 등)에 집중된다면 그 디스크가 범인입니다.

    Step 4: 고장 디스크 교체 및 RAID 재구성

    원인 파악이 끝났으면 교체 작업을 시작합니다. 핫스왑(Hot-swap, 전원을 켠 채로 디스크 교체)이 지원되는 NAS라면 더 간단합니다.

    1. 문제 디스크를 어레이에서 제거
    # 고장 디스크를 어레이에서 제거
mdadm /dev/md0 --fail /dev/sdb1
mdadm /dev/md0 --remove /dev/sdb1
    1. 물리적으로 디스크 교체 (핫스왑 지원 시 전원 유지 가능)
    2. 새 디스크 파티션 구성
    # 기존 디스크 파티션 구조 확인
fdisk -l /dev/sda

# 기존 디스크의 파티션 테이블을 새 디스크에 복사
sfdisk -d /dev/sda | sfdisk /dev/sdb

# 파티션 확인
fdisk -l /dev/sdb
    1. 새 디스크를 어레이에 추가 (리빌드 시작)
    # 새 디스크를 어레이에 추가
mdadm /dev/md0 --add /dev/sdb1

# 리빌드 진행 상황 모니터링
watch -n5 cat /proc/mdstat

    리빌드 진행 중엔 이런 화면이 보입니다:

    md0 : active raid5 sdb1[4] sda1[0] sdc1[2] sdd1[3]
      [4/4] [UUUU]
      [==========>.......]  recovery = 47.3% (...)
      finish=142.3min speed=123456K/sec

    ⚠️ 경고: 리빌드 중에는 절대로 NAS를 재부팅하거나 전원을 끄지 마세요! 가능하면 다른 서비스 사용을 최소화해서 디스크 부하를 줄이는 게 좋습니다.

    데이터 복구: RAID가 완전히 실패한 경우

    만약 RAID 어레이 자체가 죽어버렸다면? 이건 더 복잡한 상황이지만 포기하지 마세요. 제가 실제로 고객사 서버에서 RAID 5 어레이가 완전히 죽은 상황에서 데이터를 살려낸 경험이 있습니다.

    방법 1: mdadm으로 어레이 재조립 시도

    # 슈퍼블록 정보 스캔 (각 디스크에서)
mdadm --examine /dev/sda1
mdadm --examine /dev/sdb1
mdadm --examine /dev/sdc1

# 어레이 재조립 시도
mdadm --assemble --scan /dev/md0

# 슈퍼블록 손상 시 강제 조립 (마지막 수단!)
mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1

    근데 여기서 중요한 포인트! –force 옵션은 정말 마지막 수단으로 써야 합니다. 잘못 쓰면 더 꼬일 수 있어요.

    방법 2: 디스크 이미지 먼저 뜨기 (필수!)

    데이터 복구 작업 전에 반드시 디스크 이미지를 먼저 떠두세요. 복구 작업 자체가 실패할 경우를 대비한 보험입니다.

    # ddrescue로 디스크 이미지 생성 (오류 내성이 좋음)
# apt-get install gddrescue 로 설치
ddrescue -f -n /dev/sda /mnt/backup/sda.img /mnt/backup/sda.log

# 2회차 (첫 번째 패스에서 실패한 섹터 재시도)
ddrescue -d -f -r3 /dev/sda /mnt/backup/sda.img /mnt/backup/sda.log

# 이미지 마운트 후 파일 접근
mount -o loop,ro /mnt/backup/sda.img /mnt/recovered

    dd보다 ddrescue가 훨씬 좋은 이유는, 불량 섹터를 만나도 거기서 멈추지 않고 계속 진행하면서 나중에 다시 시도하거든요. 저도 처음엔 그냥 dd만 썼다가 오류 나서 멈추는 바람에 삽질했었습니다 ㅎㅎ

    방법 3: TestDisk / PhotoRec 활용

    mdadm으로 안 된다면 오픈소스 복구 도구를 써볼 수 있습니다.

    # TestDisk 설치 및 실행 (파티션 테이블 복구)
apt-get install testdisk
testdisk /dev/sda

# PhotoRec (파일 시그니처 기반 복구)
photorec /dev/sda

    TestDisk는 파티션 테이블과 파일시스템 복구에 특화되어 있고, PhotoRec은 이미 손상된 파일을 카빙(carving, 파일 시그니처 기반 복구)해서 건져냅니다. 포맷이 됐더라도 꽤 건져낼 수 있어요.

    ▲ ddrescue를 이용한 디스크 이미지 생성 과정과 복구율 실시간 모니터링 화면

    자주 발생하는 NAS RAID 설정 문제와 해결법

    문제 1: RAID 리빌드가 너무 느려요

    리빌드 속도가 답답할 때 튜닝할 수 있는 방법입니다:

    # 현재 리빌드 속도 한계 확인 (KB/s 단위)
cat /proc/sys/dev/raid/speed_limit_max
cat /proc/sys/dev/raid/speed_limit_min

# 일시적으로 속도 제한 높이기
echo 300000 > /proc/sys/dev/raid/speed_limit_max
echo 100000 > /proc/sys/dev/raid/speed_limit_min

    💡 팁: 속도를 높이면 시스템 전체 성능에 영향을 줍니다. 업무 시간 이후에 속도 올리고, 낮에는 낮추는 방식으로 운영하면 좋아요.

    문제 2: 디스크는 정상인데 어레이가 Degraded

    가끔 디스크 자체는 멀쩡한데 어레이에서 빠지는 경우가 있습니다. 케이블 불량이나 컨트롤러 문제일 수 있어요.

    # 해당 디스크 슈퍼블록 확인
mdadm --examine /dev/sdb1

# 케이블/슬롯 점검 후 수동으로 다시 추가
mdadm --manage /dev/md0 --add /dev/sdb1

    문제 3: 파일시스템 오류 (RAID는 정상인데 마운트 안 됨)

    RAID 어레이 자체는 살아있는데 그 위의 파일시스템이 손상된 경우입니다.

    # ext4 파일시스템 검사 및 복구
# 반드시 언마운트 상태에서 실행!
fsck.ext4 -y /dev/md0

# XFS 파일시스템
xfs_repair /dev/md0

# Btrfs 파일시스템
btrfs check --repair /dev/md0

    ⚠️ fsck는 절대로 마운트된 파일시스템에 실행하면 안 됩니다. 더 크게 망가집니다. 꼭 언마운트 후에!

    문제 4: 재부팅 후 어레이가 자동으로 올라오지 않음

    mdadm 설정 파일에 어레이 정보가 없어서 생기는 문제입니다.

    # mdadm 설정 파일 재생성
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

# 내용 확인
cat /etc/mdadm/mdadm.conf

# initramfs 업데이트 (Debian/Ubuntu)
update-initramfs -u

    RAID가 있어도 백업은 필수입니다 (제발요)

    13년 동안 인프라 일을 하면서 가장 많이 강조한 말이 있습니다: “RAID는 백업이 아닙니다.”

    RAID는 디스크 고장에 대한 가용성(availability)을 제공하지, 데이터 보호 자체를 보장하는 게 아닙니다. 다음 시나리오는 RAID로 막을 수 없어요:

    • 실수로 파일 삭제 → 전체 어레이에 즉시 반영됨
    • 랜섬웨어 감염 → 마운트된 모든 파일이 암호화됨
    • NAS 본체 고장 (화재, 침수, 전원 서지)
    • RAID 컨트롤러 고장으로 메타데이터 손상

    3-2-1 백업 원칙(3개의 복사본, 2가지 다른 미디어, 1개는 오프사이트)은 NAS RAID 운영에서도 기본 중의 기본입니다. 다음 글에서는 홈랩 NAS의 효율적인 백업 전략을 자세히 다룰 예정이니 참고하세요.

    ▲ NAS RAID 트러블슈팅 핵심 체크리스트와 3-2-1 백업 전략 요약 인포그래픽

    정리: NAS RAID 트러블슈팅 핵심 체크리스트

    마지막으로 RAID 문제가 생겼을 때 기억해야 할 핵심을 정리합니다.

    상황 우선 조치 주의사항
    RAID Degraded SMART 체크 → 고장 디스크 확인 후 교체 리빌드 전 백업 상태 반드시 확인
    RAID Failed 디스크 이미지 생성 → 복구 도구 활용 원본 디스크 보존, 복사본으로만 작업
    리빌드 중 추가 오류 즉시 중단 → 전문 복구 도구 또는 전문가 추가 작업 금지, 디스크 이미지 우선
    파일시스템 오류 언마운트 후 fsck 실행 마운트 상태에서 fsck 절대 금지
    자동 마운트 실패 mdadm.conf 재생성 후 initramfs 업데이트 설정 파일 백업 습관화

    NAS RAID 트러블슈팅은 경험이 쌓일수록 훨씬 침착하게 대응할 수 있게 됩니다. 처음엔 무섭지만, 체계적으로 접근하면 대부분의 상황은 해결됩니다. 중요한 건 패닉하지 말고 순서대로 진행하는 것이에요.

    혹시 지금 당장 NAS RAID 문제를 겪고 계신가요? 댓글로 상황을 공유해주시면 같이 해결해봅시다. 이런 거 함께 나누는 게 커뮤니티의 힘이라고 생각하거든요.