13년차의 서버실

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

[태그:] NAS 백업 전략

  • [NAS] NAS 스냅샷 복구 실패 원인과 예방 전략

    [NAS] NAS 스냅샷 복구 실패 원인과 예방 전략

    [NAS] NAS 스냅샷 복구 실패 원인과 예방 전략

    NAS 스냅샷 복구 실패, 이거 한 번 겪어보면 진짜 등골이 서늘해집니다. 저도 홈랩(Home Lab, 집에서 운영하는 개인 실험실)에서 파일 서버를 굴리면서 “스냅샷(Snapshot, 특정 시점의 데이터 상태를 보존한 복구 지점) 있으니까 괜찮겠지” 하고 마음 놓고 있었거든요. 근데 막상 복구를 눌렀는데 원하는 시점으로 안 돌아가거나, 권한이 꼬이거나, 공유 폴더는 살아 있는데 내부 데이터가 기대한 상태가 아닌 경우가 있었습니다. 그때 느꼈습니다. 스냅샷이 있다고 해서 곧바로 복구가 보장되는 건 아니다라는 걸요.

    이번 글에서는 NAS 스냅샷 복구 실패가 왜 생기는지, 어떤 전제조건을 놓치면 복구가 틀어지는지, 그리고 실제 운영에서 NAS 데이터 복구 성공률을 높이려면 무엇을 미리 점검해야 하는지 정리해보겠습니다. 제품 홍보성 이야기가 아니라, 인프라 엔지니어 관점에서 “어디서 사고가 나는지”를 기준으로 풀어볼게요. 혹시 백업은 해두셨는데 복구 테스트는 안 해보신 분이라면, 여기서 중요한 포인트 꼭 챙기시면 좋겠습니다.

    NAS 스냅샷 복구 실패를 설명하는 홈랩 스토리지 아키텍처 이미지

    스냅샷, 백업, 원본 데이터, 외부 백업 저장소의 관계를 한눈에 보여주는 개요 이미지입니다.

    1. NAS 스냅샷 복구 실패가 자주 생기는 이유

    처음엔 저도 스냅샷을 거의 만능 복구 장치처럼 봤습니다. 쉽게 말해 버튼 하나로 과거 시점으로 되돌리는 기능처럼 느껴지거든요. 그런데 실제로 써보니까 스냅샷은 어디까지나 파일시스템(File System, 데이터를 저장하고 관리하는 구조)이나 볼륨(Volume, 논리적으로 묶인 저장 공간)의 시점을 기록하는 기술이지, 모든 장애를 자동으로 해결해주는 마법은 아니더라고요.

    특히 아래 같은 상황에서 문제가 많이 납니다.

    • 스냅샷은 남아 있는데 원본 볼륨 상태가 이미 불안정한 경우
    • 복구 대상 경로에 이미 새 데이터가 섞여 있는 경우
    • 권한(Permission, 접근 권한)과 소유권(Ownership)이 예상과 다르게 적용된 경우
    • 애플리케이션 데이터베이스(DB, Database)처럼 정합성(Consistency, 데이터가 논리적으로 맞는 상태)이 중요한 데이터를 파일 단위로만 복구한 경우
    • 스냅샷과 백업을 같은 저장소에만 두고 운영하다가 물리 장애가 난 경우

    그러니까 스냅샷 예방의 핵심은 “스냅샷을 많이 찍는 것”보다 “복구 단위를 정확히 이해하는 것”입니다. 이 차이를 모르면 복구 버튼을 눌러도 기대한 결과가 안 나와요.

    2. 스냅샷, 백업, 복제는 뭐가 다를까요?

    여기서 많이 헷갈리더라고요. 저도 처음엔 비슷하게 봤었는데, 운영해보니 역할이 완전히 다르더라고요.

    구분 의미 강점 한계
    스냅샷 같은 스토리지 내부의 특정 시점 보존 빠른 롤백, 짧은 복구 시간 원본 저장소 장애에 함께 영향받을 수 있음
    백업 별도 위치에 데이터 복사본 보관 삭제, 랜섬웨어, 장비 장애 대응력 높음 복구 시간과 관리 비용이 더 듦
    복제 다른 시스템으로 데이터 동기화 서비스 연속성 확보에 유리 잘못된 변경도 함께 복제될 수 있음

    쉽게 말해, 스냅샷은 “되돌리기”, 백업은 “살려내기”, 복제는 “이어받기”에 가깝습니다. 이 세 가지를 같은 것으로 보면 사고가 납니다. 데이터 손실 방지를 진짜로 하려면 세 기능을 섞어서 설계해야 합니다.

    스냅샷 복구가 특히 취약한 데이터 유형

    • 가상머신 이미지처럼 파일은 하나여도 내부 변경이 큰 데이터
    • 데이터베이스 파일처럼 쓰기 타이밍이 중요한 데이터
    • 권한과 ACL(Access Control List, 세부 접근 제어 목록)이 복잡한 팀 공유 폴더
    • 동기화 클라이언트가 동시에 접근하는 작업 폴더

    제가 직접 해보니 문서나 이미지 아카이브는 스냅샷 복구가 꽤 직관적인데, 서비스 데이터는 생각보다 복구 후 검증이 더 중요했습니다.

    3. 복구 전 반드시 확인할 체크리스트

    NAS 스냅샷 복구 실패를 막으려면 기술보다 절차가 중요합니다. 저는 이제 복구 전에 아래 순서대로 확인합니다.

    1. 복구 범위 확인: 파일 단위인지, 공유 폴더 단위인지, 볼륨 단위인지 확인합니다.
    2. 현재 데이터 격리: 지금 살아 있는 데이터를 다른 경로로 임시 보관합니다.
    3. 활성 서비스 중지: SMB, NFS, 컨테이너(Container, 격리된 실행 환경), VM 등 쓰기 작업을 멈춥니다.
    4. 스냅샷 시점 검증: 원하는 파일이 실제로 그 시점에 존재했는지 먼저 확인합니다.
    5. 권한 구조 기록: UID/GID, ACL, 공유 권한을 미리 기록합니다.
    6. 복구 후 검증 항목 정의: 파일 존재 여부만 보지 말고 애플리케이션 동작까지 확인합니다.

    이 절차를 귀찮다고 건너뛰면, 복구 자체는 성공했는데 운영 기준으로는 실패인 상황이 나옵니다. 이거 진짜 자주 봤습니다.

    4. 실전 구현: NAS 데이터 복구 성공률을 높이는 운영 절차

    아래 예시는 리눅스 기반 NAS나 유닉스 계열 스토리지 환경에서 공통적으로 응용할 수 있는 점검 흐름입니다. 특정 벤더 기능명이 아니라, 원리 중심으로 보시면 됩니다.

    4-1. 현재 상태 보존

    복구 전에 현재 데이터를 별도 경로로 보존합니다. 잘못 덮어써도 다시 비교할 수 있어야 하거든요.

    mkdir -p /recovery-staging/current-data
    rsync -aH --numeric-ids /srv/share/ /recovery-staging/current-data/
    

    여기서 <code>rsync는 파일 속성과 권한을 최대한 유지하면서 복사할 때 많이 써요. --numeric-ids를 넣는 이유는 사용자 이름 매핑이 달라져도 숫자 ID 기준으로 보존하려는 목적입니다.

    4-2. 활성 서비스 중지

    파일을 잡고 있는 프로세스가 있으면 복구 중 충돌이 생길 수 있습니다.

    systemctl stop smb
    systemctl stop nfs-server
    systemctl stop docker
    

    환경에 따라 서비스 이름은 다를 수 있어요. 핵심은 쓰기 중인 서비스부터 끊는 것입니다. 처음엔 이게 과한가 싶었는데, 실제로 써보니까 이 단계에서 사고를 많이 줄였습니다.

    4-3. 스냅샷 대상 확인

    mount | grep srv
    ls -al /srv/share/
    getfacl /srv/share | head -n 20
    

    복구하려는 경로가 맞는지, 권한 구조는 어떤지 간단히 확인합니다. ACL을 쓰는 환경에서는 이 단계가 특히 중요해요.

    NAS 스냅샷 복구 실패 점검을 위한 복구 대상 경로 확인 이미지

    복구 전에 스냅샷 시점과 대상 경로를 교차 확인하는 과정을 보여주는 이미지입니다.

    4-4. 복구 후 비교 검증

    복구를 한 뒤에는 단순히 파일 개수만 보면 안 됩니다. 저는 최소한 해시(Hash, 파일 내용 기반 식별값)나 디렉터리 구조를 비교해봅니다.

    find /srv/share -type f | sort > /tmp/restored-files.txt
    find /recovery-staging/current-data -type f | sort > /tmp/current-files.txt
    diff -u /tmp/current-files.txt /tmp/restored-files.txt
    

    중요 데이터라면 샘플 파일 몇 개를 직접 열어보는 것도 필요해요. 특히 문서 관리 폴더나 애플리케이션 설정 폴더는 눈으로 확인해야 안심되더라고요.

    4-5. 점검 결과 기록

    복구 후 체크리스트를 남겨두면 다음 장애 때 훨씬 빨라집니다.

    recovery_checklist:
      snapshot_time: "2026-07-31T02:00:00"
      target_path: "/srv/share"
      services_stopped:
        - smb
        - nfs-server
        - docker
      permission_checked: true
      application_validation: pending
      notes: "restored files verified, ACL review required"
    

    이런 식으로 남기면 팀 단위 운영에서도 전달이 깔끔해요.

    5. NAS 스냅샷 복구 실패의 대표 사례와 해결 방법

    이 섹션이 핵심입니다. 저도 삽질 좀 했습니다 ㅎㅎ 복구가 안 된다고 느끼는 대표 패턴은 대부분 아래로 모입니다.

    사례 1. 스냅샷은 복원됐는데 파일이 안 보이는 경우

    원인은 대개 경로 착오, 숨김 파일 처리, 권한 문제예요. 복구는 되었는데 공유 프로토콜에서 안 보이는 거죠. 특히 SMB 환경에서는 실제 파일은 있어도 권한이 맞지 않으면 사용자는 “사라졌다”고 느낍니다.

    해결 포인트는 이렇습니다.

    • 복구 경로와 실제 공유 경로가 같은지 확인
    • 소유권과 ACL 재검토
    • 클라이언트 캐시를 비우고 재접속

    사례 2. 애플리케이션은 살아났는데 데이터가 깨진 경우

    이건 데이터베이스나 인덱스 파일에서 자주 봅니다. 파일 단위 스냅샷은 살아 있어도, 애플리케이션 입장에서는 트랜잭션(Transaction, 작업 단위) 정합성이 안 맞는 상황이 생길 수 있거든요.

    해결 포인트는 애플리케이션 정지 후 스냅샷, 혹은 애플리케이션이 제공하는 백업 절차와 함께 운영하는 것입니다. 파일시스템 스냅샷만 믿고 가면 위험해요.

    사례 3. 랜섬웨어 대응용 스냅샷이 같이 손상된 경우

    스냅샷이 같은 관리자 권한 범위 안에 있고, 삭제 보호가 약하면 공격자나 오작동 스크립트가 같이 건드릴 수 있습니다. 그래서 스냅샷만으로는 데이터 손실 방지 전략이 완성되지 않습니다.

    사례 4. 복구 후 새로 생성한 데이터가 덮여서 사라진 경우

    복구 전에 현재 데이터를 격리하지 않아서 생기는 사고거든요. 저도 예전에 테스트하다가 최근 파일 몇 개를 다시 손으로 맞춘 적이 있는데, 그 뒤로는 무조건 스테이징(Staging, 임시 보관 구역) 복사를 먼저 합니다.

    6. 예방 전략: 스냅샷 예방은 설정이 아니라 운영 습관

    여기서 중요한 포인트! NAS 스냅샷 복구 실패를 줄이려면 복구 기능보다 운영 원칙을 먼저 세워야 합니다.

    1. 스냅샷과 백업을 분리해요. 같은 NAS 안에만 두지 않습니다.
    2. 복구 테스트를 정기적으로 해야 해요. 최소한 분기별로 샘플 복구를 해보세요.
    3. 권한 구조를 문서화합니다. 복구 실패의 절반은 권한 꼬임이더라고요.
    4. 중요 서비스는 정합성 중심으로 봐야 합니다. DB, VM, 컨테이너 볼륨은 별도 절차가 필요해요.
    5. 보존 정책(Retention Policy, 몇 개를 얼마나 오래 남길지 정한 규칙)을 짧고 촘촘하게 구성합니다.

    예를 들면 저는 홈랩에서 다음처럼 운영하는 편입니다.

    대상 스냅샷 주기 백업 주기 비고
    문서 공유 폴더 짧은 간격 하루 1회 이상 삭제 복구 우선
    미디어 아카이브 긴 간격 주기적 변경 적음
    서비스 데이터 정지 후 또는 앱 연동 별도 백업 필수 정합성 우선

    정답은 환경마다 다르지만, 공통 원칙은 같습니다. 스냅샷은 빠른 복구용, 백업은 최종 생존용입니다.

    NAS 스냅샷 복구 실패 원인을 정리한 트러블슈팅 인포그래픽

    복구 실패의 대표 원인을 빠르게 점검할 수 있도록 정리한 트러블슈팅 이미지입니다.

    7. 복구가 끝난 뒤 반드시 확인할 검증 항목

    복구는 버튼을 누르는 순간 끝나는 게 아니라, 검증이 끝나야 완료된 거거든요. 제가 실제로 체크하는 항목은 아래와 같습니다.

    1. 파일 개수와 디렉터리 구조가 예상과 맞는지
    2. 대표 파일을 직접 열었을 때 손상 없이 읽히는지
    3. 권한과 ACL이 기존 정책과 맞는지
    4. 서비스가 정상 기동되는지
    5. 클라이언트에서 접근 시 오류가 없는지
    test -f /srv/share/important.db && echo "file exists"
    ls -l /srv/share
    getfacl /srv/share
    systemctl start smb
    systemctl status smb --no-pager
    

    가능하면 검증 결과를 간단히 로그로 남겨두세요. 다음 장애 때 “예전에 어떻게 했더라?”가 없어져요. 이런 운영 로그가 결국 팀의 자산이 되더라고요.

    NAS 스냅샷 복구 실패 예방을 위한 복구 후 검증 결과 이미지

    복구 이후 검증 항목이 모두 통과된 상태를 보여주는 결과 확인 이미지입니다.

    8. NAS 데이터 복구와 스냅샷 예방: 자주 묻는 질문

    Q1. 스냅샷만 있으면 백업은 없어도 되나요?

    아니에요. 스냅샷은 같은 스토리지 계층에 의존하는 경우가 많아서 물리 장애나 광범위한 손상에는 약할 수 있습니다.

    Q2. 스냅샷 개수를 많이 늘리면 더 안전한가요?

    무조건 그렇진 않아요. 보존 정책이 너무 길면 공간 압박이 생기고, 운영자가 어떤 시점이 맞는지 헷갈리기 쉬워집니다. 촘촘한 단기 보존과 별도 백업을 조합하는 게 현실적입니다.

    Q3. NAS 데이터 복구 시 가장 많이 놓치는 건 뭔가요?

    권한과 서비스 상태예요. 파일은 돌아왔는데 접근이 안 되거나, 앱이 데이터를 읽지 못하는 경우가 정말 많습니다.

    Q4. 복구 테스트는 얼마나 자주 해야 하나요?

    운영 중요도에 따라 다르지만, 최소 분기 1회 정도의 샘플 복구 테스트는 추천드려요. 저도 처음엔 귀찮았는데, 해보면 왜 필요한지 바로 체감됩니다.

    9. 마무리: 복구 성공률은 미리 만든 절차에서 갈린다

    NAS 스냅샷 복구 실패는 대개 기능 부족보다 운영 착각에서 시작되거든요. 스냅샷이 있으니 안전하다고 생각했는데, 막상 복구 경로, 권한, 서비스 정지, 정합성 검증 중 하나라도 빠지면 결과가 엇나가더라고요. 저도 처음엔 이게 뭔가 싶었는데, 결국 답은 화려한 기능보다 기본 절차였습니다.

    정리하면 이렇습니다. 스냅샷은 빠르게 되돌리는 도구이고, 백업은 최악의 상황에서 살려내는 장치예요. 둘을 분리해서 설계하고, 실제로 복구 연습까지 해봐야 진짜 데이터 손실 방지가 됩니다. 다음 글에서는 스냅샷 정책과 오프사이트(Off-site, 외부 위치) 백업을 함께 설계하는 방법도 다뤄볼 예정입니다. 이전 글에서 백업 보존 주기 설계 이야기를 보셨다면, 이번 내용이 더 잘 연결되실 거예요.

    운영자가 실제로 기억해야 할 예방 전략을 한 장으로 요약한 마무리 이미지입니다.

  • [Synology NAS] 데이터 복구 및 백업 전략: Hyper Backup과 Snapshot Replication 완벽 가이드

    [Synology NAS] 데이터 복구 및 백업 전략: Hyper Backup과 Snapshot Replication 완벽 가이드

    데이터 날린 그날, 저는 진짜 멘붕이었습니다

    몇 년 전 일인데요, 홈랩에서 운영하던 Synology NAS의 볼륨 하나가 갑자기 마운트가 안 되는 상황이 생겼습니다. 당시 저는 DSM(DiskStation Manager) 업데이트를 막 마친 참이었는데, 재부팅 후 볼륨 상태가 Degraded(저하됨)로 뜨더라고요. 식은땀이 났죠. 그 볼륨에는 수년 치 사진 원본 파일이랑 업무용 스크립트들이 잔뜩 들어있었거든요.

    다행히 그때는 Hyper Backup으로 주기적으로 백업을 해두고 있었고, 결국 데이터는 복구했습니다. 근데 그 경험이 저한테는 엄청난 교훈이 됐어요. “백업은 있는데 복구 테스트를 한 번도 안 해봤다”는 게 얼마나 위험한 건지 그날 뼈저리게 깨달았습니다.

    오늘은 Synology NAS 데이터 복구를 실제로 어떻게 준비하고 실행하는지, 제가 직접 써보고 정착시킨 백업 전략을 공유해 드리려고 합니다. Hyper Backup과 Snapshot Replication(스냅샷 복제), 이 두 도구를 어떻게 조합해서 쓰는지가 핵심입니다.

    Synology NAS 백업 전략 아키텍처 — Hyper Backup과 Snapshot Replication 이중 구성 다이어그램

    ▲ Synology NAS의 이중 백업 전략 — Hyper Backup과 Snapshot Replication을 레이어로 구성한 전체 아키텍처 개요


    먼저 개념부터: 왜 두 가지 도구가 필요한가요?

    처음에 저도 “백업 하나면 되는 거 아냐?” 싶었는데, 실제로 써보니까 두 도구가 커버하는 영역이 완전히 달라요. 쉽게 설명해 드릴게요.

    Hyper Backup — 장거리 안전망

    Hyper Backup은 NAS의 데이터를 외부 대상(다른 NAS, 외장 드라이브, 클라우드 등)으로 증분 백업(Incremental Backup)하는 도구입니다. 변경된 파일만 백업해서 저장 공간을 효율적으로 씁니다.

    • 백업 대상: 폴더, 패키지, 시스템 설정까지 포함 가능
    • 보관 기간: 버전 관리로 특정 시점으로 되돌리기 가능
    • 대상 저장소: 로컬 드라이브, 원격 NAS, Amazon S3, Backblaze B2, Google Drive 등
    • 복구 단위: 파일 단위 또는 전체 백업 세트 복구

    쉽게 말해, 몇 주 전 상태로 돌아가야 할 때 쓰는 도구예요. 랜섬웨어에 감염됐는데 3주 전 파일이 필요할 때 같은 상황이죠.

    Snapshot Replication — 단거리 빠른 복원

    Snapshot Replication(스냅샷 복제)은 Btrfs 파일 시스템 기반의 볼륨/공유 폴더 스냅샷을 찍어두는 기능입니다. 운영 중인 상태를 그대로 순간 포착해두는 거죠.

    • 스냅샷 간격: 최소 5분 단위까지 설정 가능
    • 복구 속도: 거의 즉각적 (파일 시스템 레벨 작업)
    • 복구 단위: 공유 폴더 전체 또는 개별 파일
    • 전제 조건: Btrfs 파일 시스템으로 포맷된 볼륨 필요

    오늘 오전에 실수로 파일을 지웠는데 바로 되돌려야 할 때, 이게 훨씬 빠르고 편합니다. “어? 방금 지웠는데?” 싶을 때 쓰는 거죠.

    구분 Hyper Backup Snapshot Replication
    주요 용도 장기 보존, 외부 백업 빠른 단기 복원
    복구 속도 상대적으로 느림 (파일 복사) 매우 빠름 (메타데이터 조작)
    저장 위치 외부 대상 필수 동일 볼륨 내 가능
    파일 시스템 ext4, Btrfs 모두 지원 Btrfs 전용
    버전 관리 최대 수십~수백 버전 설정에 따라 수십 개
    재해 복구 강함 (오프사이트 가능) 약함 (NAS 자체 장애시 무력)

    이 둘을 조합하는 게 핵심입니다. 스냅샷은 빠른 일상 복원용, Hyper Backup은 재해(Disaster) 상황 대비용이에요.


    Snapshot Replication 설정하기 — 먼저 이걸 켜두세요

    스냅샷은 설정이 간단하고 효과가 즉각적이라서 먼저 세팅해 두는 걸 추천드려요. 단, 앞서 말씀드린 것처럼 Btrfs 파일 시스템이 전제입니다. DSM에서 볼륨 생성할 때 Btrfs를 선택했어야 해요. ext4로 만들어뒀다면 Snapshot Replication은 쓸 수 없어요 — 이거 처음에 모르고 삽질했었습니다 ㅎㅎ.

    1단계: Snapshot Replication 패키지 설치

    1. DSM 패키지 센터(Package Center)에서 “Snapshot Replication” 검색 후 설치
    2. 설치 완료 후 패키지를 실행

    2단계: 공유 폴더(Shared Folder) 스냅샷 활성화

    1. Snapshot Replication 앱 실행
    2. 좌측 메뉴에서 스냅샷(Snapshots) 선택
    3. 스냅샷을 활성화할 공유 폴더 선택
    4. 설정(Settings) 클릭 → 스케줄 탭으로 이동

    저는 아래처럼 스케줄을 구성해서 쓰고 있어요:

    # Snapshot Replication 권장 스케줄 예시
    # (DSM UI에서 설정하는 값 기준)
    
    스냅샷 간격: 매시간 (1시간마다)
    보관 정책 (Retention Policy):
      - 최근 24시간: 시간별 스냅샷 유지
      - 최근 30일: 일별 스냅샷 유지
      - 최근 12개월: 주별 스냅샷 유지
    
    앱 일관성(Application Consistency): 활성화 권장
    # → 데이터베이스 등 앱 실행 중에도 일관된 스냅샷 보장

    3단계: 사용자 셀프 서비스 복원 활성화

    이게 진짜 꿀기능인데요. 활성화해두면 일반 사용자도 Windows의 “이전 버전” 기능처럼 파일을 직접 복원할 수 있어요. 관리자한테 매번 요청 안 해도 되니까 가족이나 팀 구성원이 있는 환경에서 특히 편합니다.

    1. 공유 폴더 선택 → 설정 → 고급(Advanced) 탭
    2. “사용자가 이전 버전에 액세스할 수 있도록 허용” 체크
    3. SMB(Windows 파일 공유)로 접근 시 파일 우클릭 → “이전 버전” 탭에서 복원 가능
    Synology DSM Snapshot Replication 스케줄 및 보관 정책 설정 화면

    ▲ DSM의 Snapshot Replication 설정 화면 — 스케줄 간격과 보관 정책을 이렇게 구성하면 실수로 지운 파일도 빠르게 복원할 수 있습니다


    Hyper Backup 설정하기 — 진짜 백업은 이거예요

    Snapshot Replication은 NAS 자체가 고장나면 의미가 없어요. 진짜 재해 복구(Disaster Recovery)를 위해서는 반드시 오프사이트 백업(Off-site Backup)이 필요합니다. 저는 Hyper Backup으로 외부 NAS와 클라우드 두 곳에 백업을 보내고 있어요.

    1단계: 백업 대상 선택

    Hyper Backup이 지원하는 백업 대상은 다양합니다:

    • 로컬 폴더 및 USB 드라이브
    • 원격 NAS (rsync 또는 Synology 전용 프로토콜)
    • Amazon S3 및 S3 호환 스토리지 (Wasabi, MinIO 등)
    • Backblaze B2
    • Google Drive, Microsoft OneDrive, Dropbox
    • Azure Blob Storage

    저는 로컬 NAS → 외부 NAS(원격) + Backblaze B2(클라우드) 구조로 3-2-1 백업 전략을 구현하고 있어요.

    💡 3-2-1 백업 규칙: 데이터 3개 복사본, 2가지 다른 미디어, 1개는 오프사이트 보관. 백업의 황금 법칙입니다.

    2단계: Hyper Backup 작업 생성

    1. DSM 메인 메뉴 → Hyper Backup 실행
    2. 좌하단 + 버튼 → 데이터 백업 작업(Data Backup Task) 선택
    3. 백업 대상 유형 선택 (예: Synology C2, Amazon S3, 원격 NAS 등)
    4. 연결 정보 입력 후 다음

    3단계: 백업 폴더 및 애플리케이션 선택

    # Hyper Backup 백업 대상 선택 권장 항목
    
    [공유 폴더]
    ✅ photo          # 사진 폴더
    ✅ documents      # 문서 폴더  
    ✅ homes          # 사용자 홈 폴더
    ✅ docker         # Docker 볼륨 (있는 경우)
    
    [애플리케이션 (Application)]
    ✅ DSM 구성 (시스템 설정 백업)
    ✅ 사용 중인 패키지 설정들
    # 예: Surveillance Station, Note Station 등
    
    # 주의: Docker 컨테이너 데이터는
    # 볼륨 폴더 백업과 병행해야 합니다

    4단계: 스케줄 및 버전 보관 정책 설정

    # Hyper Backup 권장 설정 값
    
    백업 스케줄: 매일 새벽 3:00 AM
    # 시스템 부하가 적은 시간대 권장
    
    버전 보관 정책 (Smart Recycle):
      - 최근 1~7일: 매일 1개 버전 보관
      - 최근 1~4주: 매주 1개 버전 보관  
      - 최근 1~12개월: 매월 1개 버전 보관
    
    암호화(Encryption): 활성화 강력 권장
    # 클라우드 백업 시 특히 중요
    # ⚠️ 암호화 키 분실 시 복구 불가 — 반드시 키 별도 보관!
    
    알림(Notification): 이메일 또는 푸시 알림 설정
    # 백업 실패 즉시 인지하기 위해 필수

    ⚠️ 중요 경고: 암호화를 활성화했다면 암호화 키를 반드시 NAS 외부에 별도로 저장해두세요. 저도 이걸 USB에 인쇄해서 물리적으로 보관하고 있어요. NAS가 날아가면 키도 같이 날아가니까요.


    ⚠️ 실제로 겪은 문제들과 해결법

    이론은 이론이고, 실제로 써보면 별별 문제가 다 생기더라고요. 제가 삽질했던 것들 몇 가지 공유해 드릴게요.

    문제 1: Snapshot이 안 찍힌다 — ext4 볼륨이었던 것

    Snapshot Replication 설정해놨는데 스냅샷이 하나도 안 생기는 거예요. 알고 보니 해당 볼륨이 ext4로 포맷되어 있었던 거였습니다. Btrfs가 아니면 스냅샷 자체가 불가능해요. 이 경우엔 볼륨을 다시 만들어야 하는데, 그럼 데이터 마이그레이션이 필요합니다.

    💡 확인 방법: DSM → 저장소 관리자(Storage Manager) → 볼륨 선택 → 파일 시스템 항목 확인

    문제 2: Hyper Backup 작업이 자꾸 실패

    클라우드 백업이 며칠째 실패 알림이 오는 거예요. 로그를 보니 연결 타임아웃이었는데, 원인은 백업 데이터가 너무 커서 업로드 중간에 끊기는 거였습니다. 해결책은 두 가지였어요:

    1. 첫 백업은 최대한 대상 데이터를 줄인 상태에서 실행 (초기 풀 백업 완료 후 증분만 돌리기)
    2. 백업 시간대를 네트워크 사용량이 적은 새벽으로 변경

    문제 3: 복구 테스트 안 했다가 낭패

    이게 제일 중요한 교훈인데요. 백업은 있는데 복구가 안 되면 의미가 없잖아요. 저는 6개월 동안 Hyper Backup을 돌리면서 한 번도 복구 테스트를 안 했었어요. 그러다 실제 복구가 필요한 상황이 왔을 때 백업 파일이 손상되어 있는 걸 발견했습니다. 진짜 식은땀 났죠.

    지금은 분기에 한 번 복구 테스트를 캘린더에 넣어두고 반드시 실행합니다. 방법은 아래와 같아요:

    # Hyper Backup 복구 테스트 절차
    
    1. Hyper Backup Vault 또는 Hyper Backup Explorer 실행
       (백업 대상 NAS에 설치된 Vault, 또는 PC용 Explorer 사용)
    
    2. 백업 저장소 연결 → 특정 날짜 버전 선택
    
    3. 테스트 폴더로 일부 파일 복원 시도
       예: /photo/2023 폴더 중 샘플 10개 파일
    
    4. 복원된 파일 무결성 확인
       - 파일이 정상적으로 열리는지
       - 파일 크기가 원본과 일치하는지
    
    5. DSM → Hyper Backup → 통계(Statistics)에서
       백업 무결성 검사(Backup Integrity Check) 실행
    Synology NAS 데이터 복구 화면 — Hyper Backup 날짜별 버전 선택 및 파일 복원 인터페이스

    ▲ Hyper Backup 복구 화면 — 날짜별 버전을 선택해 특정 시점의 파일을 복원할 수 있습니다. 분기 1회 복구 테스트를 꼭 해보세요


    실제 데이터 복구 시나리오별 대응법

    “어떤 상황에 뭘 써야 하나” 헷갈리실 것 같아서 시나리오별로 정리해 드릴게요.

    시나리오 A: 파일 실수로 삭제 (오늘 발생)

    1. Snapshot Replication 앱 실행
    2. 해당 공유 폴더 선택 → 찾아보기(Browse)
    3. 삭제 직전 시점의 스냅샷 선택
    4. 파일 선택 → 복원(Restore) 또는 다운로드

    ✅ 보통 1~2분 내로 해결됩니다.

    시나리오 B: 랜섬웨어 감염 (수일 전 파일 필요)

    1. 즉시 NAS 네트워크 연결 차단 (추가 감염 방지)
    2. Hyper Backup 실행 → 감염 이전 날짜 버전 선택
    3. 격리된 환경에 복원 후 파일 검증
    4. 볼륨 초기화 후 클린 복원

    ⚠️ 이때 스냅샷은 이미 랜섬웨어에 의해 오염됐을 가능성이 있어요. 반드시 외부 백업(Hyper Backup)에서 복원하세요.

    시나리오 C: NAS 하드웨어 완전 고장

    1. 새 NAS 또는 교체 NAS에 DSM 설치
    2. Hyper Backup 설치 후 백업 저장소 연결
    3. 전체 복원(Full Restore) 실행 — 시스템 설정 포함 복원 가능
    4. 패키지 설정까지 백업해뒀다면 거의 원상 복구 가능

    저는 이 시나리오를 실제로 겪었는데, DSM 설정까지 백업해둔 덕분에 새 NAS 세팅 시간이 정말 많이 줄었습니다. 처음엔 이게 되나 싶었는데 진짜 되더라고요 ㅎㅎ.


    제가 최종 정착한 백업 구성 — 참고하세요

    여러 번 바꾸고 다듬어서 지금은 이 구성으로 안정적으로 운영 중입니다:

    # 홈랩 NAS 백업 구성 (최종)
    
    [1레이어] Snapshot Replication
      - 대상: 모든 Btrfs 공유 폴더
      - 주기: 매시간
      - 보관: 24시간(시간별) + 30일(일별)
      - 목적: 빠른 파일 복원
    
    [2레이어] Hyper Backup → 외장 USB HDD
      - 주기: 매일 새벽 2:00 AM
      - 보관: Smart Recycle (월별 최대 12개월)
      - 암호화: 활성화
      - 목적: 로컬 오프사이트 복사본
    
    [3레이어] Hyper Backup → Backblaze B2
      - 주기: 매일 새벽 3:30 AM
      - 보관: Smart Recycle (월별 최대 12개월)
      - 암호화: 활성화
      - 목적: 클라우드 오프사이트 (화재/도난 대비)
    
    [검증]
      - 매주: 백업 완료 알림 이메일 확인
      - 분기: 실제 파일 복원 테스트
      - 연간: 전체 복구 시뮬레이션

    이 구성이면 3-2-1 백업 전략을 완전히 충족하고, 일상적인 실수부터 하드웨어 전체 고장까지 대부분의 시나리오에 대응할 수 있어요.

    3-2-1 백업 전략 인포그래픽 — Synology NAS 3단계 데이터 보호 구조 요약

    ▲ 3-2-1 백업 전략 요약 인포그래픽 — Snapshot, 로컬 외장드라이브, 클라우드를 조합한 3단계 보호 구조


    자주 묻는 질문 (FAQ)

    Q. Snapshot Replication은 용량을 많이 차지하나요?

    Btrfs의 Copy-on-Write(CoW) 특성 덕분에 변경된 블록만 추가 저장해요. 파일 변경이 적은 환경에서는 스냅샷 용량 증가가 미미합니다. 다만 파일 변경이 잦은 폴더(예: 다운로드 폴더)는 스냅샷 보관 수를 줄이는 게 좋아요.

    Q. Hyper Backup 초기 백업이 너무 오래 걸려요

    첫 풀 백업은 데이터 크기에 따라 며칠이 걸릴 수 있습니다. 처음엔 백업 대상 폴더를 최소화해서 시작하고, 이후 점진적으로 추가하는 방식을 추천드려요. 또는 USB HDD에 먼저 풀 백업 후 클라우드로 이관하는 방법도 있어요.

    Q. ext4 볼륨인데 스냅샷을 쓸 수 없나요?

    네, Snapshot Replication은 Btrfs 전용입니다. ext4 환경이라면 Hyper Backup만으로 백업 전략을 구성하시거나, 새 볼륨 생성 시 Btrfs를 선택하는 걸 권장드려요.

    Q. DSM 버전에 따라 기능 차이가 있나요?

    Hyper Backup과 Snapshot Replication은 DSM 6.x 이후 버전에서 안정적으로 지원됩니다. DSM 7.x에서 UI가 개선되고 일부 기능이 추가됐으니, 최신 DSM 유지를 권장합니다.


    마무리 — 백업은 있는 게 아니라 복구되는 게 중요합니다

    결국 제가 이 글에서 가장 강조하고 싶은 건 하나예요. “백업을 설정했다”는 것과 “복구할 수 있다”는 건 완전히 다른 얘기입니다. 저도 그 차이를 몸으로 배웠거든요.

    Synology NAS 데이터 복구를 위한 전략을 정리하면:

    • ✅ Snapshot Replication으로 빠른 일상 복원 레이어 구성
    • ✅ Hyper Backup으로 외부 오프사이트 백업 구성
    • ✅ 3-2-1 원칙 준수
    • ✅ 분기 1회 이상 실제 복구 테스트 반드시 실행
    • ✅ 백업 실패 알림 설정으로 문제 즉시 인지

    데이터가 날아가고 나서 후회하는 것만큼 억울한 게 없어요. 오늘 당장 복구 테스트 한 번 해보시는 걸 강력 추천드립니다. 생각보다 간단하고, 그 안도감은 진짜거든요. 🎉

    다음 글에서는 Synology NAS의 능동적 보안 설정 — 방화벽 규칙 구성과 2FA(이중 인증) 강화 방법을 다뤄볼 예정입니다. 백업 전략을 완성했다면 보안도 같이 챙겨야 하니까요. 이전 글에서는 Synology NAS 초기 세팅 가이드를 다뤘으니 참고해 보세요.