Synology NAS 초기설정: RAID보다 복구계획부터 설계

Synology NAS를 처음 설치하면 가장 먼저 RAID를 무엇으로 할지 고민하기 쉽다.

SHR인지 RAID 1인지, 볼륨을 하나로 만들지 여러 개로 나눌지, NVMe를 어디에 쓸지 같은 질문이 바로 나온다.

하지만 실제 운영에서 더 중요한 질문은 따로 있다.

이 NAS가 고장났을 때 무엇을 얼마 만에 복구해야 하는가?

이 질문에 답한 뒤 Storage Pool과 Volume을 설계하면 초기설정의 방향이 훨씬 명확해진다.

NAS 설계는 용량이 아니라 데이터 역할부터 나눈다

예를 들어 한 NAS 안에 다음 데이터가 있다고 하자.

가족 사진과 문서
대용량 영상
Docker database
WordPress uploads
VM disk
백업파일
임시 render·cache

모두 파일이지만 손실됐을 때의 영향과 성능 요구는 전혀 다르다.

가족사진은 속도보다 장기보존이 중요할 수 있고, database는 작은 random I/O와 일관성 있는 backup이 중요하다. Render cache는 빠르면 좋지만 사라져도 다시 만들 수 있다.

그래서 초기설정 전에 데이터를 최소한 다음처럼 분류하는 것이 좋다.

분류	예	우선순위
Critical persistent	사진·문서·DB	무결성·백업·복구
Active workload	DB·VM·Docker	Latency·복구속도
Bulk data	대용량 media	용량·순차성능
Rebuildable	Cache·temporary render	성능, 백업 우선순위 낮음

RAID는 Backup이 아니다

RAID 또는 SHR의 목적은 주로 drive 장애가 발생했을 때 storage를 계속 사용할 수 있도록 redundancy를 제공하는 것이다.

하지만 다음 사고는 RAID가 막지 못한다.

사용자가 파일을 삭제했다.
랜섬웨어가 공유폴더를 암호화했다.
애플리케이션이 DB를 손상시켰다.
관리자가 잘못된 명령으로 데이터를 삭제했다.
NAS 전체가 도난·화재·전기적 사고를 겪었다.

디스크 두 개에 똑같이 잘못된 데이터가 기록되면 RAID는 그 잘못을 매우 안정적으로 두 장에 저장한다.

그래서 Storage Pool 설계와 Backup 설계는 처음부터 별도의 문제로 봐야 한다.

Storage Pool은 장애허용과 확장전략을 결정한다

DSM Storage Manager에서는 먼저 drive를 묶어 Storage Pool을 만들고 그 위에 Volume을 만든다.

Storage Pool 단계에서 RAID 유형과 사용할 drive를 결정하므로 이 선택은 단순한 공간설정이 아니다.

예를 들어 2-bay NAS에서 한 drive 장애를 견디는 구성을 사용하면 usable capacity는 단일 drive 하나 수준이 된다.

그 대가로 한 drive가 실패해도 즉시 전체 data volume을 잃지 않을 수 있다.

여기서 중요한 것은 “용량 손해”라고만 보지 않는 것이다.

Redundancy를 위해 포기하는 용량은 장애 중에도 서비스를 유지할 가능성을 사는 비용이다.

SHR와 전통 RAID는 현재와 미래의 Drive 구성까지 본다

SHR를 사용할 수 있는 Synology 모델에서는 서로 다른 크기의 drive를 활용하면서 확장하기 편한 구조를 제공할 수 있다.

전통적인 RAID 유형은 구조가 명확하고 다른 storage 시스템 경험과 연결하기 쉽다.

어느 쪽이 더 좋다는 일반적인 답보다:

현재 drive 개수
한 번에 허용할 drive failure
앞으로 drive를 어떻게 교체·확장할지
해당 모델의 지원 RAID 유형

을 기준으로 선택해야 한다.

그리고 RAID level을 결정하기 전에 사용할 drive가 해당 NAS 모델과 운영정책에 적합한지도 확인하는 편이 안전하다.

Volume은 나중에 줄이기 어렵다는 점을 처음부터 알아둔다

Synology DSM의 현재 Storage Manager 구조에서는 하나의 Storage Pool에 하나 또는 여러 Volume을 만들 수 있다.

하지만 생성된 Volume은 확장할 수 있어도 일반적으로 크기를 다시 줄이는 방식은 지원되지 않는다.

처음부터 필요 이상으로 여러 Volume을 잘게 나누는 것도 불편하고, 미래 역할을 전혀 생각하지 않고 모든 공간을 한 번에 소비하는 것도 유연성을 줄일 수 있다.

Volume을 분리할 이유가 있을 때는 보통:

Workload isolation
Filesystem·encryption 정책 차이
서비스 또는 운영 lifecycle 차이
용량관리 책임을 명확히 나눌 필요

가 있는지 먼저 본다.

일반적인 데이터 Volume에서는 Btrfs를 먼저 검토할 이유가 크다

Synology는 현재 지원 모델의 일반적인 용도에서 Btrfs를 권장하고 있다.

그 이유는 단순한 filesystem 이름이 아니라:

Shared Folder Snapshot
Replication
Point-in-time recovery
Data integrity 관련 기능
Shared Folder quota

등 DSM의 데이터 보호 기능과 연결되기 때문이다.

