13년차의 서버실

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

[카테고리:] NAS

  • [NAS] TrueNAS ZFS 스냅샷과 복제: 데이터 보호 전략

    [NAS] TrueNAS ZFS 스냅샷과 복제: 데이터 보호 전략

    목차

    데이터 유실의 악몽, 여러분은 준비되셨나요?

    안녕하세요, 13년차 인프라 엔지니어입니다. 서버실 관리하며 수많은 데이터 유실 사고를 직간접적으로 경험했어요. 실수로 파일을 지우거나, 하드디스크가 갑자기 고장 나거나, 심지어 랜섬웨어 공격까지… 상상만 해도 끔찍하죠?

    그래서 홈랩에서 TrueNAS를 운영하면서 데이터 보호에 정말 신경을 많이 씁니다. RAID만 믿고 있으면 안 된다는 걸 너무 잘 알거든요. RAID는 디스크 고장으로부터는 지켜주지만, 실수나 논리적 오류(Logical Error), 랜섬웨어 같은 위협에는 무력합니다. 이럴 때 필요한 게 바로 ZFS의 스냅샷(Snapshot)과 복제(Replication) 기능입니다. 제가 직접 써보니 이거 진짜 물건이더라고요!

    오늘은 여러분의 소중한 데이터를 지켜줄 TrueNAS ZFS 스냅샷과 복제 전략을 제 경험을 바탕으로 자세히 이야기해보겠습니다. 삽질하며 배운 노하우도 아낌없이 공유해 드릴게요!

    이 다이어그램은 TrueNAS ZFS 스냅샷과 복제 아키텍처의 개요를 보여줍니다. 로컬 TrueNAS에서 생성된 ZFS 스냅샷이 원격 TrueNAS로 복제되는 과정을 시각화했습니다.

    ZFS 스냅샷과 복제, 이게 뭔가요?

    처음엔 ZFS라는 이름도 생소하고, 스냅샷이니 복제니 하는 용어들이 헷갈리더라고요. 제가 직접 경험한 것을 바탕으로 쉽게 설명해 드릴게요.

    1. ZFS 스냅샷(Snapshot): 시간 여행 기능

    ZFS 스냅샷은 특정 시점의 파일 시스템 상태를 읽기 전용(Read-only)으로 저장하는 기능입니다. 비유하자면, 게임을 하다가 중요한 순간에 ‘저장’ 버튼을 누르는 것과 같아요. 언제든지 그 저장 지점으로 돌아갈 수 있거든요. 근데 일반적인 백업과는 좀 다릅니다. 변경된 데이터만 저장하는 CoW(Copy-on-Write) 방식을 사용해서 용량 효율이 정말 좋고, 생성도 눈 깜짝할 사이에 이루어져요. 제가 써보니 수백 GB짜리 데이터셋도 TrueNAS ZFS 스냅샷 뜨는데 1초도 안 걸리더라고요. 신기했습니다!

    • 즉시 생성 & 낮은 오버헤드: 순식간에 만들어지고 시스템 성능에 거의 영향을 주지 않습니다.
    • 공간 효율성: 변경된 블록만 저장하므로 추가 용량이 최소화됩니다.
    • 데이터 복구 용이성: 특정 시점으로 쉽게 롤백(Rollback)하거나, 스냅샷에서 파일을 직접 복사할 수 있습니다.
    • 불변성(Immutability): 생성된 스냅샷은 변경할 수 없어서 랜섬웨어 공격으로부터 안전합니다.

    2. ZFS 복제(Replication): 원격지 백업의 완성

    ZFS 복제는 이렇게 만들어진 스냅샷을 다른 ZFS 시스템(다른 TrueNAS 서버나 원격 서버)으로 전송(Transfer)하는 기능입니다. 게임 저장 파일을 친구 집 컴퓨터에 똑같이 복사해두는 것과 비슷해요. 내 컴퓨터가 고장 나도 친구 컴퓨터의 저장 파일로 다시 시작할 수 있는 거죠.

    TrueNAS 복제 기능은 ZFS의 델타(Delta) 전송을 활용합니다. 첫 번째 복제 때는 전체 스냅샷을 보내지만, 그 이후부턴 이전 스냅샷과 현재 스냅샷 간의 변경된 부분(Incremental changes)만 전송합니다. 실제로 홈랩에서 써보니 처음 한 번만 오래 걸리고 그 다음부턴 정말 빠르더라고요. 네트워크 트래픽도 확 줄고요. 이게 바로 재해 복구(Disaster Recovery, DR) 전략의 핵심입니다.

    • 원격지 백업: 로컬 시스템에 문제가 생겨도 원격지에 안전한 사본이 있습니다.
    • 대역폭 효율성: 증분(Incremental) 복제를 통해 네트워크 사용량을 최소화합니다.
    • 자동화 가능: TrueNAS UI에서 스케줄링하여 자동으로 복제를 수행할 수 있습니다.
    • 완전한 복구: 원격지에서 전체 데이터셋을 복구하거나, 특정 스냅샷으로 롤백하여 복구할 수 있습니다.

    TrueNAS ZFS 스냅샷 & 복제, 제가 직접 해보니

    이제 직접 TrueNAS에서 스냅샷과 복제 설정을 해볼 시간입니다. 처음엔 메뉴가 좀 복잡해 보여서 삽질 좀 했지만, 한 번 해보면 어렵지 않아요. 저를 따라오시면 금방 하실 수 있을 겁니다. 제가 쓰는 TrueNAS SCALE 기준으로 설명해 드릴게요.

    1. 자동 스냅샷 태스크 설정하기

    가장 먼저 할 일은 원하는 데이터셋에 주기적으로 ZFS 스냅샷을 찍도록 설정하는 겁니다. 저는 매일 밤 12시에 스냅샷을 찍고, 최근 7일치 스냅샷을 보관하도록 설정했어요.

    1. TrueNAS 웹 UI에 접속합니다.
    2. 왼쪽 메뉴에서 ‘Data Protection’ > ‘Snapshots’로 이동합니다.
    3. 우측 상단의 ‘ADD’ 버튼을 클릭합니다.
    4. 설정 화면에서 다음 항목들을 채워줍니다.
      • Dataset: 스냅샷을 찍을 데이터셋을 선택합니다. (예: Pool명/데이터셋명)
      • Recursive: 하위 데이터셋까지 스냅샷을 찍을지 여부입니다. 저는 보통 체크합니다.
      • Naming Schema: 스냅샷 이름 규칙입니다. 기본값 auto-%Y-%m-%d_%H-%M을 사용해도 충분합니다.
      • Schedule: 스냅샷을 찍을 주기입니다. 저는 ‘Daily’로 설정하고 ‘Time’을 ’00:00’으로 지정했습니다.
      • Keep for: 스냅샷을 얼마나 보관할지 설정합니다. 저는 ‘7 Days’로 설정했습니다.
    5. ‘SAVE’ 버튼을 클릭하여 저장합니다.

    ✅ 이제 지정된 시간에 자동으로 ZFS 스냅샷이 생성되고 오래된 스냅샷은 자동으로 삭제될 겁니다. ‘Snapshots’ 메뉴에서 생성된 스냅샷 목록을 확인할 수 있습니다.

    TrueNAS 웹 UI에서 ZFS 자동 스냅샷 태스크를 설정하는 화면입니다. 데이터셋, 스케줄, 보관 기간 등을 지정하여 원하는 스냅샷 정책을 만들 수 있습니다.

    2. ZFS 복제 태스크 설정하기 (원격 백업)

    스냅샷만으로는 부족합니다. 메인 TrueNAS 서버 자체가 망가지면 스냅샷도 소용없거든요. 그래서 저는 집의 다른 미니 PC에 TrueNAS를 설치해서 원격 복제 타겟으로 사용하고 있습니다. 물론 클라우드 스토리지(S3 등)로 복제하는 방법도 있지만, 저는 로컬 네트워크에서 빠르고 안정적인 TrueNAS 복제를 선호해서 이렇게 구성했어요.

    복제를 위해서는 먼저 원격 TrueNAS 서버에 SSH 접속을 위한 SSH Key를 설정해야 합니다. 보안상 ID/PW 방식보다는 SSH Key 방식을 추천합니다. 이 부분은 한 번 설정해두면 정말 편합니다.

    1. SSH Key 생성:
      • 복제를 시작할 TrueNAS(소스)에서 왼쪽 메뉴 ‘System Settings’ > ‘SSH Keypairs’로 이동합니다.
      • ‘ADD’를 클릭하고 키 이름을 지정한 후 ‘GENERATE KEYPAIR’를 선택하여 새 키를 생성합니다.
      • 생성된 Public Key 내용을 복사해둡니다.
    2. 원격 TrueNAS에 Public Key 등록:
      • 원격 TrueNAS(타겟) 웹 UI에 접속합니다.
      • ‘System Settings’ > ‘Users’로 이동하여 복제에 사용할 유저(예: root)를 선택하고 ‘EDIT’합니다.
      • ‘SSH Public Keys’ 필드에 아까 복사해둔 Public Key 내용을 붙여넣고 저장합니다.
      • 💡 팁: SSH 서비스가 활성화되어 있는지 확인하세요. ‘System Settings’ > ‘Services’에서 SSH 서비스를 ‘Running’ 상태로 변경하고 ‘Start Automatically’를 체크합니다.
    3. 복제 태스크 설정:
      • 다시 소스 TrueNAS로 돌아와서 ‘Data Protection’ > ‘Replication Tasks’로 이동합니다.
      • 우측 상단의 ‘ADD’ 버튼을 클릭합니다.
      • 설정 화면에서 다음 항목들을 채워줍니다.
        • Source: 복제할 데이터셋을 선택합니다. (예: Pool명/데이터셋명)
        • Destination: 원격 TrueNAS의 IP 주소와 SSH 포트(기본값 22)를 입력합니다. (예: ssh://192.168.1.100)
        • SSH Key: 아까 생성한 SSH Keypair를 선택합니다.
        • Remote Hostname: 원격 TrueNAS의 호스트명이나 IP를 다시 확인합니다.
        • Remote ZFS Filesystem: 원격 TrueNAS에서 ZFS 스냅샷이 저장될 데이터셋 경로를 지정합니다. (예: remote_pool/replicated_data)
        • Naming Schema: 원격지에 생성될 스냅샷 이름 규칙입니다. 소스와 동일하게 설정하는 것이 좋습니다.
        • Schedule: 복제 주기를 설정합니다. 저는 스냅샷 주기와 비슷하게 ‘Daily’로 설정했습니다.
        • Liveness Check: 원격지가 살아있는지 확인할 주기입니다.
        • Enable Replication: 체크박스를 활성화합니다.
      • ‘SAVE’ 버튼을 클릭하여 저장합니다.

    🎉 드디어 복제 태스크 설정이 완료되었습니다! 첫 복제는 소스 데이터셋의 크기에 따라 시간이 좀 걸릴 수 있습니다. ‘Replication Tasks’ 목록에서 진행 상황을 확인할 수 있어요. 완료되면 원격 TrueNAS에서도 복제된 스냅샷과 데이터셋을 확인할 수 있을 겁니다.

    ⚠️ 삽질 경험 & 주의사항

    제가 TrueNAS ZFS 복제를 세팅하면서 겪었던 몇 가지 삽질과 주의사항을 공유해 드릴게요. 여러분은 저처럼 고생하지 마시라고요!

    • SSH Key 설정 오류: 가장 많이 겪는 문제입니다. Public Key를 잘못 복사하거나, 원격 TrueNAS의 유저에게 Key가 제대로 등록되지 않았을 때 복제가 실패합니다. ‘System Settings’ > ‘Users’에서 해당 유저의 SSH Public Keys 필드에 제대로 들어갔는지 꼭 확인하세요. 줄 바꿈이나 공백 하나에도 민감하니까요.
    • 네트워크 문제: 소스 TrueNAS와 타겟 TrueNAS 간의 네트워크 연결이 불안정하거나 방화벽(Firewall)이 SSH 포트(기본 22)를 막고 있는 경우가 있습니다. ping 명령어로 연결 확인하고, 방화벽 설정을 꼭 확인해 주세요. 예를 들어, 소스 TrueNAS에서 원격 TrueNAS로 Ping 테스트를 해볼 수 있습니다. 
      
ping 192.168.1.100

      혹은 SSH 서비스가 제대로 실행 중인지 원격 TrueNAS에서 확인하는 것도 중요합니다.

    • 데이터셋 경로 오류: 원격 TrueNAS의 ‘Remote ZFS Filesystem’ 경로를 잘못 지정하면 복제가 실패합니다. 반드시 원격 TrueNAS에 해당 풀(Pool)이 존재해야 하고, 원하는 데이터셋 경로가 유효한지 확인해야 합니다. 저는 실수로 존재하지 않는 데이터셋에 복제하려고 해서 한참 헤맸던 기억이 있거든요.
    • 스냅샷 보존 정책: ZFS 스냅샷과 복제 태스크의 보존 정책(Keep for)을 잘 설정해야 합니다. 너무 짧게 설정하면 중요한 스냅샷이 삭제될 수 있고, 너무 길게 설정하면 스토리지 공간을 너무 많이 차지하게 됩니다. 데이터의 중요도와 스토리지 용량을 고려해서 적절한 기간을 설정하는 것이 중요합니다.
    • 초기 복제 시간: 첫 복제는 전체 데이터를 전송하므로 시간이 오래 걸릴 수 있습니다. 데이터 양이 많다면 네트워크 대역폭과 시간을 충분히 확보하고 시작하는 것이 좋습니다. 저는 1TB 넘는 데이터를 첫 TrueNAS 복제할 때 거의 하루 종일 걸리더라고요.

    이런 문제들 때문에 저도 초기에는 꽤나 애를 먹었습니다. 에러 메시지를 꼼꼼히 읽어보고, TrueNAS 포럼이나 커뮤니티를 검색해보는 것이 큰 도움이 됩니다. 결국 해결하고 나면 그렇게 뿌듯할 수가 없어요! 🎉

    ✅ 복제 결과 확인 및 데이터 복구 테스트

    설정이 끝났다고 마냥 손 놓고 있으면 안 되겠죠? 실제로 잘 작동하는지, 그리고 만약의 사태가 발생했을 때 제대로 복구할 수 있는지 검증(Verification)하는 과정이 정말 중요합니다. 제가 직접 해본 검증 방법들을 알려드릴게요.

    1. 원격 TrueNAS에서 스냅샷 확인

    가장 기본적인 확인 절차입니다. 원격 TrueNAS 웹 UI에 접속해서 ‘Data Protection’ > ‘Snapshots’ 메뉴로 이동해 보세요. 소스 TrueNAS에서 복제된 스냅샷들이 보인다면 일단 복제는 성공적으로 진행되고 있다는 뜻입니다.

    또한, ‘Storage’ > ‘Pools’ 메뉴에서 해당 데이터셋을 클릭하고 ‘Snapshots’ 탭으로 이동하면 해당 데이터셋의 스냅샷 목록을 볼 수 있습니다. 제가 확인해보니 소스에서 찍힌 ZFS 스냅샷 이름과 동일하게 잘 복제되어 있더라고요.

    2. 파일 복구 시뮬레이션

    실제로 데이터를 잃어버렸을 때 어떻게 복구하는지 미리 경험해보는 것이 좋습니다. 저는 테스트용 파일을 만들고 삭제한 다음, 스냅샷으로 복구하는 시뮬레이션을 해봤어요.

    1. 원격 TrueNAS의 복제된 데이터셋에 접속합니다. (SMB/NFS 등으로 마운트)
    2. 테스트용 파일을 몇 개 생성합니다.
    3. 강제로 이 파일들을 삭제하거나 내용을 변경합니다.
    4. ‘Storage’ > ‘Pools’에서 해당 데이터셋을 선택하고 ‘Snapshots’ 탭으로 이동합니다.
    5. 복구하고 싶은 시점의 ZFS 스냅샷을 선택하고 ‘Rollback’ 버튼을 클릭합니다. ⚠️ 롤백은 현재 상태를 스냅샷 시점으로 되돌리는 것이므로, 신중하게 진행해야 합니다. 보통은 스냅샷을 Clone(클론)하여 새로운 데이터셋으로 만든 후, 필요한 파일만 복사하는 방식을 더 많이 사용합니다.
    6. 아니면 스냅샷 내부로 들어가 필요한 파일만 복사해 올 수도 있습니다. 스냅샷은 읽기 전용으로 마운트될 수 있거든요.

    제가 해보니 롤백은 너무 강력한 기능이라 신중해야 하고, 보통은 스냅샷을 마운트해서 특정 파일만 가져오는 게 훨씬 안전하고 편리했습니다. 💡

    TrueNAS 웹 UI에서 복제된 ZFS 데이터셋의 스냅샷 목록을 확인하고, 필요시 롤백 또는 클론 기능을 사용하는 화면입니다.

    마무리하며: 데이터 보호는 선택이 아닌 필수

    TrueNAS의 ZFS 스냅샷과 복제 기능은 정말 강력한 데이터 보호 및 재해 복구 전략을 구축할 수 있게 해줍니다. 저도 처음엔 설정이 좀 복잡하게 느껴졌지만, 한 번 제대로 구축해두니 마음이 정말 편안하더라고요. 홈랩의 소중한 사진, 영상, 문서 파일들이 안전하게 보호되고 있다는 생각에 뿌듯했습니다.

    데이터 유실은 언제든 일어날 수 있는 일입니다. 중요한 건 문제가 생겼을 때 얼마나 빨리, 그리고 얼마나 완벽하게 복구할 수 있느냐입니다. ZFS 스냅샷은 로컬에서의 빠른 복구를, ZFS 복제는 원격지 재해 발생 시의 데이터 복구를 보장해 줍니다.

    여러분도 오늘 제가 공유해드린 내용을 바탕으로 TrueNAS ZFS 스냅샷과 복제 기능을 꼭 활용해 보셨으면 좋겠습니다. 혹시 설정 중에 궁금한 점이나 막히는 부분이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 최대한 도와드리겠습니다!

    다음 글에서는 이렇게 복제된 데이터를 활용하여 다른 용도로 쓰는 방법이나, 클라우드 스토리지로의 복제 등 좀 더 심화된 내용들을 다뤄볼까 합니다. 기대해 주세요!

    TrueNAS ZFS 스냅샷과 복제 기능이 제공하는 핵심 장점들을 요약한 인포그래픽입니다.

  • [Nas] TrueNAS SMB 성능 최적화: 고속 파일 공유를 위한 설정 가이드

    [Nas] TrueNAS SMB 성능 최적화: 고속 파일 공유를 위한 설정 가이드

    목차

    안녕하세요! 13년차 서버실 지킴이, 13년차 인프라 엔지니어입니다. 오늘은 홈랩(Homelab)에서 많은 분들이 겪는 고질적인 문제, 바로 TrueNAS SMB 성능 최적화에 대해 이야기해보려고 해요. NAS 파일 공유 속도가 답답해서 속 터지는 경험, 혹시 저만 해본 건 아니겠죠? 저도 처음 TrueNAS를 구축하고 파일을 옮기는데, ‘이게 뭔가 싶을 정도로’ 느려서 한참을 삽질했던 기억이 납니다. 😅

    특히 고용량 파일이나 다수의 작은 파일을 자주 주고받아야 할 때, 느린 SMB(Server Message Block) 속도는 정말이지 작업 효율을 떨어뜨리는 주범이 됩니다. 그래서 오늘은 제가 직접 경험하고 설정하면서 얻은 TrueNAS 네트워크 최적화와 SMB 설정 노하우를 아낌없이 공유해 드릴게요. 여러분의 TrueNAS가 쾌적한 고속 파일 공유 서버로 거듭나도록 도와드리겠습니다!

    홈랩에서 TrueNAS SMB 성능을 최적화하기 위한 기본적인 네트워크 구성도입니다. 10GbE 스위치와 클라이언트, TrueNAS 간의 연결을 보여줍니다.

    TrueNAS SMB, 왜 느릴까요? 핵심 개념부터 알아보기

    우선, SMB(Server Message Block)가 뭔지 간단히 짚고 넘어갈까요? 쉽게 말해, 윈도우나 macOS 같은 운영체제에서 네트워크를 통해 파일이나 프린터를 공유하기 위해 사용하는 통신 프로토콜입니다. 우리가 흔히 ‘네트워크 드라이브’나 ‘공유 폴더’라고 부르는 것들이 바로 이 SMB를 통해 작동하더라고요.

    그럼 왜 TrueNAS의 SMB 성능이 기대만큼 나오지 않을까요? 원인은 다양한데, 크게 몇 가지로 나눠볼 수 있어요.

    • 네트워크 병목(Network Bottleneck): 가장 흔한 원인 중 하나예요. 1기가비트 이더넷(Gigabit Ethernet, GbE) 환경에서는 이론상 최대 125MB/s의 속도를 내지만, 실제로는 100~110MB/s 정도가 한계거든요. 10기가비트 이더넷(10GbE)으로 업그레이드하면 훨씬 빨라집니다.
    • 디스크 I/O 성능(Disk I/O Performance): 아무리 네트워크가 빨라도 디스크 자체가 느리면 소용없어요. 특히 HDD(Hard Disk Drive)는 SSD(Solid State Drive)에 비해 랜덤 I/O 성능이 현저히 떨어지더라고요.
    • CPU 및 RAM(CPU & RAM): SMB 서비스 자체도 어느 정도의 CPU 연산과 RAM을 사용합니다. 특히 동시 접속자 수가 많거나 암호화 기능을 사용하면 더 많은 자원이 필요해요.
    • TrueNAS 설정 문제: 오늘 다룰 핵심이죠. TrueNAS 내부의 SMB 설정이나 ZFS 데이터셋(Dataset) 설정에 따라 성능이 크게 달라질 수 있습니다.

    이런 요소들을 종합적으로 고려해서 최적의 TrueNAS SMB 성능을 끌어내는 것이 우리의 목표입니다.

    고속 파일 공유를 위한 준비물과 사전 점검 💡

    본격적인 설정에 들어가기 전에, 몇 가지 준비물과 사전 점검 사항을 확인해 봅시다. 제가 처음엔 이런 것들을 간과하고 무작정 설정만 바꾸려다가 꽤나 삽질 좀 했거든요. ㅎㅎ

    1. 하드웨어 점검

    • 10기가비트 이더넷(10GbE) 환경:
      • TrueNAS 서버 NIC(네트워크 인터페이스 카드): 서버에 10GbE NIC가 장착되어 있는지 확인하세요. 저는 인텔 X540-T2 같은 NIC를 주로 사용하는데, 안정적이고 성능도 괜찮더라고요.
      • 클라이언트 PC NIC: 파일을 주고받을 클라이언트 PC에도 10GbE NIC가 있어야 합니다.
      • 10GbE 스위치(Switch): 모든 10GbE 장비가 연결될 스위치 역시 10GbE를 지원해야 해요. 저렴한 언매니지드(Unmanaged) 스위치도 괜찮지만, 장기적으로는 관리형(Managed) 스위치가 유용할 때가 많습니다.
    • 스토리지(Storage):
      • 성능이 중요한 공유라면 SSD 풀(Pool)을 사용하는 게 좋습니다. 특히 NVMe SSD는 압도적인 성능을 보여주더라고요.
      • HDD 풀이라도 스트라이프(Stripe)나 미러(Mirror) 구성보다는 RAID-Z1, Z2 같은 방식이 쓰기 성능에 유리할 수 있습니다.

    2. 네트워크 케이블 확인

    10GbE 환경에서는 CAT6a 이상의 이더넷 케이블을 사용하는 게 중요합니다. CAT5e나 CAT6 케이블은 짧은 거리에서는 작동할 수 있지만, 장거리에서는 신뢰성과 성능 저하를 일으킬 수 있어요. 저는 처음에 집에 있던 오래된 CAT5e 케이블로 연결했다가 속도가 안 나와서 애를 먹었는데, 케이블을 바꾸니 바로 해결되더라고요! 😅

    TrueNAS SMB 성능 최적화를 위한 설정 가이드

    이제 본격적으로 TrueNAS 설정에 들어가 볼까요? 여기서는 TrueNAS SCALE SMB를 기준으로 설명하지만, CORE 버전에서도 유사한 설정들이 많으니 참고하시면 됩니다.

    1. SMB 서비스 설정

    TrueNAS 웹 UI에 접속하여 서비스(Services) 메뉴에서 SMB(CIFS) 서비스를 찾아 설정합니다.

    1. 고급 설정 활성화: SMB 서비스 설정 화면에서 ‘고급 옵션 표시(Show Advanced Options)’를 클릭하세요.
    2. 서버 최소/최대 프로토콜(Server Minimum/Maximum Protocol):
      • Server Minimum Protocol: SMB2 (SMB1은 보안에 취약하고 성능도 좋지 않습니다. 레거시 시스템이 아니라면 사용하지 마세요.)
      • Server Maximum Protocol: SMB3_11 또는 SMB3 (최신 프로토콜을 사용하는 게 성능과 보안에 모두 유리합니다.)
    3. 보조 매개변수(Auxiliary Parameters): 여기에 성능 향상을 위한 추가 옵션들을 넣어줄 거예요. 한 줄씩 추가합니다.
      4. 
# 비동기 I/O (Asynchronous I/O)를 위한 설정
aio_pthread_cases = 100
aio_pthread_read_cases = 100
aio_pthread_write_cases = 100

# SMB Multi-channel (멀티채널) 활성화 (TrueNAS SCALE만 해당, CORE는 Link Aggregation 사용)
# 여러 네트워크 인터페이스를 사용하여 대역폭을 늘리고 지연 시간을 줄입니다.
# 클라이언트와 서버 모두 Multi-channel을 지원해야 합니다.
server multi channel = yes

# 메타데이터 캐싱 최적화 (Disk I/O 감소)
cache_read_metadata = yes

# 엄격한 할당 비활성화 (쓰기 성능 향상, 주의 필요)
# 클라이언트가 요청한 크기만큼 블록을 미리 할당하지 않도록 합니다.
# 파일 시스템 단편화가 증가할 수 있으나, 쓰기 성능 향상에 기여할 수 있습니다.
strict allocate = no

      💡 팁: strict allocate = no는 파일 시스템 단편화를 유발할 수 있으니, 아주 민감한 환경이 아니라면 기본값(yes)을 유지하는 것도 좋은 선택입니다. 저는 홈랩 환경에서 쓰기 성능을 끌어올리기 위해 사용하곤 하는데, 환경에 따라 선택하시면 됩니다.

    4. 저장(Save) 버튼을 눌러 설정을 적용합니다.

    TrueNAS 웹 UI에서 SMB 서비스의 고급 설정을 변경하는 화면입니다. 보조 매개변수에 주요 최적화 옵션들이 입력되어 있습니다.

    2. 네트워크 인터페이스(NIC) 설정

    네트워크 인터페이스 설정도 TrueNAS 네트워크 최적화의 핵심입니다.

    1. 점보 프레임(Jumbo Frames) 활성화:
      • 네트워크(Network) → 인터페이스(Interfaces) 메뉴로 이동하여 사용할 10GbE NIC를 선택합니다.
      • MTU(Maximum Transmission Unit) 값을 9000으로 변경합니다. (기본값은 1500입니다.)
      • ⚠️ 중요: TrueNAS 서버, 스위치, 클라이언트 PC의 모든 장비가 동일하게 MTU 9000을 지원하고 설정되어야 합니다! 하나라도 다르면 오히려 통신 오류나 성능 저하가 발생할 수 있어요. 제가 이 부분에서 삽질 좀 했거든요. 스위치와 TrueNAS는 설정했는데 클라이언트 MTU를 잊어서 한참을 헤맸던 기억이 나네요.
    2. Link Aggregation(링크 어그리게이션) 또는 SMB Multi-channel(멀티채널):
      • TrueNAS CORE: 여러 개의 1GbE NIC를 묶어 대역폭을 확장하는 Link Aggregation(LACP)을 주로 사용합니다. 스위치에서 LACP 설정을 해주어야 해요.
      • TrueNAS SCALE: SMB Multi-channel을 적극 활용하는 게 좋습니다. 위에 SMB 보조 매개변수에서 server multi channel = yes를 설정했다면, TrueNAS 서버에 여러 개의 NIC가 연결되어 있고 클라이언트도 Multi-channel을 지원하면 자동으로 대역폭을 합쳐서 사용해요. 훨씬 간편하고 효과적입니다.

    3. ZFS 데이터셋(Dataset) 설정 (⚠️ 매우 중요!)

    SMB 공유에 사용할 ZFS 데이터셋의 설정도 성능에 큰 영향을 미칩니다. 특히 동기 쓰기(Synchronous Write)와 관련된 설정은 데이터 안전성과 성능 사이의 트레이드오프가 존재하므로 신중해야 합니다.

    1. 데이터셋(Datasets) 메뉴로 이동하여 공유할 데이터셋을 선택합니다.
    2. 고급 옵션(Advanced Options)에서 동기화(Sync) 설정을 확인합니다.
      • Sync: Standard (기본값)
        • 대부분의 경우 이 설정이 가장 안전하고 균형 잡힌 성능을 제공해요.
        • 데이터 무결성(Data Integrity)을 보장하며, 쓰기 작업이 완료되기 전에 데이터가 디스크에 기록되었는지 확인합니다.
      • Sync: Always (가장 안전하지만, 성능 저하)
        • 모든 쓰기 작업이 디스크에 기록될 때까지 기다리므로, 전력 손실 등의 상황에서도 데이터 손실 위험이 거의 없습니다. 하지만 쓰기 성능은 가장 낮아요.
      • Sync: Disabled (최대 성능, 데이터 손실 위험)
        • 쓰기 작업이 디스크에 기록되었는지 확인하지 않고, 운영체제 캐시에서 쓰기 완료를 보고합니다. 이로 인해 쓰기 성능은 가장 뛰어나지만, 전력 손실이나 시스템 크래시 시 데이터 손실 또는 손상 위험이 매우 높습니다.
        • ⚠️ 경고: 이 옵션은 극단적인 성능이 필요하고 데이터 손실 위험을 감수할 수 있는 경우에만 사용해야 합니다. 절대 중요한 데이터에 사용하지 마세요! 저는 특정 임시 파일 공유나 벤치마크 테스트 시에만 제한적으로 사용해봤습니다.

    주의사항 및 트러블슈팅: 제가 겪었던 삽질들 😱

    자, 이렇게 설정하면 웬만해선 TrueNAS SMB 성능이 확 올라갈 겁니다. 하지만 저처럼 예상치 못한 문제에 부딪힐 수도 있겠죠? 제가 겪었던 몇 가지 삽질 경험과 해결 팁을 공유해 드릴게요.

    1. 점보 프레임 설정 후 오히려 속도가 느려지거나 접속 불가

    앞서 강조했지만, MTU 9000은 TrueNAS, 스위치, 클라이언트 모두 동일하게 설정되어야 해요. 저는 스위치와 TrueNAS는 설정했지만, 윈도우 클라이언트 PC의 NIC 드라이버 설정에서 MTU를 바꾸는 걸 깜빡해서 한참을 헤맸어요. 윈도우에서는 PowerShell이나 NIC 속성에서 설정할 수 있습니다.

    
# 현재 MTU 확인 (Windows)
Get-NetAdapterAdvancedProperty -Name "이더넷 어댑터 이름" | Where-Object {$_.DisplayName -eq "Jumbo Packet"}

# MTU 9000으로 설정 (Windows)
Set-NetAdapterAdvancedProperty -Name "이더넷 어댑터 이름" -RegistryKeyword "JumboPacket" -RegistryValue 9000

    2. 클라이언트 PC의 SMB 캐싱 문제

    가끔 클라이언트 PC에서 이전에 연결했던 SMB 공유의 캐시가 남아있어 성능 측정이 정확하지 않은 경우가 있어요. 이럴 때는 클라이언트 PC를 재부팅하거나, 네트워크 드라이브 연결을 완전히 끊고 다시 연결해보세요.

    3. TrueNAS 리소스 부족

    SMB 성능은 네트워크뿐만 아니라 TrueNAS 서버 자체의 리소스(CPU, RAM)에도 영향을 받습니다. 특히 TrueNAS SCALE SMB는 컨테이너 기반으로 작동하므로, 시스템 리소스 할당이 중요할 수 있어요. TrueNAS 대시보드에서 CPU 사용률, RAM 사용률, 디스크 I/O 등을 모니터링하면서 병목 지점을 찾아보세요.

    TrueNAS 웹 UI에서 시스템 리소스 사용 현황을 모니터링하는 대시보드 화면입니다. CPU, RAM, 네트워크 트래픽 등의 지표를 확인할 수 있습니다.

    검증 및 결과 확인 🎉

    자, 이제 설정도 끝났으니 실제로 NAS 파일 공유 속도가 얼마나 빨라졌는지 확인해 볼 시간입니다! 저는 주로 두 가지 툴을 사용해서 성능을 측정합니다.

    1. iPerf3를 이용한 네트워크 대역폭 테스트

    SMB 성능은 결국 네트워크 대역폭에 크게 좌우됩니다. iPerf3는 네트워크 자체의 최대 처리량을 측정하는 데 정말 유용해요. TrueNAS SCALE에서는 앱(Apps)으로 iPerf3를 설치하거나, CLI에서 직접 실행할 수 있습니다.

    
# TrueNAS 서버에서 iPerf3 서버 실행
iperf3 -s

# 클라이언트 PC에서 iPerf3 클라이언트 실행 (TrueNAS 서버 IP로)
iperf3 -c [TrueNAS_IP] -P 8 -t 30

    이렇게 측정했을 때 10GbE 환경이라면 9~9.5Gbps 정도가 나와야 정상입니다. 만약 1Gbps에 머무르거나 그 이하로 나온다면, 네트워크 케이블, NIC 드라이버, 스위치 설정 등을 다시 점검해 봐야 합니다.

    2. CrystalDiskMark (Windows) 또는 Blackmagic Disk Speed Test (macOS)

    실제 SMB 공유 폴더에 파일을 읽고 쓰는 성능을 측정하는 데 정말 유용한 툴들이예요. 클라이언트 PC에서 공유 폴더를 네트워크 드라이브로 연결한 후 테스트를 진행합니다.

    • CrystalDiskMark: 윈도우 환경에서 가장 널리 사용되는 디스크 벤치마크 툴입니다. 순차 읽기/쓰기, 랜덤 읽기/쓰기 성능을 직관적으로 보여줍니다.
    • Blackmagic Disk Speed Test: macOS 사용자에게 정말 좋은 선택지예요. 비디오 편집 워크로드에 초점을 맞춰 성능을 측정합니다.

    설정 전후로 이 툴들을 돌려보면 확연히 빨라진 TrueNAS SMB 성능을 체감하실 수 있을 거예요. 저는 순차 읽기/쓰기 속도가 110MB/s에서 700~800MB/s (10GbE 환경, SSD 풀)까지 올라가는 걸 보고 쾌재를 불렀습니다! 🎉

    TrueNAS SMB 성능 최적화 전후의 CrystalDiskMark 벤치마크 결과 비교표입니다. 순차 읽기/쓰기 속도 변화를 보여줍니다.

    마무리하며: 쾌적한 홈랩을 위한 끊임없는 탐구

    오늘은 제가 13년차 인프라 엔지니어로 홈랩을 운영하면서 겪었던 TrueNAS SMB 성능 최적화 과정을 공유해 드렸습니다. NAS 파일 공유 속도를 높이기 위해 SMB 설정부터 네트워크 환경, 그리고 ZFS 데이터셋 설정까지 다양한 요소를 고려해야 한다는 걸 다시 한번 깨달으셨을 거예요. 때로는 복잡하고 삽질의 연속일 수 있지만, 드디어 원하는 성능이 나왔을 때의 그 쾌감은 정말 최고랍니다! 😄

    오늘 다룬 내용 외에도 ZFS 캐싱(L2ARC, SLOG)을 활용하거나, 더 고급스러운 네트워크 튜닝을 통해 TrueNAS 네트워크 최적화를 시도해 볼 수도 있어요. 하지만 오늘 제가 알려드린 기본 설정만으로도 대부분의 홈랩 환경에서는 충분히 만족할 만한 TrueNAS SMB 성능 향상을 경험하실 수 있을 겁니다. 여러분의 쾌적한 홈랩 생활에 제 경험이 조금이나마 도움이 되었기를 바랍니다!

    다음번에는 TrueNAS SCALE의 컨테이너 앱 활용법 같은 재미있는 주제로 찾아올게요. 그때까지 즐거운 홈랩 라이프 보내세요! 👋

  • [Nas] Tailscale을 이용한 NAS 외부 접속 가이드: 포트 포워딩 없는 보안 설정

    [Nas] Tailscale을 이용한 NAS 외부 접속 가이드: 포트 포워딩 없는 보안 설정

    목차

    [인프라] Tailscale을 이용한 NAS 외부 접속 가이드: 포트 포워딩 없는 보안 설정

    안녕하세요, 13년차 인프라 엔지니어로 일하며 집에서는 소박하게(?) 홈랩을 운영 중인 ‘서버실’ 주인장입니다. 여러분, 혹시 밖에서 내 NAS(나스)에 접속하고 싶을 때 어떻게 하시나요? 예전 같으면 공유기 설정 페이지에서 포트 포워딩 설정을 하고, DDNS를 맞추느라 삽질하던 게 일상이었거든요. 하지만 보안이 중요해진 지금, 포트를 외부에 그대로 노출하는 건 ‘제발 해킹해주세요’라고 광고하는 것과 다름없더라고요.

    실제로 제 지인 중 한 명은 시놀로지 기본 포트를 열어두었다가 랜섬웨어 공격을 받아 수년간 모은 사진 데이터를 날린 적이 있어요. 그때 제가 멘토로서 권해준 솔루션이 바로 오늘 소개해 드릴 Tailscale(테일스케일)입니다. 오늘은 복잡한 설정 없이, 그리고 보안 구멍 하나 없이 쾌적하게 NAS 외부 접속 환경을 만드는 법을 제 경험을 담아 공유해 보겠습니다.

    Tailscale 메쉬 VPN 작동 원리 다이어그램, NAS 외부 접속 구조

    ▲ 외부 노출 없이 기기 간에 가상의 랜 케이블을 연결하는 Tailscale의 작동 원리

    1. 왜 포트 포워딩 대신 Tailscale인가?

    인프라 엔지니어 관점에서 볼 때, 전통적인 방식의 외부 접속은 몇 가지 치명적인 단점이 있어요.

    • 보안 취약점: 특정 포트(예: 5000, 5001)가 열려 있으면 전 세계 해커들의 스캐닝 대상이 됩니다.
    • CGNAT(통신사 공유 IP) 문제: 요즘 일부 아파트나 원룸 인터넷은 공인 IP를 주지 않아 포트 포워딩 자체가 불가능한 경우가 많아요.
    • 설정의 번거로움: 기기가 늘어날 때마다 일일이 포트를 할당해야 하는 번거로움이 있거든요.

    Tailscale은 WireGuard(와이어가드) 프로토콜을 기반으로 한 Mesh VPN(메쉬 가상 사설망) 서비스예요. 쉽게 말해, 내 스마트폰과 NAS 사이에 전 세계 어디서든 연결되는 ‘보이지 않는 긴 랜 케이블’을 하나 꽂는다고 생각하시면 됩니다. NAT Traversal(NAT 트래버설, NAT 우회) 기술을 사용하기 때문에 포트 포워딩을 단 하나도 할 필요가 없다는 게 이 솔루션의 가장 큰 매력이거든요.

    2. 시놀로지 NAS에서 Tailscale 설정하기

    제가 메인으로 사용하는 시놀로지 NAS를 기준으로 설명해 드릴게요. 정말 놀라울 정도로 간단해서 “이게 끝이야?” 싶으실 거예요.

    1. 패키지 센터 설치: 시놀로지 DSM 패키지 센터에서 ‘Tailscale’을 검색합니다. 예전엔 수동으로 SPK 파일을 설치했는데, 이제 정식 패키지로 등록되어 정말 편해졌더라고요.
    2. 로그인 및 인증: 설치 후 실행 버튼을 누르면 브라우저 창이 뜨면서 로그인을 요청해요. 구글이나 MS 계정으로 로그인하고 ‘Authorize(승인)’ 버튼만 누르면 끝입니다.
    3. 상태 확인: 시놀로지 제어판의 터미널이나 Tailscale Admin Console(관리자 콘솔)에서 내 NAS에 할당된 100.x.x.x 대역의 IP를 확인하세요.
    시놀로지 DSM 패키지 센터에서 Tailscale 설치 화면 컨셉

    ▲ 패키지 센터에서 클릭 몇 번이면 보안 접속 준비가 완료됩니다.

    3. TrueNAS와 리눅스 서버에서의 Tailscale 설정

    TrueNAS를 사용하거나 별도의 리눅스 서버를 운영하시는 분들도 계시죠? 저도 홈랩 한 켠에서 TrueNAS SCALE을 돌리고 있는데, TrueNAS 외부 접속도 정말 간단해요. App(앱) 메뉴를 통해 바로 설치할 수 있거든요.

    # 일반 리눅스 서버에서 명령어로 설치할 때
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

    명령어 한 줄이면 설치가 끝나고, 출력되는 URL을 복사해서 브라우저에 붙여넣기만 하면 인증이 완료돼요. 제가 직접 해보니 Docker 컨테이너로 올리는 것보다 호스트에 직접 설치하는 게 네트워크 성능 면에서 더 잘 나오더라고요.

    4. 포트 포워딩 vs Tailscale 비교표

    인프라 쟁이답게 한눈에 보기 편하게 비교표를 만들어 봤습니다. 왜 제가 Tailscale을 고집하는지 감이 오실 거예요.

    항목 포트 포워딩 Tailscale
    보안성 낮음 (포트 노출) 매우 높음 (종단간 암호화)
    설정 난이도 중간 (공유기 설정 필요) 매우 낮음 (로그인 방식)
    CGNAT 환경 불가 완벽 지원
    속도 직결 (최상) 근접 (WireGuard 가속)

    5. ⚠️ 실제 겪은 트러블슈팅: 연결이 안 될 때?

    설정은 다 했는데 가끔 접속이 안 될 때가 있어요. 제가 삽질하며 배운 팁 몇 가지 드릴게요.

    • Key Expiry(키 만료) 주의: 기본적으로 Tailscale 노드 키는 6개월마다 만료돼요. NAS처럼 365일 켜져 있어야 하는 기기는 관리자 콘솔에서 Disable Key Expiry 설정을 꼭 해주세요.
    • 방화벽 설정: 시놀로지 자체 방화벽에서 Tailscale 인터페이스의 트래픽을 차단하고 있지 않은지 확인해 보세요.
    • MagicDNS 활용: IP 주소 외우기 힘들죠? Tailscale의 MagicDNS 기능을 켜면 <code>http://mynas/ 처럼 기기 이름으로 바로 접속할 수 있어요.
    Tailscale 관리자 콘솔 대시보드 기기 목록 시각화

    ▲ 관리자 콘솔에서 기기 이름과 연결 상태를 한눈에 관리할 수 있습니다.

    6. 보너스: Exit Node(출구 노드) 기능 활용하기

    이건 진짜 꿀팁인데, 해외 출장을 가거나 보안이 취약한 공용 와이파이를 쓸 때 NAS를 Exit Node(출구 노드)로 설정해 보세요. 내 모든 인터넷 트래픽이 집 NAS를 거쳐 나가기 때문에, 해외에서도 한국 IP로 뱅킹을 하거나 넷플릭스를 볼 수 있어요. 인프라 엔지니어가 추천하는 최고의 기능 중 하나죠!

    7. 마무리하며

    지금까지 포트포워딩 없이 NAS에 안전하게 접속하는 가장 스마트한 방법인 Tailscale 설정을 알아봤습니다. 처음엔 “남의 서버를 거치는 거 아냐?”라고 의심했는데, 실제 데이터는 Peer-to-Peer(P2P, 기기 간 직접 연결) 방식으로 흐르고 인증만 거치는 구조라 안심하고 쓰고 있어요.

    복잡한 네트워크 설정 때문에 스트레스받지 마시고, 오늘 바로 Tailscale로 안전한 NAS 라이프를 시작해 보세요. 혹시 설정하다 막히는 부분이 있으면 댓글 남겨주세요. 13년 차 짬밥으로 함께 고민해 드리겠습니다!

    스마트폰에서 LTE망을 이용해 NAS 데이터에 접속하는 모습

    ▲ 외부에서도 LTE/5G로 우리 집 NAS에 안전하게 접속된 모습입니다. 🎉

    다음 글에서는 Tailscale을 활용해 여러 대의 서버를 하나로 묶는 Site-to-Site VPN 구축기를 다뤄볼 예정이니 기대해 주세요!

  • [Nas] Docker Compose로 NAS에 앱 배포 및 관리하기: Synology, TrueNAS SCALE 가이드

    [Nas] Docker Compose로 NAS에 앱 배포 및 관리하기: Synology, TrueNAS SCALE 가이드

    목차

    13년차 서버실: Docker Compose로 NAS 앱 배포 및 관리 – Synology, TrueNAS SCALE 실전 가이드

    안녕하세요! 13년차 인프라 엔지니어입니다. 오늘은 많은 분들이 궁금해하실 주제를 다뤄볼게요. 바로 Docker Compose를 활용해서 NAS(Network Attached Storage)에 다양한 애플리케이션을 배포하고 관리하는 방법인데요. Synology와 TrueNAS SCALE 환경에서 직접 경험했던 내용을 바탕으로 실전 팁을 공유해드리겠습니다. 혹시 NAS를 파일 저장소로만 쓰고 계신가요? Docker Compose와 함께라면 여러분의 NAS가 훨씬 더 똑똑한 홈랩 서버로 변신합니다! 😉

    NAS 환경에서 Docker Compose를 활용한 애플리케이션 배포 및 관리 아키텍처 개요

    왜 NAS에 Docker Compose를 써야 할까요?

    NAS를 운영하다 보면 언젠가는 ‘파일 저장소 말고 다른 기능도 쓰고 싶은데…’ 하는 생각이 들게 돼요. 개인 블로그를 운영하고 싶거나, 영화·음악 스트리밍 서버를 구축하고 싶을 때 말이죠. 예전 같으면 복잡한 설치 과정과 설정 때문에 망설였겠지만, Docker와 Docker Compose를 알게 된 후로는 정말 달라졌어요.

    Docker는 애플리케이션을 컨테이너라는 격리된 환경에 담아 실행하는 기술입니다. 덕분에 운영체제나 다른 프로그램과의 충돌 걱정 없이 원하는 앱을 쉽게 설치하고 실행할 수 있죠. 다만 여러 개의 컨테이너를 묶어서 관리하려면 일일이 명령어를 입력해야 해서 번거로울 때가 많아요. 이때 등장하는 것이 바로 Docker Compose입니다!

    쉽게 말해, Docker Compose는 YAML이라는 설정 파일을 사용해서 여러 컨테이너로 구성된 애플리케이션을 한 번에 정의하고 실행할 수 있게 해주는 도구예요. 마치 오케스트라의 지휘자처럼 여러 악기(컨테이너)들이 조화롭게 연주(실행)되도록 지휘하는 역할을 하는 거죠.

    Docker Compose를 NAS에서 사용하면 좋은 점은 다음과 같아요:

    • ✅ 간편한 배포: 복잡한 설정 과정을 YAML 파일 하나로 정의하고, 단 한 번의 명령어로 여러 컨테이너를 한 번에 띄울 수 있어요.
    • ✅ 쉬운 관리: 컨테이너의 시작, 중지, 재시작, 삭제 등을 Compose 명령어로 간단하게 관리할 수 있습니다.
    • ✅ 재현성: 동일한 YAML 설정 파일만 있으면 언제 어디서든 똑같은 환경을 구축할 수 있어요. 개발, 테스트, 운영 환경 간의 차이로 인한 문제를 줄여주거든요.
    • ✅ 포트 충돌 방지: 각 컨테이너가 사용할 포트(Port)를 명확하게 지정하여 충돌을 피할 수 있습니다.
    • ✅ 확장성: 필요에 따라 컨테이너 수를 늘리거나 줄이기가 정말 쉬워요.

    Synology와 TrueNAS SCALE, Docker Compose 활용법

    Synology DSM과 TrueNAS SCALE은 각기 다른 방식으로 Docker 환경을 제공하지만, Docker Compose를 활용하는 기본 원리는 동일합니다. 핵심은 docker-compose.yml 파일을 작성하고 실행하는 거죠.

    1. Synology NAS에서 Docker Compose 사용하기

    Synology NAS에서는 ‘Docker’ 패키지를 설치하면 Docker Compose 기능을 사용할 수 있어요. DSM의 ‘패키지 센터’에서 Docker를 검색하여 설치해주세요. 저는 보통 SSH로 NAS에 접속해서 작업하는 것을 선호하지만, DSM의 ‘텍스트 편집기’나 ‘File Station’을 이용해 YAML 파일을 작성하고 관리할 수도 있습니다.

    실행 단계:

    1. SSH 접속: Putty(Windows) 또는 터미널(macOS/Linux)을 이용해 NAS에 SSH로 접속합니다.
    2. 작업 디렉토리 생성: 원하는 위치에 애플리케이션을 위한 디렉토리를 만들어요. 예: mkdir /volume1/docker/my-app && cd /volume1/docker/my-app
    3. docker-compose.yml 파일 작성: 텍스트 편집기(vi, nano 등)를 이용해 docker-compose.yml 파일을 생성하고 내용을 작성합니다.
    4. Docker Compose 실행: docker-compose up -d 명령어를 실행하면 설정된 컨테이너들이 백그라운드(-d)에서 실행돼요.

    예시: Nginx 웹 서버와 Portainer (컨테이너 관리 도구) 배포

    Portainer는 Docker 환경을 웹 UI로 쉽게 관리할 수 있게 해주는 정말 유용한 도구예요. NAS에 Portainer를 설치해두면 컨테이너 관리가 훨씬 편해진답니다.

    
version: '3.8'

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    ports:
      - "8000:8000"
      - "9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
    networks:
      - portainer_net

  nginx:
    image: nginx:latest
    container_name: my-nginx
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./html:/usr/share/nginx/html:ro
    depends_on:
      - portainer
    networks:
      - portainer_net

volumes:
  portainer_data:

networks:
  portainer_net:
    driver: bridge

    이 파일을 /volume1/docker/portainer-nginx/docker-compose.yml에 저장하고, 해당 디렉토리에서 docker-compose up -d를 실행하면 Portainer와 Nginx 웹 서버가 동시에 실행돼요. Portainer는 http://NAS_IP:9443 (SSL), Nginx는 http://NAS_IP로 접속할 수 있습니다.

    Synology DSM에서 Docker 패키지를 설치하는 과정

    2. TrueNAS SCALE에서 Docker Compose 사용하기 (TrueNAS SCALE Apps)

    TrueNAS SCALE은 Kubernetes 기반으로 앱을 관리하는 ‘Apps’ 기능을 제공해요. Docker Compose 파일을 직접 사용하는 방식과는 조금 다르지만, Apps 기능을 통해 원하는 애플리케이션을 쉽게 설치하고 관리할 수 있다는 점은 같습니다. TrueNAS SCALE의 Apps는 Helm chart라는 것을 사용하는데, 많은 경우 Docker Compose 파일과 유사한 구조를 가져요.

    실행 단계:

    1. Apps 메뉴 접근: TrueNAS SCALE 웹 UI에서 ‘Apps’ 메뉴로 이동합니다.
    2. Catalogs 설정: 원하는 애플리케이션을 설치하기 위해 Catalog(앱 스토어 같은 개념)를 추가해야 해요. 커뮤니티에서 제공하는 다양한 Catalog들이 있습니다.
    3. 애플리케이션 설치: Catalog에서 원하는 앱을 선택하고 설치를 진행하면 돼요. 커스텀 앱을 직접 등록하여 Docker Compose 파일처럼 관리할 수도 있습니다.

    주의사항: TrueNAS SCALE의 Apps는 Kubernetes 기반이므로, Docker Compose의 docker-compose.yml 파일을 직접 실행하는 방식과는 다릅니다. 하지만 많은 커뮤니티 앱들이 Docker Compose 구조를 따르고 있어서, YAML 파일의 내용을 이해하고 있다면 앱 설정 시 도움이 돼요. 직접 Docker Compose 파일을 적용하려면 TrueNAS CORE의 ‘iocage’ 플러그인이나 TrueNAS SCALE에서 별도의 VM을 구성해야 할 수도 있습니다. 다만 대부분의 일반 사용자는 Apps 기능으로 충분히 원하는 앱을 설치하고 관리할 수 있어요.

    TrueNAS SCALE의 Apps 메뉴에서 다양한 애플리케이션을 탐색하고 설치하는 과정

    실전 팁 & 트러블슈팅 ⚠️

    13년간 Docker를 다루면서 겪었던 문제와 팁을 공유해 드릴게요. 처음엔 이것 때문에 밤새 고생했던 기억이 있어요. ㅎㅎ

    • 포트 충돌 (Port Conflict): 가장 흔한 문제예요. docker-compose.yml 파일에서 ports 섹션에 이미 사용 중인 호스트 포트를 지정하면 컨테이너가 실행되지 않습니다. Synology NAS의 경우, DSM 자체적으로 사용하는 포트와 충돌하지 않도록 주의해야 해요. 예를 들어 80번 포트는 DSM의 웹 스테이션 등이 사용할 수 있으니, 다른 포트(예: 8080)로 변경하는 것이 훨씬 안전합니다.
    • 볼륨 마운트 경로: 컨테이너 내의 데이터가 호스트 NAS의 특정 경로에 저장되도록 volumes 설정을 잘 해야 합니다. Synology에서는 /volume1/docker/app-name 같은 경로를 주로 사용하고, TrueNAS SCALE에서는 /mnt/poolname/dataset/app-name 같은 경로를 써요. 경로가 잘못되면 데이터가 사라지거나 컨테이너가 제대로 동작하지 않을 수 있으니 주의하세요. 경로 지정 시에는 항상 절대 경로(Absolute Path)를 사용하는 게 정답이에요.
    • 권한 문제 (Permission Issues): 컨테이너가 호스트 파일 시스템에 접근할 때 권한 문제가 발생할 수 있습니다. Docker Compose 파일의 user 옵션을 설정하거나, 호스트 볼륨의 권한을 컨테이너 사용자의 권한에 맞게 조정해야 할 수 있어요.
    • Docker Compose 버전 호환성: version 필드에 명시된 Compose 파일 형식 버전과 실제 사용 중인 Docker Compose 엔진 버전 간의 호환성을 확인하세요. 최신 버전에서는 지원되지 않는 기능이 이전 버전에 있을 수 있습니다.
    • 네트워크 설정: 여러 컨테이너가 서로 통신해야 하는 경우, networks 설정을 올바르게 해야 합니다. 기본적으로는 bridge 네트워크가 사용되지만, 복잡한 구성에서는 custom network을 사용해야 할 때도 있어요.

    💡 팁: 문제가 발생했을 때, docker-compose logs 명령어로 해당 서비스의 로그를 확인하세요. 정말 많은 힌트를 얻을 수 있거든요! 저도 이 명령어로 대부분의 문제를 해결했어요.

    결과 확인 및 관리

    Docker Compose 명령어를 통해 컨테이너를 실행한 후에는 상태를 확인하는 것이 중요합니다.

    • docker-compose ps: 현재 실행 중인 컨테이너 목록과 상태를 보여줘요.
    • docker-compose logs -f : 특정 컨테이너의 실시간 로그를 확인할 수 있습니다. (Ctrl+C로 종료)
    • docker-compose down: 실행 중인 컨테이너들을 중지하고 관련된 네트워크, 볼륨 등을 삭제해요. (데이터 보존 여부는 볼륨 설정에 따라 다름)
    • docker-compose pull: Docker 이미지의 최신 버전을 다운로드합니다.
    • docker-compose up -d --build: 설정 파일을 새로 빌드하고 컨테이너를 실행해요.

    Portainer 대시보드를 통해 Synology 또는 TrueNAS SCALE에서 실행 중인 Docker 컨테이너들을 한눈에 관리하는 모습

    마무리하며

    지금까지 Docker Compose를 활용하여 Synology와 TrueNAS SCALE NAS 환경에서 애플리케이션을 배포하고 관리하는 방법에 대해 알아봤습니다. 처음에는 조금 복잡해 보일 수 있지만, 한 번 익혀두면 NAS의 활용도를 정말 무궁무진하게 높일 수 있는 강력한 도구예요.

    저도 처음엔 간단한 웹 서버 하나 띄우는 것도 버거웠는데, 지금은 여러 컨테이너를 엮어 복잡한 서비스를 구축할 수 있게 됐네요. 여러분도 오늘 알려드린 내용을 바탕으로 차근차근 시도해보신다면, 분명 여러분만의 멋진 홈랩 환경을 구축하실 수 있을 겁니다.

    다음 글에서는 Docker Compose를 활용한 Home Assistant 설치 및 연동에 대한 실전 가이드를 다룰 예정이니 많은 기대 부탁드립니다! 혹시 오늘 내용 중에 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 함께 해결해나가겠습니다. 😉

  • [NAS] Docker 컨테이너 5가지 비교 및 설치 가이드: Portainer부터 Vaultwarden까지

    목차

    NAS에 Docker 설치했는데, 뭘 올려야 할지 모르겠다고요?

    저도 처음에 딱 그랬거든요. Synology NAS에 Docker(도커, 컨테이너 기반 가상화 플랫폼)를 설치하고 나서 한참 멍하니 화면만 바라봤었어요. “이제 뭘 하지?” 하는 느낌 있잖아요. 근데 막상 하나씩 써보기 시작하니까, 진짜 NAS가 단순한 저장소에서 홈 서버로 완전히 탈바꿈하더라고요.

    이 글에서는 제가 13년 넘게 인프라를 운영하면서, 홈랩에서 실제로 돌려보고 “이건 진짜 쓸 만하다”고 느낀 NAS Docker 활용을 위한 인기 컨테이너 5가지를 비교하고 설치 방법까지 정리해 드릴게요. 특히 Docker 컨테이너를 처음 다루는 분들께 도움이 될 거예요.

    ▲ NAS 위에 Docker 컨테이너들이 올라가는 전체 구조 — 하나의 NAS가 여러 서비스를 동시에 제공합니다

    NAS Docker, 왜 써야 하나요?

    쉽게 말해, Docker는 “앱을 격리된 박스 안에 담아서 실행하는 기술”이에요. NAS에서 Docker를 활용하면 이런 게 가능해집니다:

    • 기존 NAS OS(DSM 등)에 영향 없이 별도 앱을 설치
    • 설치/삭제가 깔끔하고 충돌이 거의 없음
    • 오픈소스 서비스를 공식 패키지 없이도 자유롭게 설치
    • 업데이트, 백업, 이전이 훨씬 편함

    Synology NAS에서는 DSM의 패키지 센터에서 “Container Manager”라는 이름으로 Docker를 설치할 수 있어요. QNAP은 “Container Station”이라는 이름으로 제공하고 있고요. 둘 다 GUI(그래픽 인터페이스)를 제공하지만, 저는 개인적으로 SSH 터미널로 직접 명령어를 치는 게 훨씬 편하더라고요. 설정 파일도 관리하기 좋고요.

    NAS Docker 인기 컨테이너 5가지 비교

    일단 전체 비교를 한눈에 보고 시작하는 게 좋을 것 같아서 표로 정리했어요.

    컨테이너 카테고리 주요 용도 리소스 사용 난이도
    Portainer 관리 도구 Docker 컨테이너 GUI 관리 매우 낮음 ⭐ 쉬움
    Nginx Proxy Manager 리버스 프록시 도메인/SSL 인증서 관리 낮음 ⭐⭐ 보통
    Jellyfin 미디어 서버 영상/음악 스트리밍 중간~높음 ⭐⭐ 보통
    Nextcloud 클라우드 스토리지 자체 클라우드 저장소 구축 중간 ⭐⭐⭐ 어려움
    Vaultwarden 비밀번호 관리 Bitwarden 호환 셀프호스트 매우 낮음 ⭐⭐ 보통

    이제 하나씩 살펴볼게요. 각 컨테이너별 설치 명령어도 함께 드릴게요.

    1. Portainer — Docker 관리의 시작점

    Portainer는 Docker 컨테이너를 웹 브라우저에서 GUI로 관리할 수 있게 해주는 도구예요. NAS Docker를 시작하는 분들한테 제일 먼저 추천하는 거거든요. 설치도 제일 쉽고, 이게 있으면 나머지 컨테이너 관리가 훨씬 편해지니까요.

    실제로 써보니까, 어떤 컨테이너가 얼마나 CPU/메모리를 쓰는지 한눈에 보이고, 로그도 바로 확인할 수 있어서 문제 해결할 때 정말 유용하더라고요. 특히 컨테이너가 자동으로 재시작되지 않을 때 원인을 빨리 찾을 수 있어요.

    Portainer 설치 명령어

    # Portainer 데이터 저장용 볼륨 생성
docker volume create portainer_data

# Portainer 컨테이너 실행
docker run -d \
  -p 8000:8000 \
  -p 9443:9443 \
  --name portainer \
  --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:latest

    설치 후 https://NAS-IP:9443으로 접속하면 초기 설정 화면이 뜹니다. 관리자 계정을 만들고 나면 끝이에요. 진짜 간단해요.

    💡 팁: Synology의 Container Manager를 쓰고 있더라도 Portainer를 함께 올려놓으면 훨씬 세밀한 관리가 가능합니다. 두 도구를 병행해도 충돌이 없거든요.

    2. Nginx Proxy Manager — 도메인과 SSL을 한 방에

    이건 제가 홈랩에서 정말 애용하는 Docker 컨테이너예요. Nginx Proxy Manager는 리버스 프록시(외부 요청을 내부 서비스로 전달해주는 역할)를 GUI로 쉽게 설정하고, Let’s Encrypt SSL 인증서까지 자동으로 발급·갱신해줘요.

    처음엔 “리버스 프록시가 뭔데?” 싶었는데, 쉽게 말하면 이런 거예요. jellyfin.내도메인.com, nextcloud.내도메인.com 이렇게 서브도메인마다 다른 서비스로 연결해주는 교통 정리 역할이에요. HTTPS(암호화 통신)도 자동으로 붙여주고요.

    Nginx Proxy Manager docker-compose 설정

    version: '3.8'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    container_name: nginx-proxy-manager
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'   # 관리 웹 UI 포트
      - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

    위 내용을 docker-compose.yml 파일로 저장하고 아래 명령어를 실행하면 됩니다:

    docker compose up -d

    설치 후 http://NAS-IP:81로 접속하면 관리 UI가 뜨고요. 초기 계정은 [email protected] / changeme인데, 로그인하자마자 바로 바꿔야 해요. ⚠️ 이거 그냥 두면 정말 위험합니다. 누구나 접속해서 설정을 바꿀 수 있거든요.

    ▲ Nginx Proxy Manager에서 프록시 호스트를 추가하고 SSL 인증서를 자동 발급하는 화면

    3. Jellyfin — 나만의 미디어 서버 만들기

    Jellyfin은 오픈소스 미디어 서버예요. Plex와 비슷한데, 완전 무료에 계정 없이도 쓸 수 있다는 게 큰 장점이에요. NAS에 쌓아둔 영화, 드라마, 음악을 스마트TV, 폰, 태블릿에서 스트리밍할 수 있거든요.

    제가 직접 써보니까, 자막 자동 검색 기능이랑 메타데이터(영화 포스터, 줄거리 등) 자동 수집이 꽤 잘 되더라고요. 다만 하드웨어 트랜스코딩(영상 포맷 변환)은 NAS CPU/GPU 성능에 따라 다르니까 이 부분은 좀 알아보고 써야 해요.

    Jellyfin docker-compose 설정

    version: '3.8'
services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    restart: unless-stopped
    ports:
      - '8096:8096'
    volumes:
      - ./config:/config
      - ./cache:/cache
      - /volume1/media:/media:ro  # NAS 미디어 폴더 경로로 수정하세요
    environment:
      - TZ=Asia/Seoul

    ⚠️ 주의사항: /volume1/media 경로는 본인 NAS의 실제 미디어 폴더 경로로 반드시 바꿔야 합니다. Synology 기준으로는 보통 /volume1/ 아래에 있어요.

    4. Nextcloud — 나만의 클라우드 저장소 구축

    Nextcloud는 자체 클라우드 스토리지를 구축할 수 있는 오픈소스 플랫폼이에요. 구글 드라이브, 드롭박스 같은 서비스를 내 NAS 위에 직접 올리는 거라고 보면 돼요. 파일 공유, 캘린더, 연락처, 노트 등 다양한 기능을 제공해요.

    솔직히 말하면, 다섯 가지 중에 설치가 제일 까다롭습니다. 저도 처음에 삽질을 좀 했어요. 데이터베이스(MariaDB 또는 PostgreSQL)를 함께 올려야 하거든요.

    Nextcloud + MariaDB docker-compose 설정

    version: '3.8'
services:
  db:
    image: mariadb:10.11
    container_name: nextcloud-db
    restart: unless-stopped
    environment:
      - MYSQL_ROOT_PASSWORD=강력한루트비밀번호
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=강력한비밀번호
    volumes:
      - ./db:/var/lib/mysql

  nextcloud:
    image: nextcloud:latest
    container_name: nextcloud
    restart: unless-stopped
    ports:
      - '8080:80'
    depends_on:
      - db
    environment:
      - MYSQL_HOST=db
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=강력한비밀번호
      - TZ=Asia/Seoul
    volumes:
      - ./data:/var/www/html

    ⚠️ 꼭 확인하세요: 비밀번호는 절대 예시 그대로 쓰지 마세요. 복잡한 문자열로 바꿔야 해요. 그리고 Nextcloud는 신뢰된 도메인(trusted_domain) 설정을 별도로 해줘야 외부에서 접속이 돼요. 처음 설치하고 나서 “Access through untrusted domain” 오류가 뜨면 config/config.php 파일에서 trusted_domains 항목을 수정해줘야 합니다.

    5. Vaultwarden — 비밀번호 관리, 직접 호스팅하기

    Vaultwarden은 Bitwarden과 호환되는 비밀번호 관리 서버를 셀프호스팅할 수 있게 해주는 프로젝트예요. Bitwarden 공식 서버 대신 내 NAS에서 직접 돌리는 거라고 보면 돼요.

    이거 설치하고 나서 진짜 감탄했어요. 리소스를 엄청 적게 먹으면서도, Bitwarden 공식 앱이나 브라우저 확장 프로그램을 그대로 연결해서 쓸 수 있거든요. 비밀번호가 내 서버에만 저장되니까 보안 측면에서도 마음이 편하고요.

    Vaultwarden docker-compose 설정

    version: '3.8'
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    ports:
      - '8888:80'
    volumes:
      - ./vw-data:/data
    environment:
      - TZ=Asia/Seoul
      - SIGNUPS_ALLOWED=true  # 초기 계정 생성 후 false로 변경 권장

    💡 중요 포인트: Vaultwarden은 반드시 HTTPS 환경에서만 제대로 동작해요. 앞서 설치한 Nginx Proxy Manager와 조합해서 SSL을 붙여줘야 합니다. HTTP로는 브라우저 확장 프로그램 연결이 안 되더라고요. 저도 이거 몰라서 한참 헤맸었어요.

    ▲ Portainer에서 5개의 컨테이너가 모두 정상 실행(Running) 상태인 것을 확인하는 화면

    ⚠️ NAS Docker 활용 시 자주 겪는 문제들

    포트 충돌 문제

    NAS 앱 설치를 많이 해두셨다면, 포트 번호가 겹칠 수 있어요. 예를 들어 Synology의 기본 웹 서비스가 80, 443 포트를 이미 쓰고 있을 수 있거든요. 이럴 때는 컨테이너의 호스트 포트 번호를 바꿔주면 됩니다. 8080:80처럼 앞 숫자(호스트 포트)를 안 쓰는 번호로 바꿔주세요.

    볼륨 권한 문제

    NAS에서 Docker 볼륨을 마운트할 때 권한 오류가 나는 경우가 꽤 있어요. 특히 Synology에서 Permission denied 오류가 뜨면, 해당 폴더의 소유자와 권한을 확인해보세요.

    # 폴더 소유자 확인
ls -la /volume1/docker/

# 권한 수정 (예시)
chown -R 1000:1000 /volume1/docker/nextcloud/

    메모리 부족

    NAS 램이 4GB 이하라면, 컨테이너를 너무 많이 올리면 전체 시스템이 느려질 수 있어요. 특히 Nextcloud + MariaDB 조합은 생각보다 메모리를 좀 먹거든요. 처음에는 2~3개부터 시작하는 걸 추천드려요.

    설치 전 체크리스트

    1. NAS에 Docker(Container Manager 또는 Container Station) 설치 완료 확인
    2. SSH 접속 활성화 (명령어 방식 사용 시)
    3. Docker 저장 경로 설정 — 가급적 빠른 볼륨(SSD 캐시 있는 풀)에 배치
    4. 포트 충돌 여부 사전 확인
    5. 외부 접속 필요 시 공유기 포트포워딩 설정
    6. 도메인 보유 여부 확인 (Nginx Proxy Manager, Vaultwarden 사용 시 필요)

    ▲ NAS Docker 인기 컨테이너 5가지 용도, 난이도, 리소스 사용량 한눈에 비교

    자주 묻는 질문 (FAQ)

    Q. Synology NAS에서 Docker를 못 쓰는 모델이 있나요?

    네, 있어요. Synology 기준으로 Intel/AMD x86-64 아키텍처 모델에서만 Container Manager(Docker)가 지원됩니다. ARM 기반의 일부 보급형 모델(J 시리즈 등)은 지원이 제한될 수 있으니, 설치 전에 Synology 공식 호환성 페이지에서 확인해보세요.

    Q. docker-compose 명령어가 안 먹혀요.

    최신 Docker에서는 docker-compose(하이픈 있는 구버전) 대신 docker compose(공백, 플러그인 방식)를 사용해요. 둘 다 안 된다면 Docker Compose 플러그인이 설치됐는지 확인해보세요.

    Q. 컨테이너가 재부팅 후 자동 시작이 안 돼요.

    restart: unless-stopped 옵션이 docker-compose에 들어있는지 확인하세요. 명령어 방식으로 실행했다면 --restart=unless-stopped 옵션을 추가해야 합니다.

    NAS Docker 활용, 이렇게 시작하세요

    오늘 소개한 다섯 가지 컨테이너 중에서 처음 시작하는 분들께는 이 순서를 추천드려요:

    1. Portainer 먼저 설치 → Docker 전체 현황 파악
    2. Nginx Proxy Manager 설치 → 도메인/SSL 환경 구축
    3. 그다음 원하는 서비스(Jellyfin, Nextcloud, Vaultwarden) 순서대로 추가

    처음부터 다 설치하려고 하면 꼬이기 쉬워요. 저도 처음에 욕심 부리다가 포트 다 꼬이고 한참 삽질했거든요. 하나씩 안정화시키면서 늘려가는 게 훨씬 낫더라고요.

    Docker Compose를 사용하면 설정 파일 하나로 관리가 되니까, 처음부터 compose 방식에 익숙해지는 걸 강력히 권장합니다. 나중에 마이그레이션이나 백업할 때 훨씬 편해요.

    다음 글에서는 Nginx Proxy Manager와 Let’s Encrypt를 연동해서 외부에서 안전하게 홈서버에 접속하는 방법을 더 자세히 다룰 예정이에요. 이 글에서 설치한 컨테이너들을 외부에서 HTTPS로 접근하게 만드는 실전 가이드가 될 거예요. 🎉

    궁금한 점이나 삽질 경험 있으시면 댓글로 나눠주세요. 같이 해결해봐요!

  • [NAS] TrueNAS SCALE 앱 배포: Docker 컨테이너부터 관리까지

    목차

    NAS가 단순 저장소였던 시대는 끝났습니다

    홈랩을 운영하다 보면 어느 순간 이런 생각이 드시지 않나요? “NAS에 데이터만 넣어두기엔 너무 아깝다.” 저도 처음엔 그냥 파일 서버로 쓰다가, 어느 날 Plex를 띄워보고 나서 생각이 완전히 바뀌었거든요. 그 이후로 TrueNAS SCALE 위에서 십수 개의 서비스를 돌리고 있습니다.

    근데 솔직히 말씀드리면, 처음에 TrueNAS SCALE 앱 시스템을 접했을 때 꽤 헷갈렸어요. 버전마다 배포 방식이 달라지고, 한글 자료도 많지 않아서 삽질을 꽤 했거든요. 이번 글에서는 제가 직접 겪어온 경험을 바탕으로, TrueNAS SCALE에서 앱을 배포하고 관리하는 방법을 처음부터 끝까지 정리해 드리겠습니다.

    TrueNAS SCALE 위에서 여러 컨테이너 앱이 동작하는 홈랩 전체 아키텍처. 스토리지, 네트워킹, 앱 레이어가 통합된 모습입니다.

    TrueNAS SCALE 앱 시스템이 바뀐 이유

    여기서 중요한 역사 이야기를 하나 해야 할 것 같아요. TrueNAS SCALE의 앱 시스템은 버전을 거치면서 꽤 큰 변화가 있었거든요.

    초기 버전(Angelfish, Bluefin, Cobia 등)에서는 K3s(경량 쿠버네티스)를 기반으로 앱을 운영했습니다. 쿠버네티스를 쓴다니까 좋아 보이긴 했는데, 일반 홈랩 사용자 입장에서는 진입 장벽이 꽤 높았어요. Helm 차트 구조도 이해해야 하고, 리소스 관리가 복잡하다는 불만도 많았고요.

    그래서 iXsystems는 Electric Eel(24.10) 버전부터 TrueNAS SCALE 앱 시스템을 Docker Compose 기반으로 전면 바꿨습니다. 쿠버네티스를 걷어내고 훨씬 직관적인 Docker Compose 방식을 채택한 거죠. 솔직히 처음엔 “아니 왜 바꾸는 거야”라고 생각했는데, 써보니 훨씬 낫더라고요.

    • 이전(~Dragonfish): K3s + Helm Chart 기반, TrueCharts 커뮤니티 카탈로그 의존도 높음
    • 이후(Electric Eel~): Docker Compose 기반, 공식 카탈로그 + 커스텀 컨테이너 지원

    이 글은 Electric Eel 이후의 Docker Compose 기반 앱 시스템을 중심으로 설명합니다. 혹시 구버전 사용 중이시라면 업그레이드를 먼저 하시길 권장합니다.

    시작 전 준비사항 체크

    본격적으로 TrueNAS SCALE 앱 배포에 들어가기 전에 확인해야 할 것들이 있어요. 저도 이걸 안 하고 바로 들어갔다가 중간에 막혀서 처음부터 다시 한 경험이 있거든요 😅

    1. 풀(Pool) 설정 확인: 앱 데이터를 저장할 ZFS 풀이 생성되어 있어야 합니다. 저는 SSD 별도 풀을 만들어서 앱 전용으로 씁니다.
    2. Apps 전용 풀 지정: TrueNAS SCALE에서 Apps 탭으로 이동하면, 앱 데이터를 저장할 풀을 처음 한 번 지정하게 돼 있어요. 나중에 바꾸기 귀찮으니 처음에 잘 골라두세요.
    3. 네트워크 설정: 외부에서 접근이 필요한 앱이라면, 공유기 포트 포워딩이나 Reverse Proxy(리버스 프록시) 설정도 미리 생각해두면 좋습니다.
    4. TrueNAS SCALE 버전: 앞서 말씀드린 것처럼, 가능하면 Electric Eel(24.10) 이상으로 업그레이드하고 시작하세요.

    TrueNAS SCALE 앱 카탈로그에서 첫 번째 앱 설치하기

    준비가 됐다면 이제 실전입니다! TrueNAS SCALE 웹 UI 왼쪽 메뉴에서 Apps를 클릭하세요. 처음 접속하면 앱 풀(pool)을 선택하라고 나옵니다. 앞서 준비한 풀을 선택하면 돼요.

    앱 화면으로 들어오면 Discover Apps 버튼이 보입니다. 여기서 공식 카탈로그에 등록된 앱들을 검색하고 설치할 수 있어요. Plex, Nextcloud, Jellyfin, Home Assistant 같은 인기 홈랩 앱들이 대부분 등록되어 있습니다.

    예시로 Jellyfin(미디어 서버)을 설치해볼게요.

    1. Discover Apps에서 “Jellyfin” 검색
    2. 앱 카드 클릭 → Install 버튼 클릭
    3. 설정 화면에서 주요 항목 입력:
      • Application Name: jellyfin (기본값 그대로)
      • Network Configuration: 포트 번호 설정 (기본 8096)
      • Storage Configuration: 미디어 파일이 있는 데이터셋 경로 지정
    4. Install 클릭 후 배포 완료 대기

    설치가 완료되면 앱 목록에 Jellyfin이 나타나고, http://NAS-IP:8096으로 접속할 수 있어요. 드디어 됐다! 라는 느낌이 이때 오더라고요 🎉

    TrueNAS SCALE Apps 탭의 카탈로그 화면. Discover Apps에서 원하는 앱을 검색하고 GUI로 간편하게 설치할 수 있습니다.

    Docker 컨테이너 직접 배포하기 (Custom App)

    카탈로그에 없는 앱을 써야 할 때가 있죠. 저도 특정 오픈소스 툴을 올리고 싶은데 카탈로그에 없을 때, 직접 Docker 이미지를 지정해서 배포하는 방법을 씁니다. Docker on TrueNAS를 활용하는 방식이에요.

    Discover Apps 화면 오른쪽 위를 보면 Custom App 버튼이 있습니다. 이걸 누르면 Docker Compose 방식으로 직접 컨테이너를 정의할 수 있는 화면이 나와요.

    예시로 Uptime Kuma(서비스 모니터링 앱)를 커스텀 앱으로 배포해볼게요.

    # Custom App 설정에서 사용하는 Docker Compose 예시
services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    ports:
      - "3001:3001"
    volumes:
      - /mnt/pool/apps/uptime-kuma:/app/data
    restart: unless-stopped

    TrueNAS SCALE의 Custom App UI에서는 이걸 GUI 폼으로 입력할 수 있어요. 직접 YAML을 쓰는 방식도 지원되고, 폼 형태로도 입력 가능합니다.

    핵심 입력 항목들은 이렇습니다:

    항목 설명 예시
    Image Repository Docker Hub 이미지 이름 louislam/uptime-kuma
    Image Tag 버전 태그 latest 또는 1.23.x
    Container Port 컨테이너 내부 포트 3001
    Node Port 호스트에서 접근할 포트 3001
    Host Path TrueNAS 데이터셋 경로 /mnt/pool/apps/uptime-kuma
    Mount Path 컨테이너 내부 마운트 경로 /app/data

    💡 팁: 볼륨 경로는 반드시 미리 ZFS 데이터셋으로 만들어두고 마운트하는 게 좋습니다. 그냥 디렉토리 경로를 쓰면 나중에 스냅샷 관리가 안 되거든요. 이거 처음에 몰라서 나중에 다 옮긴 적이 있습니다 ㅎㅎ.

    환경 변수와 네트워크 설정 팁

    컨테이너를 배포할 때 환경 변수(Environment Variable) 설정이 필요한 경우가 많아요. 예를 들어 데이터베이스 비밀번호, API 키 같은 것들이요.

    Custom App 설정 화면에서 Environment Variables 섹션을 찾으면 Key-Value 형태로 추가할 수 있습니다.

    # 환경 변수 예시 (Nextcloud 같은 경우)
MYSQL_DATABASE=nextcloud
MYSQL_USER=ncuser
MYSQL_PASSWORD=your_secure_password
NEXTCLOUD_ADMIN_USER=admin
NEXTCLOUD_ADMIN_PASSWORD=admin_password

    네트워크 관련해서 한 가지 더 말씀드리면, TrueNAS SCALE에서 여러 앱이 서로 통신해야 할 때(예: 웹 앱 + DB 컨테이너) 같은 Docker 네트워크에 묶어야 해요. Custom App에서 Network Configuration 섹션에서 네트워크를 지정할 수 있습니다. 이 부분은 처음엔 좀 헷갈릴 수 있는데, 같은 앱 스택이라면 동일한 사용자 정의 네트워크를 사용하면 돼요.

    ⚠️ 트러블슈팅: 자주 겪는 문제들

    13년 동안 인프라 일을 하면서 깨달은 건, 문서대로 안 되는 게 정상이라는 거예요 ㅎㅎ. TrueNAS SCALE 앱 배포하면서 자주 만나는 문제들과 해결법을 공유합니다.

    문제 1: 앱이 Deploying 상태에서 멈춤

    가장 흔한 문제예요. 배포 눌렀는데 한참 동안 Deploying 상태에서 안 바뀌는 경우.

    원인 대부분은 이미지 풀(pull) 실패입니다. 이미지 이름이 틀렸거나, NAS가 인터넷에 제대로 연결 안 됐을 때 주로 발생해요.

    # TrueNAS Shell에서 컨테이너 로그 확인
docker logs [컨테이너_이름]

# 이미지가 제대로 받아졌는지 확인
docker images | grep [앱_이름]

    문제 2: 볼륨 마운트 권한 오류

    앱은 뜨는데 데이터를 못 쓰는 경우가 있어요. 특히 컨테이너가 특정 UID로 실행되는데, 마운트한 경로의 소유자가 다를 때 발생합니다.

    # TrueNAS Shell에서 권한 확인 및 수정
ls -la /mnt/pool/apps/uptime-kuma

# 필요하다면 소유자 변경 (999는 예시 UID, 앱마다 다름)
chown -R 999:999 /mnt/pool/apps/uptime-kuma

    💡 팁: Docker Hub의 해당 이미지 문서에 어떤 UID로 실행되는지 나와 있는 경우가 많아요. 미리 확인하고 데이터셋 권한을 맞춰두면 삽질을 줄일 수 있습니다.

    문제 3: 포트 충돌

    “이미 사용 중인 포트”라는 오류가 뜨는 경우요. 앱들이 기본 포트가 겹칠 때 발생합니다. 예를 들어 여러 웹 앱이 다 80번 포트를 쓰려 하면 충돌이 나죠.

    해결책은 단순합니다. 앱 설치 시 Node Port를 겹치지 않게 다른 번호로 바꿔주면 돼요. 저는 개인적으로 앱별로 포트 번호를 스프레드시트에 정리해두고 쓰고 있습니다. 처음엔 귀찮아 보여도, 앱이 10개 이상 넘어가면 이게 필수예요.

    TrueNAS SCALE 앱 관리 및 업데이트

    설치하고 끝이 아니죠. 앱 관리도 중요합니다. TrueNAS SCALE에서 설치된 앱의 업데이트는 Apps 탭 → Installed 화면에서 할 수 있어요.

    업데이트 가능한 앱이 있으면 배지(badge)가 표시되고, Update All 버튼으로 한 번에 업데이트도 가능합니다. 근데 저는 한 번에 다 올리기보다는, 중요한 앱은 하나씩 올리고 확인하는 편이에요. 한 번에 다 올렸다가 뭔가 깨지면 어디서 문제가 생긴 건지 찾기 어렵거든요.

    앱 데이터 백업은 ZFS 스냅샷을 활용하는 게 최고입니다. 앱 데이터를 담은 데이터셋에 정기 스냅샷을 걸어두면, 앱이 망가졌을 때 스냅샷으로 롤백이 가능해요. 이게 TrueNAS SCALE을 쓰는 가장 큰 이유 중 하나라고 생각합니다.

    TrueNAS SCALE Apps의 Installed 탭. 실행 중인 앱 상태, 업데이트 가능 여부, 리소스 사용량을 한눈에 확인할 수 있습니다.

    ✅ 실전 구성: 제 홈랩 앱 운영 사례

    참고로 현재 제가 TrueNAS SCALE 위에서 돌리고 있는 주요 앱들을 공유할게요. 비슷한 구성을 계획하시는 분들께 도움이 될 것 같아서요.

    앱 이름 용도 설치 방법
    Jellyfin 미디어 서버 (영화, 음악) 공식 카탈로그
    Nextcloud 개인 클라우드 스토리지 공식 카탈로그
    Home Assistant 스마트홈 허브 공식 카탈로그
    Uptime Kuma 서비스 모니터링 Custom App
    Vaultwarden 비밀번호 관리자 Custom App
    Nginx Proxy Manager 리버스 프록시 + SSL Custom App

    모두 ZFS 데이터셋에 데이터를 저장하고, 매일 새벽 3시에 스냅샷이 자동으로 찍히도록 설정해뒀습니다. 덕분에 앱 업데이트 실패나 설정 꼬임 같은 상황에서도 걱정 없이 복구할 수 있어요. 실제로 Home Assistant 업데이트 후 통합 설정이 날아갔을 때 스냅샷으로 5분 만에 복구한 적도 있습니다 😅

    현재 운영 중인 홈랩의 앱 구성 요약. TrueNAS SCALE 위에서 미디어, 클라우드, 모니터링, 보안 앱들이 유기적으로 연동되는 모습입니다.

    마무리: TrueNAS SCALE 앱 배포, 이렇게 시작하세요

    오늘 다룬 내용을 간단히 정리해볼게요.

    • ✅ TrueNAS SCALE은 Electric Eel(24.10)부터 Docker Compose 기반 앱 시스템으로 전환됨
    • ✅ 공식 카탈로그 앱은 GUI로 손쉽게 설치 가능
    • ✅ 카탈로그에 없는 앱은 Custom App 기능으로 Docker 이미지 직접 지정 배포
    • ✅ 볼륨은 반드시 ZFS 데이터셋으로 분리해서 관리할 것
    • ✅ 스냅샷 정책을 함께 설정해두면 백업/복구가 정말 편함

    처음 TrueNAS SCALE 앱 시스템을 접하면 설정 항목이 많아서 막막할 수 있어요. 근데 한 번 익숙해지면 정말 편합니다. 스토리지와 앱을 같은 플랫폼에서 관리한다는 게 이렇게 편할 줄 몰랐다는 생각이 드실 거예요.

    다음 글에서는 Nginx Proxy Manager와 Let’s Encrypt를 이용한 HTTPS 설정을 다룰 예정입니다. 외부에서 도메인으로 안전하게 접근하는 방법인데, 홈랩을 한 단계 업그레이드하고 싶은 분들께 유용할 거예요. 이전 글에서 다뤘던 ZFS 데이터셋 구성과 함께 보시면 더 도움이 됩니다.

    궁금한 점이 있으면 댓글로 남겨주세요. 같이 삽질하며 발전하는 홈랩 라이프, 응원합니다! 🎉

  • [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 문제를 겪고 계신가요? 댓글로 상황을 공유해주시면 같이 해결해봅시다. 이런 거 함께 나누는 게 커뮤니티의 힘이라고 생각하거든요.

  • [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 초기 세팅 가이드를 다뤘으니 참고해 보세요.

  • [NAS] Synology DSM 7.2 vs 7.3 비교: 내 환경에 맞는 버전 선택법

    [NAS] Synology DSM 7.2 vs 7.3 비교: 내 환경에 맞는 버전 선택법

    목차

    업그레이드할까, 말까? DSM 버전 선택의 기로에서

    NAS를 운영하다 보면 어느 날 갑자기 알림이 뜨죠. “DSM 새 버전이 출시되었습니다.” 저도 처음엔 무조건 업그레이드하는 편이었는데, 몇 번 삽질을 겪고 나서부터는 좀 신중해졌거든요. 특히 홈랩이 아니라 실제 업무에 쓰는 NAS라면 더더욱요.

    요즘 Synology DSM 7.2 vs 7.3 비교에 대한 질문을 커뮤니티에서 정말 많이 보더라고요. “7.3으로 올려도 되나요?”, “7.2랑 뭐가 다른가요?” 이런 질문들 말이에요. 13년 동안 인프라를 만지다 보니 이런 버전 비교가 얼마나 중요한지 잘 알고 있습니다. 성급하게 올렸다가 특정 패키지가 안 되거나, 예상치 못한 동작 변화로 밤새 고생한 적이 한두 번이 아니거든요.

    그래서 오늘은 Synology DSM 비교를 제대로 해보려고 합니다. 단순히 “7.3이 더 최신이니까 좋다”가 아니라, 각 버전의 실제 특징과 내 환경에 맞는 선택이 뭔지 함께 살펴보겠습니다.

    Synology DSM 7.2 vs 7.3 버전 비교 개요 다이어그램

    ▲ DSM 7.2와 7.3의 주요 변경사항을 한눈에 정리한 개요도. 두 버전의 핵심 차이를 시각적으로 비교해보세요.

    DSM이 뭔지 잠깐 짚고 가자면 (NAS 운영체제 기초)

    DSM(DiskStation Manager)은 Synology NAS에 탑재된 운영체제(OS)입니다. 쉽게 말해, Synology NAS의 두뇌 역할을 하는 소프트웨어죠. 윈도우나 macOS처럼 웹 브라우저로 접속해서 파일 관리, 패키지 설치, 네트워크 설정 등 모든 걸 할 수 있어요.

    DSM은 버전이 올라갈수록 보안 패치, 새로운 기능, 성능 개선이 이루어집니다. 근데 여기서 중요한 포인트! 버전이 높다고 무조건 내 환경에 맞는 건 아니에요. 특히 다음과 같은 경우라면 더 신중하게 봐야 합니다.

    • 오래된 Synology 모델을 사용 중인 경우
    • 특정 서드파티 패키지에 의존하는 경우
    • 24/7 무중단 운영이 필요한 비즈니스 환경
    • Docker나 Virtual Machine Manager를 적극 활용하는 경우

    DSM 7.2: 안정성의 대명사

    DSM 7.2는 2023년에 출시되어 꽤 오랜 기간 안정화된 버전입니다. 제가 실제로 메인 NAS(DS923+)에서 7.2를 꽤 오래 써봤는데, 솔직히 말해서 “이거 진짜 안정적이다”라는 인상을 받았어요.

    DSM 7.2의 주요 특징

    • 불변 스냅샷(Immutable Snapshot): 랜섬웨어 공격에도 스냅샷을 보호할 수 있는 기능. 이거 진짜 중요한 기능입니다.
    • SMB 멀티채널(SMB Multichannel): 네트워크 카드 여러 개를 묶어서 파일 전송 속도를 높이는 기능
    • SSD 캐시 어드바이저(SSD Cache Advisor): SSD 캐시 설정 최적화 도우미
    • WORM(Write Once Read Many) 지원 강화: 데이터 보존 정책 관련
    • 개선된 Storage Pool 관리: 스토리지 풀(저장공간 묶음) 관리 UI 개선

    7.2는 출시된 지 시간이 지나면서 마이너 업데이트(7.2-64570 등)가 꾸준히 나와서, 알려진 버그들이 대부분 수정된 상태예요. 저도 처음엔 헷갈렸는데, 이 “마이너 업데이트”들이 쌓이면 실제로 상당히 안정적인 환경을 만들어주더라고요.

    DSM 7.3: 새로운 기능의 최전선

    DSM 7.3은 최신 버전으로, 2024년에 출시되었습니다. 제가 홈랩 테스트용 DS220+에 설치해서 써봤는데, 확실히 눈에 띄는 변화들이 있더라고요.

    DSM 7.3의 주요 특징

    • Synology Photos 대폭 개선: AI 얼굴 인식 정확도 향상, 앨범 공유 기능 강화
    • Storage Analyzer 개선: 스토리지 분석 도구가 더 직관적으로 바뀌었어요
    • Active Directory 연동 개선: 기업 환경에서 AD(액티브 디렉토리, 사용자 계정 통합 관리 시스템) 연동이 더 매끄러워짐
    • 보안 강화: 2FA(이중 인증) 정책 강화, 비밀번호 정책 세분화
    • 하이퍼백업(Hyper Backup) 성능 향상: 백업 속도와 복원 안정성 개선
    • 네트워크 설정 UI 개편: 인터페이스가 더 정리된 느낌

    처음 7.3을 설치했을 때 “어, 여기 이게 바뀌었네?” 하는 순간이 몇 번 있었어요. 특히 사진 관련 기능을 많이 쓰시는 분들은 체감 차이가 꽤 크더라고요.

    DSM 7.3 새로운 기능 대시보드 비교 화면

    ▲ DSM 7.3에서 새롭게 개편된 주요 기능들. Photos 개선, 보안 강화, Storage Analyzer 업데이트 등 눈에 띄는 변화들을 확인할 수 있습니다.

    DSM 7.2 vs 7.3 비교표

    말로만 하면 헷갈리니까, 표로 정리해볼게요. 제가 직접 써보면서 느낀 점들을 반영했습니다.

    항목 DSM 7.2 DSM 7.3
    안정성 ⭐⭐⭐⭐⭐ 매우 안정적 ⭐⭐⭐⭐ 안정적 (개선 중)
    보안 패치 지속 제공 중 최신 패치 포함
    Synology Photos 기본 기능 AI 개선, 공유 강화
    SMB 멀티채널 ✅ 지원 ✅ 지원 (개선)
    불변 스냅샷 ✅ 지원 ✅ 지원
    Active Directory 기본 지원 개선된 연동
    Hyper Backup 안정적 성능 향상
    Docker/Container Manager 안정적 일부 호환성 확인 필요
    구형 모델 지원 더 넓은 지원 범위 일부 구형 모델 제외 가능
    서드파티 패키지 호환성 검증 완료 일부 미검증
    권장 대상 안정성 우선, 비즈니스 환경 최신 기능 원하는 홈 유저

    ⚠️ 업그레이드 전 꼭 확인해야 할 것들

    여기서 제가 직접 겪은 삽질 경험을 좀 공유해야 할 것 같아요. 실제로 DSM을 업그레이드하다가 낭패를 본 경우들이 있거든요.

    1. 내 NAS 모델이 지원되는지 먼저 확인

    DSM 7.3은 일부 구형 모델을 지원하지 않을 수 있습니다. Synology 공식 호환성 목록을 반드시 확인하세요. 저도 예전에 DS718+를 쓸 때 버전 호환성 문제로 한참 고생했었는데, 사전에 확인만 했어도 됐을 일이었어요.

    2. 서드파티 패키지 호환성 체크

    이게 진짜 중요합니다. Plex Media Server, SurveillanceStation, 또는 직접 설치한 커뮤니티 패키지들이 7.3에서 정상 동작하는지 미리 확인하세요. 커뮤니티 포럼에서 같은 패키지를 쓰는 사람들의 후기를 보는 게 제일 빠릅니다.

    3. 업그레이드 전 반드시 백업

    이건 당연한 얘기지만, 실제로 안 하는 분들이 많더라고요. DSM 업그레이드 전에는 반드시 설정 백업(Configuration Backup)과 중요 데이터 백업을 먼저 하세요.

    # DSM 설정 백업 (웹 UI 경로)
# 제어판 > 업데이트 및 복원 > 설정 백업
# 또는 SSH 접속 후 아래 경로 확인
ls /var/packages/  # 설치된 패키지 목록 확인
cat /etc/synoinfo.conf  # 시스템 설정 파일 확인

    4. Docker 컨테이너 사용자라면 특히 주의

    Container Manager(구 Docker 패키지)를 많이 활용하고 계신 분들은 7.3 업그레이드 후 일부 네트워크 설정이나 볼륨 마운트 방식이 바뀌어 있을 수 있어요. 제가 테스트할 때 Portainer 연동에서 잠깐 이슈가 있었거든요. 업그레이드 후 컨테이너 상태를 꼭 확인하세요.

    # SSH 접속 후 컨테이너 상태 확인
docker ps -a
docker network ls

# 문제 발생 시 컨테이너 로그 확인
docker logs [컨테이너_이름] --tail 50

    5. 업그레이드는 낮 시간대에 (야간 업그레이드 금지!)

    이건 경험에서 나온 조언인데요, NAS 업그레이드는 반드시 본인이 모니터링할 수 있는 시간대에 하세요. 저는 한 번 야간에 자동 업데이트 켜놨다가 아침에 일어나보니 NAS가 응답 없는 상태여서 식은땀 흘렸던 적이 있어요. 다행히 재부팅으로 해결됐지만요.

    내 상황에 맞는 DSM 버전 선택 가이드

    “그래서 뭘 써야 하나요?”라는 질문에 답해드릴게요. 상황별로 정리해봤습니다.

    ✅ DSM 7.2를 유지하는 게 나은 경우

    • 소규모 비즈니스나 사무실 환경에서 사용 중인 경우
    • 특정 서드파티 패키지(Plex, Surveillance Station 등)에 강하게 의존하는 경우
    • 구형 Synology 모델(2018년 이전 출시 모델)을 사용 중인 경우
    • 현재 아무 문제 없이 잘 쓰고 있는 경우 (“돌아가고 있으면 건드리지 마라”는 인프라 격언이 있죠)
    • Docker/Container Manager로 많은 서비스를 운영 중인 경우

    ✅ DSM 7.3으로 업그레이드하면 좋은 경우

    • Synology Photos를 메인으로 사용하는 홈 유저
    • 최신 보안 패치가 최우선인 경우
    • Active Directory 연동을 더 잘 활용하고 싶은 경우
    • Hyper Backup 성능 개선이 필요한 경우
    • 최신 모델(DS923+, DS1823xs+ 등) 사용자

    💡 결론적으로 제 추천은?

    솔직히 말씀드리면, 홈 유저라면 7.3으로 올리세요. 새 기능들이 실생활에 유용하고, 보안 패치도 최신으로 받을 수 있으니까요. 단, 위에서 언급한 사전 확인 작업은 꼭 하시고요.

    반면에 업무용이거나 특정 패키지 의존성이 높다면 7.2를 좀 더 유지하시는 걸 추천합니다. 7.3이 좀 더 안정화될 때까지 기다리는 것도 나쁘지 않아요. 인프라에서 “최신 = 최선”은 아닌 경우가 많거든요.

    DSM 7.2와 7.3 버전 선택 결정 흐름도

    ▲ 내 환경에 맞는 DSM 버전 선택 흐름도. 사용 목적과 환경에 따라 7.2 유지 또는 7.3 업그레이드를 결정하는 기준을 시각화했습니다.

    DSM 7.3 업그레이드 방법 (직접 해봤습니다)

    업그레이드하기로 결심했다면, 절차를 같이 보실게요. 제가 홈랩에서 직접 한 순서대로 정리했습니다.

    1. 현재 DSM 버전 확인: 제어판(Control Panel) → 정보 센터(Info Center) → DSM 버전 확인
    2. 설정 백업: 제어판 → 업데이트 및 복원 → 설정 백업 → 내보내기
    3. 패키지 목록 저장: 패키지 센터에서 설치된 패키지 목록 메모 또는 스크린샷
    4. 데이터 백업 확인: Hyper Backup 또는 외장 드라이브에 최신 백업 존재 여부 확인
    5. 업데이트 실행: 제어판 → 업데이트 및 복원 → DSM 업데이트 → 지금 업데이트
    6. 재부팅 대기: 업그레이드 후 자동 재부팅. 보통 10~15분 소요
    7. 패키지 재확인: 재부팅 후 모든 패키지 정상 동작 확인
    8. Docker 컨테이너 확인: Container Manager에서 모든 컨테이너 상태 점검
    # 업그레이드 후 SSH로 접속해서 버전 확인
cat /etc.defaults/VERSION

# 출력 예시
# majorversion="7"
# minorversion="3"
# productversion="7.3-69057"

# 시스템 로그 확인 (업그레이드 관련 오류 체크)
tail -f /var/log/messages | grep -i error

    드디어 7.3 버전 확인이 되면 기분이 묘하게 좋더라고요. 물론 그 다음에 패키지 하나하나 다시 확인하는 게 좀 번거롭긴 하지만요.

    자주 묻는 질문 (FAQ)

    Q. DSM 7.3으로 올렸다가 다시 7.2로 내릴 수 있나요?

    안타깝게도 DSM 다운그레이드는 공식적으로 지원되지 않습니다. 이게 업그레이드 전에 신중하게 고민해야 하는 이유예요. 강제로 다운그레이드하는 방법이 있긴 한데, 데이터 손실 위험이 있어서 권장하지 않습니다.

    Q. 자동 업데이트를 켜놔도 되나요?

    보안 패치(Security Update)의 자동 업데이트는 켜두는 걸 추천합니다. 근데 DSM 메이저/마이너 버전 업그레이드 자동화는 개인적으로 비추예요. 제가 앞서 말한 것처럼, 예기치 않은 시간에 업그레이드되면 대응하기 어렵거든요.

    Q. 7.2에서 7.3으로 올리면 데이터가 날아가나요?

    정상적인 업그레이드 절차를 따르면 데이터는 유지됩니다. DSM 업그레이드는 운영체제만 업데이트하고 볼륨(데이터 저장 공간)은 건드리지 않아요. 그래도 백업은 필수입니다. 혹시 모를 상황에 대비해서요.

    Q. DSM 7.3 설치 후 NAS가 느려졌다는 분들이 있던데요?

    초기 업그레이드 직후에는 인덱싱(Indexing, 파일 목록 재구성) 작업이 백그라운드에서 돌아서 일시적으로 느릴 수 있어요. 보통 수 시간~하루 정도 지나면 정상으로 돌아옵니다. 저도 처음엔 “뭔가 잘못됐나?” 싶었는데, 기다리니까 해결됐더라고요.

    마무리: 버전보다 중요한 건 내 환경 파악

    오늘 Synology DSM 7.2 vs 7.3 비교를 꽤 자세히 살펴봤는데요, 결국 핵심은 이거예요. “최신이 항상 최선은 아니다.” 내 NAS가 어떤 용도로 쓰이고 있는지, 어떤 패키지에 의존하고 있는지를 먼저 파악하는 게 버전 선택보다 더 중요합니다.

    13년 동안 인프라를 운영하면서 배운 게 있다면, 변경은 항상 되돌아올 길을 확보하고 해야 한다는 거예요. 백업, 설정 저장, 호환성 확인. 이 세 가지만 잘 지켜도 업그레이드 관련 사고는 거의 없습니다.

    혹시 아직 7.1 버전을 쓰고 계신 분들도 있으시다면, 7.2로의 업그레이드는 거의 필수라고 봅니다. 7.2에서 추가된 보안 기능들이 꽤 중요하거든요. 그 이야기는 다음 글에서 자세히 다뤄볼게요.

    Synology DSM 관련해서 궁금한 점이 있으시면 댓글로 남겨주세요. 제가 직접 테스트해보고 답변드릴 수 있는 건 최대한 해드리겠습니다. 🎉

    DSM 7.2 vs 7.3 홈 유저와 비즈니스 환경별 최종 비교 요약 인포그래픽

    ▲ DSM 7.2 vs 7.3 최종 비교 요약 인포그래픽. 홈 유저와 비즈니스 환경별로 어떤 버전이 적합한지 한눈에 확인하세요.

  • [NAS] SMB 다중 사용자 동시 접속 시 성능 저하 해결 방안

    [NAS] SMB 다중 사용자 동시 접속 시 성능 저하 해결 방안

    목차

    퇴근 시간에 NAS가 느려지는 이유 — SMB 다중 사용자 동시 접속 문제

    혹시 이런 경험 있으신가요? 혼자 쓸 때는 멀쩡하던 NAS가, 팀원 몇 명이 동시에 접속하는 순간부터 전송 속도가 뚝 떨어지는 상황 말이에요. 저도 처음 홈 오피스 겸 소규모 팀 환경에 NAS를 도입했을 때 딱 이 문제를 겪었거든요. 오전에는 100MB/s 넘게 잘 나오다가, 오후 2~3시에 팀원 4~5명이 동시에 파일 작업 시작하면 10MB/s도 안 나오는 상황이 반복됐어요. SMB NAS 성능 저하 문제, 생각보다 많은 분들이 겪고 계시더라고요.

    13년 동안 인프라 엔지니어로 일하면서 크고 작은 NAS 환경을 수십 곳 설계하고 운영해봤는데요, 결론부터 말씀드리면 이 문제는 하드웨어를 교체하지 않고도 SMB 설정 최적화만으로 상당 부분 해결돼요. 오늘은 그 삽질 과정을 솔직하게 공유해드릴게요.

    SMB 다중 사용자 동시 접속 시 NAS 성능 저하 발생 구간 아키텍처 개요도

    다중 사용자가 SMB 프로토콜로 NAS에 동시 접속할 때 발생하는 병목 지점 개요도. 네트워크 레이어, SMB 세션, 디스크 I/O 구간별 병목을 시각화한 다이어그램.

    SMB 성능 저하, 왜 일어나는 걸까요? — 원인부터 짚어보기

    SMB(Server Message Block)는 윈도우 파일 공유 프로토콜인데, 생각보다 꽤 복잡해요. 단순히 파일을 복사하는 것처럼 보여도, 실제로는 인증, 세션 관리, 파일 잠금(File Locking), 캐시 동기화까지 엄청난 양의 통신이 오가거든요.

    NAS 동시 접속 시 성능이 저하되는 주요 원인은 크게 다섯 가지예요.

    • Oplocks(Opportunistic Locks, 기회적 잠금) 경합: 여러 클라이언트가 같은 파일에 접근할 때 잠금 협상 과정에서 오버헤드 발생
    • SMB 서명(Signing) 오버헤드: 패킷마다 서명을 검증하는 과정이 CPU를 많이 잡아먹음
    • Max Connections 제한 및 세션 큐잉: 동시 세션 수가 제한에 걸리면 대기열이 생기면서 전체 속도가 떨어짐
    • SMB1 레거시 폴백: 오래된 클라이언트가 있으면 서버 전체가 SMB1 모드로 협상되는 경우
    • 네트워크 드라이브 속도에 영향을 주는 MTU(Maximum Transmission Unit) 설정 불일치

    저는 처음에 디스크 문제인 줄 알았어요. HDD를 SSD로 교체할 뻔 했는데, 막상 iostat으로 디스크 사용률을 확인해보니 30%도 안 됐거든요. 범인은 디스크가 아니라 SMB 설정이었어요. 🕵️

    진단 먼저 — 어디서 막히는지 확인하기

    무작정 설정을 바꾸기 전에 진단부터 해야 해요. 근거 없이 설정 건드리다가 더 망가지는 경우 정말 많거든요. 저는 주로 아래 명령어들로 현황을 파악합니다.

    현재 SMB 연결 상태 확인 (Linux/Samba 기준)

    # 현재 접속 중인 SMB 세션 확인
smbstatus

# 더 상세한 정보
smbstatus --verbose

# 현재 열린 파일 목록
smbstatus --shares

# 잠금(Lock) 상태 확인
smbstatus --locks

    네트워크 병목 확인

    # 네트워크 인터페이스 트래픽 실시간 모니터링
iftop -i eth0

# 또는 nethogs로 프로세스별 트래픽 확인
nethogs eth0

# ss 명령어로 SMB 관련 소켓 상태 확인 (445번 포트)
ss -tnp | grep 445

    Windows 클라이언트에서 SMB 버전 확인

    # 현재 사용 중인 SMB 버전 확인
Get-SmbConnection

# SMB 서버 설정 확인
Get-SmbServerConfiguration

# SMB 클라이언트 설정 확인
Get-SmbClientConfiguration

    💡 팁: Get-SmbConnection 결과에서 Dialect(다이얼렉트) 컬럼을 꼭 확인하세요. 여기서 SMB 1.0이 보이면 그게 주범일 가능성이 높아요.

    SMB 설정 최적화 — 핵심 설정 변경하기

    Samba smb.conf 성능 최적화 파라미터 구성 다이어그램

    Samba smb.conf 주요 성능 최적화 파라미터 구성도. global 섹션과 share 섹션별 설정 항목을 시각적으로 구분한 다이어그램.

    1단계: SMB 버전 강제 설정 (SMB2/3으로 고정)

    가장 먼저 할 일은 SMB1을 완전히 비활성화하는 거예요. SMB1은 2017년 WannaCry 사태 이후로 사실상 퇴역 수준인데, 여전히 폴백(Fallback)으로 동작하는 경우가 있거든요.

    Linux Samba 서버 기준 (/etc/samba/smb.conf)

    [global]
   # SMB 버전 설정 - SMB2 최소, SMB3 권장
   server min protocol = SMB2
   server max protocol = SMB3
   
   # 클라이언트 최소 버전도 제한
   client min protocol = SMB2
   client max protocol = SMB3

    Windows Server 기준 (PowerShell)

    # SMB1 완전 비활성화
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# SMB2/3 활성화 확인
Set-SmbServerConfiguration -EnableSMB2Protocol $true -Force

# 변경 사항 확인
Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

    2단계: Samba 성능 최적화 파라미터 적용

    이게 핵심이에요. 제가 실제로 적용해서 효과 본 설정들입니다. 하나씩 설명해드릴게요.

    [global]
   # === 프로토콜 버전 ===
   server min protocol = SMB2
   server max protocol = SMB3

   # === 성능 최적화 ===
   # 소켓 옵션 - TCP 성능 향상
   socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072

   # 읽기/쓰기 버퍼 크기 최적화 (단위: bytes)
   read raw = yes
   write raw = yes
   max xmit = 65535

   # 비동기 I/O 활성화
   aio read size = 16384
   aio write size = 16384

   # 동시 연결 수 제한 해제 (기본값이 너무 낮은 경우)
   max smbd processes = 0

   # === 보안 vs 성능 균형 ===
   # 내부 네트워크라면 서명 비활성화로 CPU 부하 절감
   # 주의: 외부 노출 환경에서는 절대 비활성화 금지!
   server signing = auto
   client signing = auto

   # === 캐시 설정 ===
   # Winbind 캐시 타임아웃
   winbind cache time = 300

   # getwd cache
   getwd cache = yes

   # === 로깅 최소화 (성능에 영향) ===
   log level = 1
   
[공유폴더명]
   path = /data/shared
   valid users = @sambausers
   read only = no
   
   # 공유 수준 캐시 설정
   oplocks = yes
   level2 oplocks = yes
   kernel oplocks = no
   
   # 스트릭트 동기화 비활성화 (성능 향상, 단 UPS 있는 환경 권장)
   strict sync = no
   sync always = no

    ⚠️ 주의: strict sync = no와 sync always = no는 전원이 갑자기 끊길 경우 데이터 손실 위험이 있어요. UPS(무정전 전원장치)가 있는 환경에서만 사용하세요.

    3단계: Windows 클라이언트 측 최적화

    서버만 바꾼다고 끝이 아니에요. 클라이언트 설정도 같이 봐야 해요. 특히 네트워크 드라이브 속도에 직결되는 설정들이 있거든요.

    # SMB Direct (RDMA) 활성화 여부 확인
Get-SmbClientConfiguration | Select EnableBandwidthThrottling, EnableLargeMtu, EnableMultiChannel

# Large MTU 활성화 (점보 프레임 지원 네트워크 환경)
Set-SmbClientConfiguration -EnableLargeMtu $true -Force

# 멀티채널(Multi-Channel) 활성화 - NIC가 여러 개일 때 대역폭 합산
Set-SmbClientConfiguration -EnableMultiChannel $true -Force

# 읽기 선행(Read-Ahead) 크기 조정
Set-SmbClientConfiguration -SessionTimeout 60 -Force

    4단계: Jumbo Frame (점보 프레임) 설정

    이건 스위치, NAS 서버, 클라이언트 PC 모두 지원해야 효과가 있어요. 한 곳이라도 지원 안 하면 오히려 역효과가 나요. 저도 이거 모르고 NAS만 점보 프레임 설정했다가 패킷 단편화(Fragmentation)로 더 느려진 경험이 있어요. 😅

    # Linux NAS 서버 - MTU 9000 설정
ip link set eth0 mtu 9000

# 영구 적용 (Ubuntu/Debian - netplan)
# /etc/netplan/01-netcfg.yaml 편집
    # /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      mtu: 9000
    # netplan 적용
netplan apply

# 확인
ip link show eth0 | grep mtu

    ⚠️ 삽질 모음 — 실제로 겪은 문제들

    설정을 바꾸면서 제가 직접 겪은 문제들이에요. 미리 알면 시간 많이 아낄 수 있습니다.

    문제 1: Oplocks 설정 후 오피스 파일이 열리지 않는 현상

    Oplocks를 활성화했더니 Excel, Word 파일이 열릴 때 “파일이 잠겨 있습니다” 오류가 뜨는 경우가 생겼어요. 알고 보니 특정 구버전 Office와의 호환성 문제더라고요.

    # 오피스 파일 공유에는 Oplocks 비활성화 고려
[office_docs]
   path = /data/office
   oplocks = no
   level2 oplocks = no

    문제 2: 서명(Signing) 비활성화 후 Windows 11 클라이언트 접속 거부

    Windows 11은 기본적으로 SMB 서명을 필수로 요구하도록 정책이 강화됐어요. 서버에서 서명을 꺼버리면 Windows 11 클라이언트가 아예 연결을 거부해요. 이럴 때는 auto로 설정하는 게 최선이에요.

    # 'disabled' 대신 'auto' 사용
server signing = auto
client signing = auto

    문제 3: max smbd processes 설정 후 메모리 폭발

    동시 접속이 많은 환경에서 max smbd processes = 0(무제한)으로 설정했더니, smbd 프로세스가 수백 개 생기면서 RAM이 꽉 차버렸어요. 적절한 상한선을 설정하는 게 맞습니다.

    # 동시 접속자 수 * 2 정도로 설정 (예: 20명이면 40)
max smbd processes = 40

    검증 — 설정 적용 후 성능 측정하기

    SMB NAS 성능 최적화 적용 전후 동시 접속 전송 속도 비교 벤치마크 결과

    SMB 설정 최적화 적용 전후 동시 접속 성능 비교 차트. 사용자 수 증가에 따른 전송 속도 변화를 비교한 벤치마크 결과.

    CrystalDiskMark로 클라이언트 측 성능 측정

    Windows 클라이언트에서 CrystalDiskMark로 네트워크 드라이브를 대상으로 벤치마크를 돌려보세요. 설정 전후를 비교해보면 효과가 확실히 보입니다.

    iperf3로 순수 네트워크 대역폭 확인

    # NAS 서버에서 iperf3 서버 실행
iperf3 -s

# 클라이언트에서 테스트 (여러 스트림으로 병렬 테스트)
iperf3 -c [NAS_IP] -P 4 -t 30

# 점보 프레임 환경이라면
iperf3 -c [NAS_IP] -P 4 -t 30 -M 8972

    Samba 로그로 성능 모니터링

    # Samba 로그 실시간 확인
tail -f /var/log/samba/log.smbd

# 프로파일링 활성화 (임시)
smbcontrol smbd profilelevel 2
smbcontrol smbd profile

# 확인 후 프로파일링 비활성화
smbcontrol smbd profilelevel 0

    제가 이 설정들을 적용하고 나서 실제로 측정한 결과, 5명 동시 접속 기준으로 평균 전송 속도가 22MB/s에서 87MB/s로 약 4배 향상됐어요. 🎉 물론 환경마다 다르겠지만, 체감 차이가 확실히 느껴졌습니다.

    SMB 버전별 성능 및 특징 비교

    구분 SMB 1.0 SMB 2.x SMB 3.x
    출시 시기 1980년대 Windows Vista/2008 Windows 8/2012
    다중 요청 처리 ❌ 순차 처리 ✅ 파이프라이닝 ✅ 멀티플렉싱
    멀티채널 ❌ 미지원 ❌ 미지원 ✅ 지원
    암호화 ❌ 없음 ⚠️ 서명만 ✅ 엔드투엔드 암호화
    동시 접속 성능 🔴 매우 낮음 🟡 보통 🟢 우수
    보안 🔴 취약 (WannaCry) 🟡 양호 🟢 강력
    권장 여부 ❌ 사용 금지 ⚠️ 최소 버전 ✅ 적극 권장

    자주 묻는 질문 (FAQ)

    Q. Synology/QNAP NAS에서도 같은 설정이 적용되나요?

    Synology는 DSM 내 제어판 > 파일 서비스 > SMB에서 최소/최대 SMB 버전을 GUI로 설정할 수 있어요. 고급 설정에서 추가 파라미터도 넣을 수 있고요. QNAP도 유사한 GUI를 제공하는데, 커스텀 smb.conf 직접 편집은 펌웨어 업데이트 시 초기화될 수 있으니 주의하세요.

    Q. SMB Multichannel(멀티채널)이 뭔가요?

    SMB 3.0에서 도입된 기능으로, NIC(Network Interface Card, 네트워크 카드)가 여러 개 있거나 NIC가 여러 포트를 가진 경우 대역폭을 합산해서 사용할 수 있어요. 예를 들어 1Gbps NIC 2개를 묶으면 이론상 2Gbps까지 나옵니다.

    Q. 설정 변경 후 Samba 재시작은 어떻게 하나요?

    # Samba 서비스 재시작
systemctl restart smbd nmbd

# 설정 문법 오류 확인 (재시작 전에 꼭!)
testparm

    Q. Windows Server에서 SMB NAS 성능 저하가 심할 때는?

    Windows Server 환경에서는 SMB 대역폭 조절(Throttling) 기능이 활성화되어 있을 수 있어요. 아래 명령어로 확인하고 필요시 조정하세요.

    # 대역폭 조절 확인
Get-SmbClientConfiguration | Select EnableBandwidthThrottling

# 비활성화
Set-SmbClientConfiguration -EnableBandwidthThrottling $false -Force

    마무리 — 정리하며

    SMB NAS 성능 최적화 핵심 설정 체크리스트 요약 인포그래픽

    SMB NAS 성능 최적화 핵심 체크리스트 요약 인포그래픽. 프로토콜 버전, 서명, 멀티채널, 점보프레임 등 단계별 적용 항목 정리.

    오늘 다룬 내용을 간단히 정리해볼게요.

    1. ✅ 진단 먼저: smbstatus, iperf3, Get-SmbConnection으로 현황 파악
    2. ✅ SMB1 비활성화: 보안과 성능 모두를 위해 즉시 적용
    3. ✅ 버퍼/소켓 최적화: smb.conf의 socket options, aio 설정
    4. ✅ 서명 설정: 내부망은 auto, 외부 노출 환경은 required
    5. ✅ 점보 프레임: 스위치, 서버, 클라이언트 모두 지원 시에만 적용
    6. ✅ SMB Multichannel: NIC 여러 개 환경에서 대역폭 극대화

    SMB NAS 성능 저하 문제는 하드웨어 업그레이드보다 설정 최적화가 먼저예요. 저도 처음엔 장비 탓만 했는데, 결국 설정 몇 줄 바꿔서 해결했거든요. 여러분도 오늘 소개한 방법들 적용해보시고, 효과 있으셨으면 댓글로 알려주세요!

    다음 글에서는 NFS vs SMB 성능 비교와 리눅스 클라이언트 환경에서의 마운트 최적화를 다룰 예정입니다. SMB 외에 NFS도 궁금하신 분들은 기대해주세요. 😊

    혹시 설정 적용하다가 막히는 부분 있으시면 댓글로 남겨주세요. 제가 아는 범위 내에서 최대한 도와드리겠습니다!