단, 모델과 DSM version에 따라 지원기능이 다를 수 있으므로 실제 장비의 공식 사양을 기준으로 확인해야 한다.

Shared Folder는 사용자가 보기 좋은 폴더가 아니라 정책경계다

NAS 초기설정에서 Shared Folder를 “사진, 문서, 기타” 정도로만 나누기 쉽다.

하지만 Shared Folder는 다음 정책을 나누는 중요한 단위가 될 수 있다.

권한
Snapshot
Quota
Backup
Encryption
Replication

예를 들어 database data와 대용량 media를 같은 Shared Folder에 넣으면 backup frequency와 retention을 각각 최적화하기 어려워질 수 있다.

반대로 사용자가 파일을 찾기 불편할 정도로 지나치게 세분화하면 운영복잡성이 높아진다.

좋은 경계는 같은 보존·권한·복구정책을 공유하는 데이터끼리 묶는 것이다.

Snapshot은 빠른 복구를 위한 첫 번째 층으로 사용할 수 있다

Btrfs와 지원되는 환경에서는 Snapshot Replication을 이용해 Shared Folder의 point-in-time snapshot을 만들 수 있다.

실수로 파일을 삭제하거나 application이 데이터를 잘못 수정했을 때 수 TB의 전체 backup을 복원하는 대신 이전 시점으로 빠르게 돌아갈 수 있다.

하지만 Snapshot도 같은 storage system에만 존재하면 NAS 전체 장애에는 취약하다.

즉:

Snapshot = 빠른 local recovery

Backup = 별도 failure domain을 포함한 data protection

으로 역할을 나누는 편이 좋다.

Backup은 DSM 설치가 끝난 뒤 나중에 생각하는 기능이 아니다

Synology 역시 NAS 데이터 보호를 위해 3-2-1 backup 전략을 권장한다.

즉:

데이터 사본 3개
서로 다른 2개 매체 또는 storage 영역
그중 1개는 off-site

라는 구조다.

중요한 데이터가 NAS에 처음 들어간 날부터 backup이 존재해야 한다.

“데이터가 많이 쌓이면 나중에 backup하자”는 방식은 바로 그 기간 동안 single point of failure를 허용하는 것이다.

Backup 성공보다 Restore 시간을 먼저 계산한다

5TB를 cloud에 백업하는 데 성공했다고 하자.

하지만 장애 후 실제 download와 restore에 4일이 필요하고 해당 서비스는 하루만 중단되어도 문제가 된다면 backup은 존재하지만 Recovery Objective를 만족하지 못한다.

따라서 데이터별로:

RPO — 최대 얼마의 최신 데이터를 잃어도 되는가?
RTO — 몇 시간 안에 다시 사용할 수 있어야 하는가?

를 정한다.

RPO 1시간이 필요한 DB와 일주일에 한 번이면 충분한 archive를 같은 backup schedule로 처리할 이유는 없다.

NVMe는 가장 큰 파일보다 가장 민감한 Workload에 먼저 쓴다

NVMe가 있다고 모든 data를 NVMe로 옮길 필요는 없다.

대용량 영상파일은 HDD에서도 순차접근으로 충분한 경우가 많다.

반대로:

Database
Docker active data
VM disk
작은 파일이 많은 application
build·temporary working set

은 storage latency에 더 민감하다.

지원 모델과 공식 구성을 전제로 NVMe storage pool을 사용할 수 있다면 이러한 active workload를 우선 검토하는 편이 자원효율이 높다.

서비스를 설치하기 전에 Data Path를 문서화한다

WordPress를 설치한다고 하자.

운영자는 최소한 다음을 알고 있어야 한다.

데이터	실제 보존위치
WordPress code/image	재생성 가능한 runtime인지
Uploads	어느 persistent path인지
Database	어느 volume/path인지
Secrets	어디에 별도 보관되는지
Backup	어느 NAS/cloud/off-site에 있는지

이 표를 만들 수 없다면 NAS에서 application은 동작하고 있지만 아직 복구 가능한 production system이라고 말하기 어렵다.

초기 구축이 끝났다는 기준은 로그인 성공이 아니다

다음 단계까지 확인해야 commissioning이 끝났다고 보는 편이 좋다.

Storage Pool과 Volume이 Healthy인가
사용할 filesystem과 Shared Folder 정책이 의도대로인가
관리자 권한과 일반 사용자 권한이 분리됐는가
중요 데이터의 Snapshot 또는 local recovery가 준비됐는가
Off-site를 포함한 Backup이 실제 성공했는가
Backup에서 테스트 파일 또는 application을 실제 복원해봤는가
NAS 재부팅 후 핵심 서비스가 정상 시작되는가
장애 시 무엇부터 복구할지 순서가 정해져 있는가

결론

Synology NAS 초기설정은 DSM을 설치하고 Shared Folder를 만드는 작업이 아니다.

좋은 구축 순서는:

데이터 중요도 → RPO/RTO → RAID/SHR → Storage Pool → Volume/Filesystem → Shared Folder → Snapshot → Backup → Restore Test → Application

에 가깝다.

이 순서로 구성하면 RAID 종류나 NVMe 사용법도 목적 없이 선택하지 않게 된다.

NAS의 완성도는 디스크가 모두 정상이라고 표시되는 순간이 아니라 오늘 장비가 고장나도 어떤 데이터부터 어떤 방법으로 복구할지 설명할 수 있을 때 결정된다.