아직 저장소를 만들지 않은 신규 구성
현재 필요한 데이터량, 예상 증가량과 업무 조건을 기준으로 디스크 수와 RAID 방식을 선택합니다. 초기 배치뿐 아니라 다음 확장에 필요한 디스크와 여유 베이도 함께 계획합니다.
사용할 디스크에 기존 자료가 있다면 새 저장소에 편입하기 전에 별도 위치에 보존합니다.
STORAGE GUIDE
새 RAID를 구성하거나 기존 데이터를 유지하면서 저장 구성을 바꾸려 하시나요?
필요한 용량과 디스크 장애 허용 범위를 비교하고, 현재 NAS와 운영체제에서 지원하는 구성과 변경 경로를 확인합니다. 정상 저장소의 계획 변경과 장애 상태의 대응을 구분하며, 백업과 복원 가능성, 작업 중 서비스 영향과 완료 후 검증까지 함께 살펴봅니다.
01 / STARTING POINT
RAID를 아직 만들지 않은 경우와 기존 데이터를 유지하며 변경하는 경우는 출발점이 다릅니다. 경고나 접근 이상이 있다면 계획했던 용량 확장보다 현재 상태와 데이터 보존을 먼저 판단합니다.
현재 필요한 데이터량, 예상 증가량과 업무 조건을 기준으로 디스크 수와 RAID 방식을 선택합니다. 초기 배치뿐 아니라 다음 확장에 필요한 디스크와 여유 베이도 함께 계획합니다.
사용할 디스크에 기존 자료가 있다면 새 저장소에 편입하기 전에 별도 위치에 보존합니다.
현재 RAID, 사용 중인 디스크와 빈 베이를 확인한 뒤 목표 구성으로 바꿀 수 있는 공식 경로를 찾습니다. 정상 상태는 변경을 검토할 출발 조건이지, 모든 변경이 가능하다는 뜻은 아닙니다. DSM도 RAID 변경 전에 저장소의 정상 상태와 변경별 요구 조건을 확인하도록 안내합니다.
디스크 경고, 읽기 전용 전환, 저장소 비활성화와 파일 접근 이상을 같은 문제로 취급하지 않습니다. 추가 디스크를 구입하거나 교체하기 전에 현재 상태와 기존 디스크의 분리 및 변경 이력을 확인합니다.
특히 QNAP의 Degraded, Degraded-Readonly, Not Active는 작업 방향이 달라질 수 있는 상태입니다. 작업 준비와 상태별 진행 판단에서 구분해 확인합니다.
02 / RAID SELECTION AND LAYOUT
RAID 방식의 구조와 장애 대응을 이해한 뒤, 계산상 용량과 효율, 작업 특성, 베이 수와 다음 확장 조건을 순서대로 비교합니다.
02A / BASICS
저장 방식에 따라 디스크를 사용하는 방법과 장애 대응 범위가 달라집니다. 아래 내용은 기본적인 구조 비교이며, 실제 지원 방식과 최대 디스크 수는 NAS 모델과 운영체제에 따라 달라질 수 있습니다.
| 방식 | 최소 디스크 | 데이터 배치 | 장애 대응 |
|---|---|---|---|
Basic / Single | 1개 | 한 디스크에 저장 | 중복 보호 없음 |
구조와 지원 범위한 디스크를 독립된 저장공간으로 사용합니다. DSM의 Basic과 QTS의 Single이 해당하며 최소 한 개로 구성합니다. 이름이 비슷하더라도 풀과 볼륨의 생성 조건은 해당 모델과 OS를 따릅니다. 용량 특성미러나 패리티 공간을 사용하지 않습니다. 디스크 한 개의 용량을 바탕으로 저장공간을 만들지만, 시스템과 파일시스템이 사용하는 공간은 별도로 제외됩니다. 장애와 제한디스크가 고장 나면 다른 참여 디스크에서 데이터를 재구축할 수 없습니다. 디스크를 새것으로 바꾸는 것만으로 기존 데이터가 돌아오지 않으므로 별도 사본과 복원 방법이 필요합니다. 검토 대상과 비교단일 베이 장비나 데이터를 다시 복사할 수 있는 별도 저장소를 검토할 때 비교합니다. 여러 Basic 또는 Single 저장소를 독립 운영하는 것과 여러 디스크를 한 공간으로 연결하는 JBOD는 장애 영향 범위와 관리 단위가 다릅니다. | |||
JBOD | 구현별 차이 | 여러 디스크를 하나의 저장공간으로 연결 | 중복 보호 없음 |
구조와 지원 범위이 표의 JBOD는 여러 디스크를 하나의 논리 공간으로 이어 쓰는 구성입니다. QTS 5.2.x는 최소 두 개를 안내합니다. DSM은 한 개로 시작하는 구성도 있지만 RAID Group 지원 모델은 최소 두 개가 필요하므로 모델별 조건을 확인합니다. 용량 특성각 디스크의 공간을 이어 활용하며 중복 보호용 용량은 따로 두지 않습니다. QTS의 선형 JBOD는 한 디스크를 채운 뒤 다음 디스크에 기록합니다. RAID 0처럼 스트라이핑으로 병렬 처리하는 구조와 다릅니다. 장애와 제한한 디스크의 장애가 결합된 저장공간 전체의 접근 불가로 이어질 수 있습니다. 파일이 정상 디스크에 남아 있을 것으로 추정해도 파일시스템과 메타데이터의 상태가 달라질 수 있어 나머지 파일의 정상 접근을 보장하지 않습니다. 검토 대상과 비교서로 다른 용량을 한 공간으로 묶어야 하고, 장애 시 별도 사본으로 복원할 수 있는 경우에 검토합니다. 독립 저장소인 Basic 또는 Single과 구분하며, 장비 문서에서 JBOD가 단순 디스크 개별 노출을 뜻하는 경우에도 이 표의 결합 방식과 구분합니다. | |||
RAID 0 | 2개 이상 | 여러 디스크에 데이터 분산 | 없음 |
구조와 지원 범위최소 두 디스크에 데이터를 블록 단위로 나누어 기록하는 스트라이핑입니다. 같은 데이터의 사본이나 패리티는 만들지 않습니다. 지원 가능한 최대 디스크 수와 혼합 용량 처리 방식은 NAS와 OS별로 확인합니다. 용량 특성미러와 패리티를 위한 공간 차감이 없습니다. 다만 서로 다른 용량을 사용했을 때 모든 공간이 활용되는지는 구현에 따라 다릅니다. 동일 용량을 전제로 한 수치는 02B 용량 비교에서 확인합니다. 장애와 제한한 디스크를 잃으면 여러 디스크에 나뉜 데이터의 일부가 없어져 전체 RAID를 사용할 수 없게 됩니다. 교체 디스크에 누락 데이터를 재구축할 중복 정보가 없으므로 별도 사본에서 복원하거나 데이터를 다시 생성해야 합니다. 검토 대상과 비교원본이 별도로 있고 다시 만들 수 있는 임시 작업 데이터에서 처리량과 용량을 우선할 때 검토합니다. 실제 속도는 디스크뿐 아니라 NAS와 네트워크에도 제한됩니다. RAID 1은 미러 사본을 확보하는 방식이므로 RAID 0과 보호 목적이 다릅니다. | |||
RAID 1 | 2개 이상 다중 미러는 지원 조건 확인 | 참여 디스크에 같은 데이터 미러링 | 2개 미러: 1개 다중 미러: 지원 구성에 따름 |
구조와 지원 범위동일한 데이터를 참여 디스크에 기록하는 미러입니다. 대표적인 구성은 두 개이며, QTS 5.2.x는 두 디스크 RAID 1을 안내합니다. DSM 등에서 다중 미러를 지원하는 경우에는 모델과 OS가 허용하는 디스크 수를 확인합니다. 용량 특성같은 데이터를 여러 번 저장하므로 디스크를 더 넣어도 파일 저장공간이 그대로 합산되지 않습니다. 일반적인 구성에서는 가장 작은 참여 디스크 한 개분이 기준이며, 02B 용량 비교는 두 디스크 미러를 전제로 합니다. 장애와 제한두 디스크 미러는 한 개 장애 후 남은 디스크로 데이터를 제공합니다. 다중 미러도 완전하고 읽을 수 있는 사본이 남아 있어야 합니다. 장애 디스크를 교체한 뒤 동기화가 완료되기 전까지는 정상 상태의 보호 범위로 돌아온 것이 아닙니다. 검토 대상과 비교두 베이에서 디스크 한 개 장애에 대비하거나, 단순한 미러 구조가 필요한 저장소에서 검토합니다. 삭제와 잘못된 변경도 미러에 반영되므로 별도 백업과 다릅니다. RAID 10은 여러 미러 쌍 사이에 데이터를 분산하며, 하나의 다중 미러 RAID 1과 구분합니다. | |||
RAID 5 | 3개 이상 | 데이터와 패리티 분산 | 1개 |
구조와 지원 범위최소 세 디스크에 데이터와 복구 정보인 패리티를 분산합니다. 패리티 전용 디스크 한 개를 따로 지정하는 구조가 아닙니다. NAS의 지원 RAID와 그룹당 최대 디스크 수를 함께 확인합니다. 용량 특성같은 용량 기준으로 한 디스크분에 해당하는 공간을 패리티에 사용합니다. 서로 다른 용량을 섞는 일반적인 구성은 가장 작은 디스크를 기준으로 봅니다. 구체적인 계산은 02B 용량 비교에서 확인합니다. 장애와 제한한 디스크 장애 후에는 남은 데이터와 패리티를 이용합니다. 재구축 완료 전 추가 디스크 장애를 허용하지 않으며, 남은 디스크의 읽기 오류도 복구에 영향을 줄 수 있습니다. 장애 상태의 읽기 처리와 재구축은 정상 운영 때와 부하가 다릅니다. 검토 대상과 비교파일 공유와 보관에서 용량 활용과 한 디스크 장애 대응을 함께 검토할 때 비교합니다. 작은 쓰기에서는 패리티 갱신 부하를 고려합니다. 두 디스크 장애 대응이 필요하면 RAID 6를, 응답시간과 작은 임의 쓰기가 중요하면 RAID 10을 함께 비교합니다. | |||
RAID 6 | 4개 이상 | 데이터와 이중 패리티 분산 | 2개 |
구조와 지원 범위최소 네 디스크에 데이터와 두 종류의 독립적인 패리티를 분산합니다. 두 패리티가 두 개의 고정된 전용 디스크에만 기록되는 방식은 아닙니다. 신규 구성과 기존 RAID에서의 변경 지원은 별도로 확인합니다. 용량 특성같은 용량 기준으로 두 디스크분에 해당하는 공간을 패리티에 사용합니다. 같은 디스크 수의 RAID 5보다 파일 저장공간이 작아집니다. 계산식과 수치는 02B 용량 비교에서 확인합니다. 장애와 제한정상 상태에서 두 디스크 장애에 대응합니다. 한 개 장애 후에는 추가 한 개까지 대응할 수 있지만, 두 개가 빠진 상태에서는 추가 디스크 장애를 허용하지 않습니다. 재구축 시간과 업무 성능, 읽기 오류에 따른 영향은 별도로 확인해야 합니다. 검토 대상과 비교용량 일부를 보호 정보에 배정하더라도 두 디스크 장애에 대비해야 하는 업무 저장소에서 검토합니다. RAID 5보다 장애 허용 범위가 크지만 서비스 무중단을 보장하지는 않습니다. 작은 쓰기 부하가 큰 환경에서는 패리티 갱신이 없는 RAID 10과 실제 작업 성능을 비교합니다. | |||
| 방식 | 최소 디스크 | 데이터 배치 | 장애 대응 |
|---|---|---|---|
RAID 0+1 (RAID 01) | 4개 이상 짝수 | RAID 0 그룹을 미러링 | 디스크 1개 추가 장애는 위치에 따라 달라짐 |
구조와 지원 범위RAID 0 스트라이프 그룹을 먼저 만들고 그룹 전체를 미러링합니다. 두 그룹을 대칭으로 구성하는 일반적인 방식은 최소 네 개의 짝수 디스크를 사용합니다. RAID 10 지원만으로 RAID 0+1도 지원한다고 판단하지 않고 컨트롤러와 NAS의 실제 지원 목록을 확인합니다. 용량 특성같은 크기의 두 스트라이프 그룹 중 한쪽은 미러 사본에 해당하므로 파일 저장공간은 전체의 절반입니다. 용량이 RAID 10과 같아 보여도 디스크를 묶는 순서와 장애 영향 범위는 다릅니다. 장애와 제한한 디스크 장애로 한쪽 스트라이프 그룹이 실패하면 남은 그룹에 의존합니다. 이때 남은 그룹에서 디스크가 추가로 고장 나면 전체 구성을 잃을 수 있습니다. 추가 장애가 이미 실패한 그룹에 있는지 정상 그룹에 있는지가 중요하며, 임의의 두 개 장애를 허용하지 않습니다. 검토 대상과 비교기존 장비가 RAID 01로 운영 중이거나 해당 구조를 명시적으로 제공하는 경우에 구성과 장애 위치를 해석할 때 검토합니다. 신규 선택에서는 미러 쌍별로 보호하는 RAID 1+0과 비교하고, 비슷한 이름만으로 교체 및 재구축 절차를 동일하게 적용하지 않습니다. | |||
RAID 1+0 (RAID 10) | 4개 이상 짝수 | 미러 쌍을 만든 뒤 쌍 사이에 데이터 분산 | 각 미러 쌍에서 1개 |
구조와 지원 범위디스크 두 개씩 미러 쌍을 만든 뒤 쌍 사이에 데이터를 스트라이핑합니다. 이 표는 최소 네 개 이상의 짝수 디스크를 사용하는 일반적인 미러 쌍 구성을 기준으로 합니다. 다른 소프트웨어 구현의 RAID 10 배치를 NAS에 그대로 적용하지 않습니다. 용량 특성같은 용량의 디스크를 쌍으로 구성하면 전체의 절반을 파일 저장공간으로 사용합니다. 패리티 계산은 없지만 데이터는 각 쌍의 두 디스크에 모두 기록됩니다. 계산은 02B 용량 비교에서 확인합니다. 장애와 제한각 미러 쌍에 읽을 수 있는 사본이 남아 있어야 합니다. 서로 다른 쌍에서 한 개씩 고장 나는 경우와 같은 쌍의 두 개가 모두 고장 나는 경우는 결과가 다릅니다. 재구축 중인 쌍은 남은 디스크에 의존하므로 임의의 두 디스크 장애를 항상 허용한다고 설명하지 않습니다. 검토 대상과 비교가상화나 데이터베이스처럼 작은 임의 읽기와 쓰기, 응답시간이 중요한 환경에서 RAID 5 및 RAID 6와 비교합니다. 실제 성능은 디스크와 NAS, 캐시 및 작업 부하에 따라 확인합니다. RAID 0+1과 구조를 구분하고, 신규 구성 가능 여부와 기존 RAID 변경 및 디스크 추가 확장 지원은 따로 확인합니다. | |||
RAID 5+0 (RAID 50) | 6개 이상 | 여러 RAID 5 하위 그룹 사이에 데이터 분산 | 각 하위 그룹에서 1개 |
구조와 지원 범위최소 세 디스크로 만든 RAID 5 하위 그룹을 두 개 이상 만들고 그 위에 스트라이핑합니다. 최소 구성은 여섯 개이며, 실제 하위 그룹 수와 그룹별 디스크 수는 NAS와 OS가 허용하는 배치를 따릅니다. 용량 특성각 하위 그룹에서 한 디스크분의 공간을 패리티에 사용합니다. 전체에서 한 개분만 빼는 단일 RAID 5와 다르며, 같은 총 디스크 수라도 그룹을 나누는 방법에 따라 파일 저장공간이 달라집니다. 장애와 제한각 하위 그룹에서 한 개 장애에 대응합니다. 두 개가 서로 다른 그룹에서 고장 나면 각 그룹의 보호 범위 안이지만, 같은 그룹에서 두 개가 고장 나면 상위 RAID 50 전체가 실패할 수 있습니다. 그룹 수를 전체 RAID의 무조건적인 장애 허용 수로 읽으면 안 됩니다. 검토 대상과 비교여러 베이를 사용하는 업무 데이터와 백업 저장소에서 하위 그룹별 구성과 재구축 부하를 함께 검토할 때 비교합니다. 독립 RAID 5 그룹을 각각 운영하는 것과 달리 상위 스트라이핑으로 연결됩니다. 각 그룹에서 두 디스크 장애 대응이 필요하면 RAID 60과 비교합니다. | |||
RAID 6+0 (RAID 60) | 8개 이상 | 여러 RAID 6 하위 그룹 사이에 데이터 분산 | 각 하위 그룹에서 2개 |
구조와 지원 범위최소 네 디스크로 만든 RAID 6 하위 그룹을 두 개 이상 만들고 그 위에 스트라이핑합니다. 최소 구성은 여덟 개이며, 그룹 수와 그룹별 디스크 수 및 확장 방식은 해당 NAS와 OS의 지원 범위를 따릅니다. 용량 특성각 하위 그룹에서 두 디스크분을 패리티에 사용합니다. 전체에서 두 개분만 제외하는 단일 RAID 6와 다르며, 같은 그룹 배치의 RAID 50보다 파일 저장공간이 작아집니다. 장애와 제한각 하위 그룹에서 두 개 장애에 대응합니다. 두 그룹에 두 개씩 장애가 난 상황과 한 그룹에 세 개가 집중된 상황은 다릅니다. 어느 한 그룹이라도 보호 범위를 넘어서 실패하면 상위 RAID 60 전체를 잃을 수 있습니다. 검토 대상과 비교다수의 디스크를 사용하는 업무 저장소에서 그룹별 두 디스크 장애 대응이 필요한 경우 검토합니다. 독립 RAID 6 여러 개와 동일한 구성으로 취급하지 않습니다. RAID 50과 비교할 때 보호 범위뿐 아니라 그룹별 패리티 공간과 재구축 중 운영 부하도 함께 봅니다. | |||
| 방식 | 최소 디스크 | 데이터 배치 | 장애 대응 |
|---|---|---|---|
SHR-1 | 1개 | 디스크 조합에 맞춰 유연하게 관리 | 1디스크: 보호 없음 2디스크 이상: 1개 |
구조와 지원 범위Synology가 디스크의 용량 조합에 맞춰 내부 RAID 영역을 관리하는 방식입니다. 지원 모델에서 한 개로 시작할 수 있으나, 한 디스크 장애 대응에는 최소 두 개가 필요합니다. 단일 디스크 SHR에도 보호 기능이 있다고 해석하지 않습니다. 용량 특성서로 다른 용량을 내부 영역으로 나누어 중복 보호가 가능한 조합을 구성합니다. 큰 디스크의 남는 공간을 항상 전부 사용할 수 있는 것은 아니며 디스크 조합에 따라 미사용 공간이 생깁니다. 한 개 구성에 두 번째 디스크를 추가하는 경우 보호가 생겨도 용량은 늘지 않을 수 있습니다. 장애와 제한중복 보호가 갖춰진 SHR-1은 한 디스크 장애에 대응합니다. 장애 후 복구가 끝나기 전에는 추가 디스크 장애를 허용하지 않습니다. 혼합 용량 활용과 임의의 디스크 추가 허용은 다른 의미이므로 편입 및 교체 조건을 확인합니다. 검토 대상과 비교Synology 지원 장비에서 혼합 용량을 활용하거나 단계적인 교체와 확장을 계획할 때 검토합니다. 일반 RAID 1 또는 RAID 5와 비슷한 보호 수준인 경우에도 용량 활용과 확장 조건은 같지 않습니다. 두 디스크 장애 대응이 필요하면 SHR-2를 비교합니다. | |||
SHR-2 | 4개 | 두 디스크 장애 대응을 위한 SHR 구성 | 2개 |
구조와 지원 범위두 디스크 장애 대응이 가능하도록 Synology가 내부 RAID 영역을 관리하는 SHR 구성입니다. 신규 구성에는 최소 네 개가 필요하며 지원 모델과 디스크 조합을 확인합니다. SHR-1에서 변경할 때 필요한 추가 디스크 조건은 신규 구성의 최소 개수와 다릅니다. 용량 특성혼합 용량에서 두 디스크 중복 보호를 만들 수 있는 영역만 활용합니다. 큰 디스크가 있다고 남는 공간을 모두 쓸 수 있는 것은 아닙니다. SHR-1과 같은 디스크 조합을 사용하더라도 두 디스크 보호를 위한 공간이 추가로 필요합니다. 장애와 제한정상 상태에서 두 디스크 장애에 대응하지만 두 개가 빠진 상태에서는 추가 디스크 장애를 허용하지 않습니다. 디스크 교체 후 복구 완료 상태와 남은 디스크의 건강 상태를 함께 확인하며, SHR이라는 이름만으로 재구축 성공을 보장하지 않습니다. 검토 대상과 비교Synology 지원 장비에서 혼합 용량 활용과 두 디스크 장애 대응을 함께 고려할 때 검토합니다. SHR-1보다 보호 범위를 늘리는 대신 용량과 필요한 디스크 구성을 다시 확인해야 합니다. 일반 RAID 6와 보호 수준은 비교할 수 있지만 혼합 용량 활용과 확장 조건을 동일하게 적용하지 않습니다. | |||
RAID F1 | 3개 이상 | RAID 5 기반, 특정 SSD에 패리티 쓰기를 더 배분 | 1개 |
구조와 지원 범위RAID 5 기반으로 데이터를 분산하되 특정 SSD에 패리티 쓰기를 더 배분하는 Synology 방식입니다. 최소 세 개가 필요하며 RAID F1을 지원하는 모델과 SSD 구성 조건을 확인합니다. 용량 특성기본 용량 특성은 RAID 5처럼 한 디스크분의 패리티 공간을 사용하는 구조입니다. 패리티 쓰기를 불균등하게 배분하는 목적은 SSD 마모 시점을 벌리는 것이며, 두 디스크 장애 대응용 패리티를 추가하는 RAID 6와 다릅니다. 장애와 제한디스크 한 개 장애에 대응합니다. SSD들이 비슷한 시점에 함께 마모되는 위험을 줄이도록 설계되었지만, 동시 장애가 없어지거나 모든 SSD의 수명이 늘어난다는 보장은 아닙니다. SSD 수명 지표, 오류와 교체 후 재구축 상태를 계속 확인해야 합니다. 검토 대상과 비교지원되는 올플래시 저장소에서 SSD 마모 분산과 한 디스크 장애 대응을 함께 검토할 때 비교합니다. RAID 5와의 핵심 차이는 패리티 쓰기 배분이며 일반 HDD RAID 5의 단순 대체 방식이 아닙니다. 쓰기 부하와 필요한 장애 허용 범위에 따라 다른 지원 RAID도 함께 비교합니다. | |||
02B / RAID CAPACITY AND EFFICIENCY
같은 용량의 디스크를 사용할 때 RAID 방식과 참여 디스크 수에 따라 계산상 데이터 공간과 용량 효율이 달라집니다.
N = RAID에 참여하는 전체 디스크 개수 / S = 디스크 한 개의 용량
G = RAID 50 또는 RAID 60을 구성하는 하위 RAID 그룹 개수
용량 효율 = RAID 계산상 데이터 공간 ÷ 참여 디스크 전체 표기 용량 × 100
같은 용량 디스크를 사용하는 상담용 계산 예시이며 TB는 십진수 기준입니다. RAID 1은 두 디스크 미러, RAID 10은 미러 쌍, RAID 50과 RAID 60은 동일한 크기의 하위 그룹을 전제로 합니다. 핫스페어는 N과 용량 효율 계산에 포함하지 않습니다.
실제 지원 RAID, 그룹 수와 디스크 수는 NAS 모델과 운영체제에 따라 다릅니다. 아래 계산에는 시스템, 파일시스템 관리 공간과 예약 공간을 반영하지 않았습니다.
12TB HDD 4개 → 4 × 12TB = 48TB
전체 표기 용량 48TB 중 RAID 계산상 데이터 공간도 48TB이므로 효율은 100%입니다.
RAID 0은 미러나 패리티 공간을 사용하지 않고 여러 디스크에 데이터를 분산합니다. 동일 용량 디스크 기준으로 RAID에 참여한 디스크의 표기 용량을 모두 데이터 공간 계산에 사용합니다.
모든 디스크는 12TB이며, 아래 구성은 계산을 위한 예시입니다. 실제 장비의 지원 조건은 별도로 확인합니다.
| 디스크 구성 | 계산상 용량 | 용량 효율 |
|---|---|---|
| 12TB × 2개 | 24TB | 100% |
| 12TB × 4개 | 48TB | 100% |
| 12TB × 6개 | 72TB | 100% |
100%라는 높은 효율은 장애 보호 비용을 사용하지 않은 결과입니다. RAID 0은 참여 디스크 가운데 한 개의 장애만으로도 전체 RAID의 데이터 접근을 잃을 수 있습니다.
따라서 용량 효율 100%를 RAID 5나 RAID 6보다 우수한 보호 구성이라는 의미로 해석하지 않습니다.
대용량 임시 작업공간처럼 데이터 손실 시 원본에서 다시 만들 수 있고 별도 사본이 확보된 환경에서 검토할 수 있습니다. 중요한 원본이나 유일한 업무 데이터의 보호 수단으로 사용하지 않습니다.
12TB HDD 2개 → 계산상 데이터 공간 12TB
전체 표기 용량 24TB 대비 효율 50%
두 디스크에 같은 데이터를 기록하는 미러를 기준으로 계산상 용량은 S, 용량 효율은 50%입니다. 서로 다른 용량을 사용하면 일반적인 RAID 1의 데이터 공간은 가장 작은 참여 디스크 한 개분을 기준으로 봅니다.
같은 용량 디스크 두 개를 미러링하는 예시입니다. 디스크 용량이 달라져도 두 디스크 미러의 효율은 50%입니다.
| 디스크 구성 | 계산상 용량 | 용량 효율 |
|---|---|---|
| 8TB × 2개 | 8TB | 50% |
| 12TB × 2개 | 12TB | 50% |
| 16TB × 2개 | 16TB | 50% |
이 예시의 두 디스크 미러는 디스크 한 개 장애에 대응합니다. 재구축 중에는 남은 디스크의 상태를 함께 확인합니다.
세 개 이상의 디스크를 하나의 미러로 사용하는 환경에서는 복제본 수가 늘어도 데이터 공간은 한 디스크분입니다. 이러한 다중 미러의 지원 여부와 장애 허용 범위는 제조사 및 운영체제 조건을 따릅니다.
2베이 NAS처럼 단순한 미러 보호가 필요한 환경에서 자주 사용합니다. 다중 미러는 용량 효율 감소와 추가 복제본의 필요성을 함께 판단합니다.
4개 이상의 디스크에서 50% 용량 효율을 유지하면서 미러 구조를 사용하려는 경우에는 RAID 10과 구조 및 장애 조건을 비교할 수 있습니다.
12TB HDD 4개 → (4 − 1) × 12TB = 36TB
전체 표기 용량 48TB 대비 효율 75%
동일 용량 디스크 한 개분을 패리티 공간으로 반영합니다. 패리티는 특정 디스크에만 저장하는 것이 아니라 참여 디스크에 분산합니다.
용량 효율 = (N − 1) ÷ N × 100%입니다.
모든 디스크는 12TB이며, 아래 구성은 계산을 위한 예시입니다. 실제 장비의 지원 조건은 별도로 확인합니다.
| 디스크 구성 | 계산상 용량 | 용량 효율 |
|---|---|---|
| 12TB × 3개 | 24TB | 66.7% |
| 12TB × 4개 | 36TB | 75% |
| 12TB × 6개 | 60TB | 83.3% |
참여 디스크가 늘면 전체 표기 용량에서 1개분의 패리티가 차지하는 비율이 작아져 효율이 높아집니다. 하지만 정상 구성의 장애 허용 범위는 1개로 유지됩니다.
효율만으로 그룹 크기를 정하지 않고 디스크 상태, 재구축 중 부하와 필요한 운영 여유를 함께 확인합니다.
한 디스크 장애 후에는 남은 디스크와 패리티를 이용해 데이터를 재구축합니다. 재구축이 완료되기 전에는 추가 디스크 장애를 허용하지 않습니다.
디스크 수와 용량이 커질수록 재구축에 필요한 데이터량과 작업 시간이 커질 수 있으므로 실제 그룹 크기, 디스크 상태와 업무 중단 요구를 함께 판단합니다.
RAID 5는 같은 디스크 수의 RAID 6보다 한 디스크분의 데이터 공간을 더 확보할 수 있습니다. 대신 RAID 6은 두 개 디스크 장애에 대응합니다.
12TB HDD 6개 → (6 − 2) × 12TB = 48TB
전체 표기 용량 72TB 대비 효율 66.7%
동일 용량 디스크 두 개분을 패리티 공간으로 반영합니다. 패리티는 특정 디스크에만 저장하는 것이 아니라 참여 디스크에 분산합니다.
용량 효율 = (N − 2) ÷ N × 100%입니다.
모든 디스크는 12TB이며, 아래 구성은 계산을 위한 예시입니다. 실제 장비의 지원 조건은 별도로 확인합니다.
| 디스크 구성 | 계산상 용량 | 용량 효율 |
|---|---|---|
| 12TB × 4개 | 24TB | 50% |
| 12TB × 6개 | 48TB | 66.7% |
| 12TB × 8개 | 72TB | 75% |
참여 디스크가 늘면 전체 표기 용량에서 2개분의 패리티가 차지하는 비율이 작아져 효율이 높아집니다. 하지만 정상 구성의 장애 허용 범위는 2개로 유지됩니다.
효율만으로 그룹 크기를 정하지 않고 디스크 상태, 재구축 중 부하와 필요한 운영 여유를 함께 확인합니다.
정상 상태에서는 두 개 디스크 장애에 대응합니다. 한 개 디스크가 이미 고장 난 상태에서는 남은 보호 범위가 한 개로 줄고, 두 개 장애 상태에서는 추가 장애를 허용할 여유가 없습니다.
재구축 중의 실제 운영 위험은 남은 디스크 상태, 그룹 크기, 디스크 용량과 작업 부하까지 함께 판단합니다.
같은 디스크 수에서 RAID 5보다 데이터 공간을 한 디스크분 더 사용해 패리티를 저장하는 대신 장애 허용 범위를 한 개 더 확보합니다.
12TB HDD 6개 → 6 ÷ 2 × 12TB = 36TB
전체 표기 용량 72TB 대비 효율 50%
두 디스크씩 미러 쌍을 만든 뒤 여러 미러 쌍 사이에 데이터를 분산합니다. 동일 용량 디스크에서는 절반을 데이터 공간, 절반을 미러 복제 공간으로 사용하므로 디스크 수가 증가해도 계산상 효율은 50%입니다.
모든 디스크는 12TB이며, 아래 구성은 계산을 위한 예시입니다. 실제 장비의 지원 조건은 별도로 확인합니다.
| 디스크 구성 | 계산상 용량 | 용량 효율 |
|---|---|---|
| 12TB × 4개 미러 2쌍 | 24TB | 50% |
| 12TB × 6개 미러 3쌍 | 36TB | 50% |
| 12TB × 8개 미러 4쌍 | 48TB | 50% |
RAID 10은 “디스크 두 개 장애 허용”으로 단순하게 표현할 수 없습니다.
서로 다른 미러 쌍에서 한 개씩 고장 난 경우에는 여러 디스크 장애에도 데이터가 유지될 수 있지만, 같은 미러 쌍의 두 디스크가 모두 고장 나면 전체 RAID의 데이터 접근을 잃을 수 있습니다.
따라서 장애 수보다 어느 미러 쌍에서 장애가 발생했는지가 중요합니다.
고장 난 디스크가 속한 미러 쌍의 정상 디스크에서 새 디스크로 데이터를 복제하는 방식으로 재구축합니다. 패리티 RAID와 재구축 구조가 다르지만, 실제 소요시간과 업무 영향은 디스크 용량과 상태, NAS 처리 성능과 현재 부하에 따라 달라집니다.
가상머신과 데이터베이스처럼 작은 임의 읽기와 쓰기, 응답시간이 중요한 환경에서 RAID 5 또는 RAID 6과 함께 비교할 수 있습니다.
다만 RAID 10이라는 이유만으로 항상 더 빠르다고 단정하지 않습니다. HDD 또는 SSD, 읽기와 쓰기 비율, 동시 작업량, 네트워크와 NAS의 처리 성능을 함께 확인합니다.
12TB HDD 12개, RAID 5 하위 그룹 2개 × 그룹당 6개 → (12 − 2) × 12TB = 120TB
전체 표기 용량 144TB 중 하위 그룹마다 1개분의 패리티 공간을 반영하면 효율은 83.3%입니다.
G는 RAID 5 하위 그룹의 개수이며 N은 모든 하위 그룹에 참여하는 디스크의 합계입니다. 같은 용량 디스크와 동일한 하위 그룹 크기를 가정합니다.
각 하위 그룹에 RAID 5를 구성하고 그 위에서 스트라이핑합니다. 그룹마다 1개분의 패리티 공간이 필요하므로 전체에서 G개분을 제외합니다.
별도의 RAID 5 그룹 여러 개를 독립적으로 운영하는 구성과는 다릅니다. 지원 RAID, 그룹 수와 그룹당 디스크 수는 해당 NAS 모델과 운영체제에서 확인합니다.
모든 디스크는 12TB이며 하위 그룹의 디스크 수를 동일하게 맞춘 가정입니다. 12개 구성 두 가지는 그룹 수에 따른 차이를 비교합니다.
| 디스크 구성 | 계산상 용량 | 용량 효율 |
|---|---|---|
| 12TB × 6개 2그룹 × 그룹당 3개 | 48TB | 66.7% |
| 12TB × 12개 2그룹 × 그룹당 6개 | 120TB | 83.3% |
| 12TB × 12개 3그룹 × 그룹당 4개 | 108TB | 75% |
12개 디스크를 2그룹으로 나누면 120TB, 3그룹으로 나누면 108TB입니다. 총 디스크 수가 같아도 그룹 수가 늘면 패리티에 사용하는 공간이 늘어납니다.
그룹 수를 용량 효율만으로 정하지 않고 그룹별 장애 허용, 재구축 중 부하와 장비의 지원 범위를 함께 비교합니다.
정상 구성에서 각 하위 그룹의 디스크 1개 장애에 대응합니다. 어느 한 그룹이라도 이 범위를 넘으면 전체 RAID 50의 데이터 접근을 잃을 수 있습니다.
2그룹 구성이라고 해서 임의의 디스크 2개 장애를 항상 허용하는 것은 아닙니다. 재구축 중에는 영향을 받은 그룹의 남은 중복 보호와 디스크 상태를 확인하며, 복구 시간은 디스크 용량과 작업 부하 등에 따라 달라집니다.
여러 디스크를 하위 그룹으로 나누고 그룹마다 패리티 보호를 적용하려는 경우 비교합니다. 단일 RAID 5보다 패리티 공간을 더 사용하며, 같은 그룹 배치의 RAID 60보다 용량은 크지만 그룹당 장애 허용은 작습니다.
그룹 분할만으로 성능이나 서비스 연속성이 보장되지는 않습니다. 실제 작업 부하와 별도 백업 및 복원 계획을 함께 확인합니다.
12TB HDD 12개, RAID 6 하위 그룹 2개 × 그룹당 6개 → (12 − 4) × 12TB = 96TB
전체 표기 용량 144TB 중 하위 그룹마다 2개분의 패리티 공간을 반영하면 효율은 66.7%입니다.
G는 RAID 6 하위 그룹의 개수이며 N은 모든 하위 그룹에 참여하는 디스크의 합계입니다. 같은 용량 디스크와 동일한 하위 그룹 크기를 가정합니다.
각 하위 그룹에 RAID 6를 구성하고 그 위에서 스트라이핑합니다. 그룹마다 2개분의 패리티 공간이 필요하므로 전체에서 2 × G개분을 제외합니다.
별도의 RAID 6 그룹 여러 개를 독립적으로 운영하는 구성과는 다릅니다. 지원 RAID, 그룹 수와 그룹당 디스크 수는 해당 NAS 모델과 운영체제에서 확인합니다.
모든 디스크는 12TB이며 하위 그룹의 디스크 수를 동일하게 맞춘 가정입니다. 12개 구성 두 가지는 그룹 수에 따른 차이를 비교합니다.
| 디스크 구성 | 계산상 용량 | 용량 효율 |
|---|---|---|
| 12TB × 8개 2그룹 × 그룹당 4개 | 48TB | 50% |
| 12TB × 12개 2그룹 × 그룹당 6개 | 96TB | 66.7% |
| 12TB × 12개 3그룹 × 그룹당 4개 | 72TB | 50% |
12개 디스크를 2그룹으로 나누면 96TB, 3그룹으로 나누면 72TB입니다. 총 디스크 수가 같아도 그룹 수가 늘면 패리티에 사용하는 공간이 늘어납니다.
그룹 수를 용량 효율만으로 정하지 않고 그룹별 장애 허용, 재구축 중 부하와 장비의 지원 범위를 함께 비교합니다.
정상 구성에서 각 하위 그룹의 디스크 2개 장애에 대응합니다. 어느 한 그룹이라도 이 범위를 넘으면 전체 RAID 60의 데이터 접근을 잃을 수 있습니다.
2그룹 구성이라고 해서 임의의 디스크 4개 장애를 항상 허용하는 것은 아닙니다. 재구축 중에는 영향을 받은 그룹의 남은 중복 보호와 디스크 상태를 확인하며, 복구 시간은 디스크 용량과 작업 부하 등에 따라 달라집니다.
하위 그룹마다 두 디스크 장애에 대응해야 하는 경우 비교합니다. 단일 RAID 6보다 패리티 공간을 더 사용하며, 같은 그룹 배치의 RAID 50보다 계산상 용량은 작습니다.
그룹 분할만으로 성능이나 서비스 연속성이 보장되지는 않습니다. 실제 작업 부하와 별도 백업 및 복원 계획을 함께 확인합니다.
02C / WORKLOAD
RAID는 용량 효율이나 장애 대응 수만으로 선택하지 않습니다. 파일 크기, 읽기와 쓰기 비율, 동시 작업 수, 응답시간과 필요한 복원 범위를 기준으로 비교할 RAID 후보를 정합니다.
아래 내용은 특정 RAID를 일괄 추천하는 기준이 아니라, 업무 특성에 따라 먼저 비교할 구성을 찾기 위한 안내입니다.
| 작업 환경 | 중요하게 볼 조건 | 비교할 RAID 후보 |
|---|---|---|
일반 문서 및 파일 공유 | 필요한 용량, 동시 사용자, 장애 대응 | RAID 1, RAID 5, RAID 6 |
RAID 비교 기준소규모 구성에서는 RAID 1의 단순한 미러 구조를 먼저 비교할 수 있습니다. 디스크 수와 필요한 공간이 늘어나면 RAID 5와 RAID 6의 용량 효율 및 장애 대응 범위를 함께 봅니다. 성능 확인 조건사용자가 많다는 이유만으로 RAID 방식을 결정하지 않습니다. 문서 파일 크기, 동시 접근량, 파일 서버 기능과 네트워크 속도가 실제 체감 성능에 영향을 줍니다. | ||
사진 원본 및 대용량 자료 보관 | 데이터 증가량, 순차 읽기, 보관 기간 | RAID 5, RAID 6 |
필요 공간 산정RAW 사진이나 대용량 프로젝트 자료처럼 데이터가 계속 증가하는 환경은 장기간 필요한 공간을 먼저 계산합니다. RAID 비교 기준같은 용량의 디스크를 같은 개수로 구성할 때, RAID 6은 RAID 5보다 한 디스크분의 공간을 더 패리티에 사용하며 두 개 디스크 장애에 대응합니다. 원본 백업다시 만들 수 없는 원본이라면 RAID 방식과 별도로 다른 장치나 위치의 백업을 준비합니다. | ||
영상 아카이브 및 대용량 파일 저장 | 지속적인 대용량 전송, 용량 증가량 | RAID 5, RAID 6 |
저장 및 전송 조건완성 영상이나 촬영 자료를 저장하고 큰 파일을 연속해서 읽고 쓰는 환경입니다. 필요한 총 저장공간과 실제 순차 전송량을 기준으로 RAID 5와 RAID 6을 비교합니다. 그룹 크기와 재구축단일 RAID 그룹의 디스크 수를 늘리기 전에는 지원 가능한 그룹 크기와 재구축 중 업무 영향을 확인합니다. | ||
NAS에서 영상 직접 편집 | 영상 비트레이트, 동시 스트림, 처리량과 지연 | RAID 6, RAID 1+0 (RAID 10) 등 |
편집 작업 부하영상 파일을 NAS에서 바로 편집한다면 저장 용량만으로 RAID를 정하지 않습니다. 코덱과 비트레이트, 편집자 수, 동시 스트림과 읽기와 쓰기 작업이 실제 부하를 결정합니다. RAID 비교 기준RAID 1+0 (RAID 10)은 패리티 갱신이 없는 미러 기반 구조이므로 작은 임의 읽기와 쓰기가 섞이고 응답시간이 중요한 환경에서 비교 후보가 될 수 있습니다. RAID 6은 필요한 용량과 두 개 디스크 장애 대응을 함께 확보해야 할 때 비교합니다. 네트워크 확인NAS부터 스위치와 작업 컴퓨터까지의 네트워크가 필요한 처리량을 제공하는지도 확인합니다. | ||
PC 및 서버 백업 저장소 | 백업 보관량, 변경량, 백업 창, 복원 시간 | RAID 5, RAID 6 |
백업 공간 산정백업용 NAS는 원본 데이터량보다 보관할 복원 시점, 변경량과 보존 기간 때문에 필요한 공간이 커질 수 있습니다. 백업 및 복원 시간RAID 5와 RAID 6의 용량 및 장애 대응 범위를 비교하되, 실제 선택에는 백업이 완료되어야 하는 시간과 장애 발생 후 필요한 데이터를 복원하는 데 허용할 수 있는 시간도 포함합니다. 복원 가능성 확인백업 저장소의 RAID가 정상이라는 것과 실제 백업에서 데이터를 복원할 수 있다는 것은 별도로 확인합니다. | ||
가상머신 운영 | 작은 임의 읽기와 쓰기, 응답시간, 동시 VM 부하 | RAID 1+0 (RAID 10), RAID 5, RAID 6 |
가상머신 실행 위치NAS 내부에서 가상머신을 실행하는지, 외부 가상화 서버가 NAS를 저장소로 사용하는지 먼저 구분합니다. 실행 위치에 따라 NAS의 가상화 기능과 CPU와 메모리, 저장소 연결 방식과 네트워크를 확인합니다. RAID 비교 기준작은 임의 쓰기와 낮은 지연시간이 중요하면 RAID 1+0 (RAID 10)을 먼저 비교하고, 필요한 용량과 실제 부하에 따라 RAID 5와 RAID 6도 함께 검토합니다. 동시 VM 부하동시에 실행하는 VM 수와 각 VM의 부하가 실제 요구 성능에 영향을 줍니다. | ||
데이터베이스 및 업무 프로그램 | 쓰기 지연, 랜덤 I/O, 동시 요청, 데이터 일관성 | RAID 1+0 (RAID 10), RAID 5, RAID 6 |
RAID 비교 기준데이터베이스는 작은 읽기와 쓰기가 반복되고 쓰기 지연에 민감할 수 있으므로 RAID 1+0 (RAID 10)을 비교 후보로 둘 수 있습니다. 프로그램 지원과 백업실제 프로그램이 NAS의 저장 방식이나 프로토콜을 지원하는지 먼저 확인합니다. 데이터베이스의 트랜잭션 일관성과 전용 백업은 RAID가 대신하지 않습니다. | ||
CCTV 및 NVR 연속 녹화 | 카메라 수, 비트레이트, 보관 일수, 지속 쓰기 | RAID 5, RAID 6 |
녹화 용량 산정영상 감시 저장소는 카메라 수와 해상도만으로 용량을 정하지 않고 실제 비트레이트, 하루 녹화 시간과 보관 일수로 계산합니다. 녹화 및 재생 부하RAID 5와 RAID 6을 비교할 때는 필요한 녹화 공간과 장애 대응 범위를 함께 봅니다. 지속적인 쓰기 작업 외에도 동시에 영상을 검색하거나 재생할 때 필요한 처리량을 확인합니다. 중요 영상 보존중요 영상을 장기간 보존해야 한다면 자동 덮어쓰기 대상에서 분리하거나 별도 사본을 마련합니다. | ||
다수의 디스크를 사용하는 고처리량 환경 | 하위 그룹 구성, 처리량, 장애 허용과 재구축 영향 | RAID 5+0 (RAID 50), RAID 6+0 (RAID 60) 등 |
복합 RAID 비교디스크 수가 많은 환경에서는 RAID 5+0 (RAID 50)과 RAID 6+0 (RAID 60)처럼 여러 하위 RAID 그룹을 사용하는 구조도 비교할 수 있습니다. 그룹별 장애 대응RAID 50은 각 RAID 5 하위 그룹에서 한 개 디스크 장애를, RAID 60은 각 RAID 6 하위 그룹에서 두 개 디스크 장애를 허용합니다. 장애 위치와 재구축전체 장애 디스크 수만으로 보호 범위를 판단하지 않습니다. 같은 하위 그룹이 허용 범위를 넘으면 전체 RAID 50 또는 RAID 60에 영향을 줄 수 있으므로 하위 그룹별 장애 허용과 재구축 영향을 함께 봅니다. 독립 그룹과의 구분여러 독립 RAID 5 또는 RAID 6 그룹을 각각 운영하는 것과 RAID 50 또는 RAID 60으로 하위 그룹을 다시 스트라이핑하는 것도 서로 다른 구성입니다. | ||
사진 원본이나 영상처럼 큰 파일을 연속해서 읽고 쓰는 작업과, 가상머신이나 데이터베이스처럼 작은 데이터 요청이 반복되는 작업은 저장장치에 주는 부하가 다릅니다.
RAID 5와 RAID 6은 쓰기 과정에서 패리티 갱신이 필요합니다. RAID 1+0 (RAID 10)은 패리티를 사용하지 않는 미러 기반 구조이므로 작은 임의 입출력과 응답시간이 중요한 환경에서 비교할 이유가 있습니다.
RAID 10이라는 이유만으로 항상 더 빠르다고 단정하지 않습니다.
실제 프로그램의 요청 크기, 읽기와 쓰기 비율과 동시 작업 수를 반영해 처리량과 응답시간을 확인하며, 평균값뿐 아니라 부하가 몰리는 시간대의 지연도 함께 봅니다.
다음 조건이 RAID보다 먼저 병목이 될 수 있습니다.
NAS 내부 저장소가 충분히 빠르더라도 네트워크가 먼저 제한되면 RAID 변경만으로 실제 작업 속도가 향상되지 않을 수 있습니다.
RAID 5의 한 개, RAID 6의 두 개 장애 대응은 RAID가 정상 상태일 때의 중복 보호 범위입니다.
장애가 발생한 뒤의 재구축 시간, 작업 중 성능 변화, 추가 장애 위험과 백업에서 복원하는 데 필요한 시간은 별도의 운영 조건입니다.
RAID 1+0 (RAID 10), RAID 5+0 (RAID 50), RAID 6+0 (RAID 60)은 단순히 전체 장애 디스크 수만으로 보호 범위를 설명하지 않고 미러 쌍 또는 하위 RAID 그룹의 장애 위치를 함께 확인합니다.
02D / BAY CONFIGURATION
2베이부터 60베이까지의 본체 구성과 확장 장치 연결 예시를 비교합니다. RAID 참여 디스크, 매체 종류, 핫스페어와 빈 슬롯을 구분하고, 장치별 저장소 배치와 다음 확장 방법을 함께 확인합니다.
2~24베이는 12TB HDD, 30베이는 HDD와 SSD의 별도 풀, 36베이는 스토리지 서버, 48베이는 HDD 및 SSD 유형별 구성, 60베이는 HD6500의 데이터 베이를 기준으로 비교합니다. 각 항목에 디스크 용량과 장비 조건을 표시한 신규 구성의 가정이며 실제 구축 실적이나 기존 RAID 변경 절차를 뜻하지 않습니다.
계산상 용량은 십진수 TB 기준이며 시스템, 파일시스템과 예약 공간을 차감하기 전입니다. 핫스페어는 용량에서 제외하며 빈 베이는 미장착 슬롯입니다. 확장 장치를 합친 전체 베이 수와 하나의 배열, 풀 및 볼륨이 지원하는 범위는 각각 확인합니다.
HDD / INITIAL CONFIGURATION
동일한 12TB HDD를 사용하는 신규 구성 예시입니다. 표의 RAID와 예비 디스크 설정을 지원하는 모델 및 OS를 전제로 하며, 시스템 공간과 예약 공간을 차감하기 전의 용량입니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| Basic / Single | 1개 | 12TB | 없음 | 1개 |
| RAID 1 | 2개 | 12TB | 없음 | 없음 |
| RAID 0 | 2개 | 24TB | 없음 | 없음 |
RAID 1은 두 디스크에 같은 데이터를 기록해 계산상 12TB와 디스크 한 개 장애 대응을 확보합니다. Basic 한 개 구성도 12TB이지만 중복 보호가 없으며, 두 구성을 같은 보호 수준으로 비교하지 않습니다.
RAID 0의 24TB는 두 디스크 용량을 합친 값입니다. 별도 원본이 있고 다시 만들 수 있는 작업 공간 등에서 검토하더라도, 한 디스크 장애로 전체 RAID의 데이터 접근을 잃을 수 있다는 조건을 수용해야 합니다.
두 디스크 미러가 모두 장착되면 별도 핫스페어를 넣을 슬롯은 없습니다. 장애 디스크 교체와 재구축 중에는 추가 장애를 허용하지 않으므로 교체 대응 시간과 별도 백업을 함께 계획합니다.
두 베이를 모두 사용하면 빈 슬롯에 디스크를 추가하는 확장은 할 수 없습니다. 지원되는 대용량 디스크 교체 확장이나 다른 저장소로 이전하는 방법을 비교합니다.
디스크 교체와 실제 풀 및 볼륨 용량 확장은 별도 단계가 될 수 있습니다. Basic 한 개로 시작한 경우의 RAID 1 전환도 지원되는 변경 경로에서 조건을 확인합니다.
HDD / INITIAL CONFIGURATION
동일한 12TB HDD를 사용하는 신규 구성 예시입니다. 표의 RAID와 예비 디스크 설정을 지원하는 모델 및 OS를 전제로 하며, 시스템 공간과 예약 공간을 차감하기 전의 용량입니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| RAID 5 | 3개 | 24TB | 없음 | 1개 |
| RAID 5 | 4개 | 36TB | 없음 | 없음 |
| RAID 6 | 4개 | 24TB | 없음 | 없음 |
| RAID 1+0 (RAID 10) | 4개 | 24TB | 없음 | 없음 |
| RAID 5 | 3개 | 24TB | 1개 | 없음 |
3개 RAID 5는 계산상 24TB와 빈 베이 한 개를 남깁니다. 4개 RAID 5는 36TB를 제공하지만 장애 대응은 한 개로 같습니다. 현재 용량과 다음 디스크 추가 시점을 함께 정합니다.
4개 RAID 6과 RAID 10은 모두 24TB이지만 선택 근거가 다릅니다. RAID 6은 두 디스크 장애 대응, RAID 10은 미러 쌍의 장애 조건과 실제 업무의 입출력 특성을 비교합니다.
3개 RAID 5와 핫스페어 한 개는 24TB를 유지하며, 지정된 예비 디스크로 장애 디스크를 대체해 재구축하는 구성입니다. RAID 5는 한 디스크 장애 후 재구축이 끝나기 전에 추가 디스크 장애를 허용하지 않습니다. 핫스페어를 더해도 RAID 6의 두 디스크 장애 대응과 같아지지 않습니다.
빈 베이는 추후 장착할 공간이고, 핫스페어는 이미 장착해 보호 대상 RAID에 지정한 디스크입니다. 마지막 행은 확장용 빈 슬롯을 남기는 대신 장애 시 교체를 시작할 예비 디스크를 확보합니다.
4개를 모두 사용한 구성은 새 디스크를 넣을 슬롯이 없습니다. 대용량 디스크 교체, 지원 확장 장치 또는 다른 NAS로의 이전 중 가능한 경로를 확인합니다.
3개 RAID 5에서 남은 베이를 이용한 추가 확장이나 RAID 6 전환은 OS가 해당 작업을 지원할 때 적용합니다. 4베이라는 이유만으로 변경 기능이 제공되지는 않습니다.
HDD / INITIAL CONFIGURATION
동일한 12TB HDD를 사용하는 신규 구성 예시입니다. 표의 RAID와 예비 디스크 설정을 지원하는 모델 및 OS를 전제로 하며, 시스템 공간과 예약 공간을 차감하기 전의 용량입니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| RAID 6 | 4개 | 24TB | 없음 | 2개 |
| RAID 6 | 5개 | 36TB | 없음 | 1개 |
| RAID 6 | 6개 | 48TB | 없음 | 없음 |
| RAID 1+0 (RAID 10) | 6개 | 36TB | 없음 | 없음 |
| RAID 6 | 5개 | 36TB | 1개 | 없음 |
4개 RAID 6은 24TB와 빈 베이 두 개, 5개 RAID 6은 36TB와 빈 베이 한 개를 남깁니다. 6개 RAID 6은 48TB를 확보하는 대신 모든 슬롯을 사용합니다.
6개 RAID 10의 계산상 용량은 36TB입니다. 5개 RAID 6과 용량이 같아도 장착 수, 장애 위치에 따른 결과와 쓰기 특성이 다르므로 실제 작업 부하를 기준으로 비교합니다.
5개 RAID 6과 핫스페어 한 개는 36TB에 예비 디스크를 더한 구성입니다. 핫스페어가 있다고 RAID 6의 정상 상태 장애 허용 수가 세 개로 늘어나지는 않습니다.
빈 베이와 기존 RAID의 디스크 추가 확장 지원은 별개입니다. Synology 공식 안내에서 RAID 10은 기존 배열에 디스크를 추가하는 확장을 지원하지 않습니다. 필요한 경우 지원되는 대용량 교체 확장이나 재구성 및 이전을 비교합니다.
RAID 6을 일부 디스크로 시작한다면 추가할 디스크의 용량과 최대 참여 수, 확장 후 볼륨 한도를 기준으로 증설 단위를 정합니다. 디스크를 더 장착할 수 있어도 배열 또는 볼륨 한도에 도달하면 별도 저장소가 필요할 수 있습니다.
HDD / INITIAL CONFIGURATION
동일한 12TB HDD를 사용하는 신규 구성 예시입니다. 표의 RAID와 예비 디스크 설정을 지원하는 모델 및 OS를 전제로 하며, 시스템 공간과 예약 공간을 차감하기 전의 용량입니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| RAID 6 | 6개 | 48TB | 없음 | 2개 |
| RAID 6 | 7개 | 60TB | 1개 | 없음 |
| RAID 6 | 8개 | 72TB | 없음 | 없음 |
| RAID 1+0 (RAID 10) | 8개 | 48TB | 없음 | 없음 |
| RAID 6+0 (RAID 60) | 2그룹 × 그룹당 4개 | 48TB | 없음 | 없음 |
6개 RAID 6은 48TB와 빈 베이 두 개를 남깁니다. 7개 RAID 6에 핫스페어 한 개를 두면 60TB이며, 8개 RAID 6은 예비 디스크 없이 72TB입니다.
8개 RAID 10과 4개씩 두 하위 그룹으로 구성한 RAID 60은 모두 48TB입니다. RAID 10의 미러 쌍과 RAID 60의 RAID 6 하위 그룹은 데이터 배치와 장애 조건이 다르므로 같은 용량만 보고 결정하지 않습니다.
RAID 60은 각 하위 그룹에서 두 개까지의 디스크 장애에 대응합니다. 임의의 네 디스크 장애를 항상 허용한다는 의미는 아닙니다. RAID 10도 임의의 두 디스크 장애를 항상 허용하지 않습니다.
RAID 60 지원 여부는 제조사와 OS별로 확인합니다. RAID 6 배열 두 개를 따로 운영하는 구성을 RAID 60이라고 부르지 않습니다.
남긴 두 슬롯을 기존 그룹 확장에 쓸지, 별도 저장소나 핫스페어에 쓸지 먼저 정합니다. RAID 10이나 RAID 60에 디스크를 임의로 한 개씩 추가할 수 있다고 가정하지 않습니다.
온라인 확장을 지원해도 작업 중 처리량과 응답시간이 달라질 수 있으므로 작업 준비와 상태별 진행 판단을 함께 확인합니다.
HDD / INITIAL CONFIGURATION
동일한 12TB HDD를 사용하는 신규 구성 예시입니다. 표의 RAID와 예비 디스크 설정을 지원하는 모델 및 OS를 전제로 하며, 시스템 공간과 예약 공간을 차감하기 전의 용량입니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| RAID 6 | 10개 | 96TB | 1개 | 1개 |
| RAID 6 | 12개 | 120TB | 없음 | 없음 |
| RAID 1+0 (RAID 10) | 12개 | 72TB | 없음 | 없음 |
| RAID 5+0 (RAID 50) | 2그룹 × 그룹당 6개 | 120TB | 없음 | 없음 |
| RAID 6+0 (RAID 60) | 2그룹 × 그룹당 6개 | 96TB | 없음 | 없음 |
10개 RAID 6과 핫스페어 한 개는 96TB와 빈 베이 한 개를 남깁니다. 12개 RAID 6은 120TB이며, 12개 RAID 10은 72TB입니다.
6개씩 두 하위 그룹으로 나누면 RAID 50은 120TB, RAID 60은 96TB입니다. 단일 RAID 6과 RAID 50이 같은 120TB여도 장애 대응 구조는 다릅니다.
단일 RAID 6은 두 디스크 장애에 대응하지만, RAID 50은 각 RAID 5 하위 그룹에서 한 개까지만 허용합니다. 같은 하위 그룹의 두 디스크가 실패하면 전체 RAID 50에 영향을 줍니다.
그룹을 나누면 재구축 대상 배열의 크기가 달라집니다. 실제 재구축 시간과 서비스 영향은 디스크 성능, 부하, 컨트롤러와 OS의 구현을 함께 확인합니다.
남은 베이 한 개의 활용은 현재 RAID에 따라 달라집니다. QTS 5.2.x에서 기존 RAID 50 또는 RAID 60 그룹에 디스크를 추가할 때는 모든 하위 그룹에 같은 수를 추가해야 합니다. 두 하위 그룹에 한 개씩 추가하려면 최소 두 개의 빈 슬롯이 필요하므로, 빈 슬롯 하나로는 이 방식의 확장을 진행할 수 없습니다.
단일 볼륨 한도와 필요한 메모리는 모델별로 대조합니다. 계산상 120TB를 한 볼륨에 담을 수 없다면 업무별 볼륨 분리나 다른 장비로의 이전을 비교합니다.
HDD / INITIAL CONFIGURATION
동일한 12TB HDD를 사용하는 신규 구성 예시입니다. 표의 RAID와 예비 디스크 설정을 지원하는 모델 및 OS를 전제로 하며, 시스템 공간과 예약 공간을 차감하기 전의 용량입니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| RAID 6 | 14개 | 144TB | 1개 | 1개 |
| RAID 6 | 16개 | 168TB | 없음 | 없음 |
| RAID 1+0 (RAID 10) | 16개 | 96TB | 없음 | 없음 |
| RAID 5+0 (RAID 50) | 2그룹 × 그룹당 8개 | 168TB | 없음 | 없음 |
| RAID 6+0 (RAID 60) | 2그룹 × 그룹당 8개 | 144TB | 없음 | 없음 |
14개 RAID 6과 핫스페어 한 개는 144TB와 빈 베이 한 개를 남깁니다. 16개 RAID 6은 168TB, RAID 10은 96TB입니다.
8개씩 두 하위 그룹으로 구성하면 RAID 50은 168TB, RAID 60은 144TB입니다. 필요한 용량을 충족한 후보 중 업무 지연, 재구축 범위와 교체 대응 방식을 비교합니다.
한 개의 16디스크 배열과 두 개의 8디스크 하위 그룹은 장애가 집중되는 범위가 다릅니다. RAID 50은 그룹당 한 개, RAID 60은 그룹당 두 개의 장애 허용 조건을 적용합니다.
표의 첫 행은 핫스페어가 한 개입니다. 이 디스크가 재구축에 편입되면 대기 중인 예비 디스크는 남지 않습니다. 추가 교체에 대비한 보충 시점을 정하고, 복수 핫스페어가 필요하면 남겨 둔 베이의 용도를 다시 결정합니다.
QTS 5.2.x의 기존 그룹 디스크 추가 절차는 RAID 5와 RAID 6의 최대 참여 수를 16개로 안내합니다. 따라서 16개 RAID 6 행은 이 절차로 더 늘릴 수 없으며, 새 RAID 그룹 추가나 다른 저장소로의 이전을 비교해야 합니다. 이 한도를 다른 OS에 그대로 적용하지 않습니다.
다음 확장을 외장 확장 장치에 의존한다면 연결 대역폭과 케이블 및 장치 장애의 영향 범위까지 함께 계획합니다.
HDD / INITIAL CONFIGURATION
동일한 12TB HDD를 사용하는 신규 구성 예시입니다. 표의 RAID와 예비 디스크 설정을 지원하는 모델 및 OS를 전제로 하며, 시스템 공간과 예약 공간을 차감하기 전의 용량입니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| RAID 5+0 (RAID 50) | 2그룹 × 그룹당 12개 | 264TB | 없음 | 없음 |
| RAID 6+0 (RAID 60) | 2그룹 × 그룹당 12개 | 240TB | 없음 | 없음 |
| RAID 6+0 (RAID 60) | 4그룹 × 그룹당 6개 | 192TB | 없음 | 없음 |
| RAID 6+0 (RAID 60) | 2그룹 × 그룹당 11개 | 216TB | 1개 | 1개 |
| RAID 6 (독립 배열) | 2배열 × 배열당 12개 | 각 120TB 합계 240TB | 없음 | 없음 |
12개씩 두 하위 그룹을 사용하면 RAID 50은 264TB, RAID 60은 240TB입니다. RAID 60을 6개씩 네 그룹으로 나누면 패리티에 쓰는 공간이 늘어 계산상 192TB가 됩니다.
11개씩 두 하위 그룹의 RAID 60은 216TB입니다. 핫스페어 한 개와 빈 베이 한 개를 남기는 대신 초기 저장 용량을 줄이는 배치입니다.
독립 RAID 6 배열 두 개와 RAID 60은 구분합니다. 각 12개 RAID 6을 별도 저장소로 운영하면 각각 120TB, 합계 240TB입니다. RAID 60은 하위 그룹 위에 스트라이핑을 적용하며, 한 하위 그룹의 허용 범위를 넘는 장애가 전체 RAID 60에 영향을 줄 수 있습니다.
독립 저장소로 나눠도 NAS 본체나 전원, 컨트롤러를 공유한다면 장비 장애까지 분리되는 것은 아닙니다. 합산 용량을 하나의 풀이나 볼륨에서 쓸 수 있는지는 별도 조건입니다.
QTS 5.2.x에서 새 RAID 50 또는 RAID 60 그룹을 풀에 추가하는 경우, 기존 풀과 같은 디스크 수 및 하위 그룹 수로 새 그룹을 만들어야 합니다. 기존 그룹의 하위 그룹에 디스크를 더하는 확장과는 다른 경로이며, 빈 베이 한 개로는 필요한 새 그룹을 만들 수 없습니다.
Synology RAID Group은 여러 배열을 LVM으로 결합하는 기능으로 RAID 50 또는 RAID 60과 구분합니다. DSM의 지원 모델에서는 풀 생성 시 배열별 최대 디스크 수를 정하며, 기존 배열이 설정한 최대 수에 도달해야 새 배열이 추가됩니다. 남은 슬롯 수와 함께 현재 배열별 장착 수를 대조합니다.
HDD AND SSD / SEPARATE POOLS
QNAP TS-h3087XU-RP의 3.5인치 24베이와 2.5인치 SSD용 6베이를 기준으로 한 신규 구성 가정입니다. HDD는 한 개당 12TB, SATA SSD는 한 개당 3.84TB로 계산하며 HDD 풀과 SSD 풀을 따로 구성합니다.
30베이라는 표기만으로 3.5인치 HDD 30개를 장착할 수 있다고 해석하지 않습니다. 표의 RAID 방식, 호환 디스크와 풀 구성은 설치된 QuTS hero 버전의 조건을 확인합니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| HDD RAID 60 + SSD RAID 1 | 12TB HDD: 2그룹 × 12개 3.84TB SSD: 2개 | HDD 240TB SSD 3.84TB | 없음 | SSD 4개 |
| HDD RAID 60 + SSD RAID 1 | 12TB HDD: 2그룹 × 11개 3.84TB SSD: 2개 | HDD 216TB SSD 3.84TB | HDD 1개 | HDD 1개 SSD 4개 |
| HDD RAID 60 + SSD RAID 10 | 12TB HDD: 2그룹 × 12개 3.84TB SSD: 6개 | HDD 240TB SSD 11.52TB | 없음 | 없음 |
HDD 24개를 RAID 60으로 구성하면 계산상 240TB입니다. SSD 두 개의 RAID 1은 별도 3.84TB이며, SSD 여섯 개의 RAID 10은 11.52TB입니다. 서로 다른 풀의 공간이므로 하나의 용량으로 합쳐 안내하지 않습니다.
HDD 22개와 HDD 핫스페어 한 개를 사용하면 216TB와 HDD 빈 베이 한 개를 남깁니다. 남은 SSD 베이는 별도 SSD 풀 확장이나 다른 지원 용도로 검토하며 HDD 추가 슬롯을 대신하지 않습니다.
HDD RAID 60은 하위 RAID 6 그룹별 장애 조건을 적용하고 SSD RAID 1 및 RAID 10은 해당 미러의 장애 조건을 적용합니다. SSD 풀을 시스템 및 앱에 사용할 경우 그 풀의 장애가 전체 서비스에 주는 영향도 확인합니다.
SSD를 캐시로 지정한다면 이 표의 SSD 저장 용량 계산을 적용하지 않습니다. 시스템 풀, 데이터 풀과 캐시 중 실제로 맡길 역할을 먼저 정합니다.
HDD와 SSD별로 빈 슬롯과 설치된 QuTS hero의 확장 경로를 대조합니다. HDD 풀의 용량이 부족하다면 HDD 교체 또는 확장 장치 구성을 검토하며, SSD 추가만으로 HDD 풀의 용량이 증가하지는 않습니다.
필요한 경우 해당 모델이 지원하는 확장 장치와 연결 카드를 확인하고, 장치 추가 뒤 기존 풀 확장과 별도 풀 생성 중 어떤 경로를 사용할지 정합니다.
STORAGE SERVER / ARRAY LAYOUT
동일한 12TB SAS 또는 SATA HDD를 사용하는 36베이 스토리지 서버의 계산 예시입니다. Supermicro SSG-641E-E1CR36H처럼 3.5인치 SAS/SATA 36베이를 제공하는 장비가 있으며, 실제 드라이브 유형은 장비와 컨트롤러의 호환 조건을 따릅니다.
아래는 각 배열을 독립 저장소로 운영하는 가정입니다. 실제 RAID 컨트롤러와 설치 OS가 배열 수, RAID 방식과 디스크 수를 지원하는지 확인합니다. 시스템용 드라이브가 데이터 베이를 사용하면 해당 슬롯을 계산에서 제외합니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| RAID 6 (독립 배열) | 12TB HDD 3배열 × 배열당 12개 | 각 120TB 합계 360TB | 없음 | 없음 |
| RAID 6 (독립 배열) | 12TB HDD 3배열 × 배열당 11개 | 각 108TB 합계 324TB | 3개 | 없음 |
| RAID 6 (독립 배열) | 12TB HDD 3배열 × 배열당 10개 | 각 96TB 합계 288TB | 3개 | 3개 |
| RAID 1+0 (RAID 10) (독립 배열) | 12TB HDD 3배열 × 배열당 12개 | 각 72TB 합계 216TB | 없음 | 없음 |
RAID 6을 12개씩 세 배열로 나누면 각각 120TB, 합계 360TB입니다. 11개씩 세 배열과 핫스페어 세 개는 각각 108TB, 합계 324TB이며 모든 베이를 사용합니다.
10개씩 세 배열과 핫스페어 세 개는 합계 288TB와 빈 베이 세 개를 남깁니다. RAID 10을 12개씩 세 배열로 나누면 합계 216TB이며 업무 입출력 특성과 미러 쌍별 장애 조건을 비교합니다.
독립 배열의 합산 용량과 하나의 풀 및 볼륨 용량을 구분합니다. 한 배열의 장애가 다른 배열의 데이터를 직접 손상시키지 않더라도 공통 컨트롤러, 전원과 서버 OS 장애는 함께 영향을 줄 수 있습니다.
핫스페어 세 개의 보호 범위를 각 배열 전용 또는 공용으로 지정할 수 있는지 컨트롤러와 OS에서 대조합니다. 전용이면 다른 배열에 예비 디스크가 남아도 자동으로 가져다 쓸 수 있다고 가정하지 않습니다. 소프트웨어 RAID는 HBA 등 실제 디스크 접근 방식도 설계에 포함합니다.
빈 베이 세 개를 각 배열에 하나씩 추가할 수 있는지는 컨트롤러와 OS의 확장 기능에 따라 다릅니다. 기존 배열 확장, 새 독립 배열 추가와 데이터 이전을 구분해 결정합니다.
HDD / SAS AND SATA SSD / NVMe SSD
48베이의 HDD, SAS/SATA SSD와 NVMe SSD 구성을 구분해 비교합니다. HDD는 한 개당 12TB, SAS/SATA SSD는 3.84TB, PAS7700의 NVMe SSD는 7.68TB를 사용하는 신규 구성 가정입니다. 매체별 인터페이스와 호환 조건이 달라 서로 같은 장비에 장착하는 예시로 해석하지 않습니다.
JetStor RDX48은 3.5인치 HDD 48개를 수용하는 서버이며, Supermicro SSG-2029P-E1CR48L은 2.5인치 SAS/SATA 48베이를 제공합니다. 앞 네 행은 해당 유형의 장비에서 독립 RAID 6 배열을 운영한다고 가정한 계산이며, 실제 컨트롤러와 OS 지원을 확인합니다.
PAS7700으로 표시한 세 행은 7.68TB U.3 NVMe SSD SPU7200D-7680G를 사용하는 가정입니다. 공식 호환 목록과 설치된 DSM Enterprise를 기준으로 적용합니다.
PAS7700 공식 사양의 지원 RAID는 RAID 5, RAID 6, RAID TP이며, PAS7700으로 표시한 세 행은 RAID 6 배열 배치를 비교합니다. 배열당 최대 24개 조건을 적용하고, 해당 세 행의 전체 용량은 두 컨트롤러에 배분되는 공간의 합계입니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| RAID 6 (독립 배열) | 12TB HDD 4배열 × 배열당 12개 | 각 120TB 합계 480TB | 없음 | 없음 |
| RAID 6 (독립 배열) | 12TB HDD 4배열 × 배열당 11개 | 각 108TB 합계 432TB | 4개 | 없음 |
| RAID 6 (독립 배열) | 3.84TB SAS/SATA SSD 4배열 × 배열당 12개 | 각 38.4TB 합계 153.6TB | 없음 | 없음 |
| RAID 6 (독립 배열) | 3.84TB SAS/SATA SSD 4배열 × 배열당 11개 | 각 34.56TB 합계 138.24TB | 4개 | 없음 |
| RAID 6 (PAS7700) | 7.68TB NVMe SSD 2배열 × 배열당 SSD 24개 | 전체 337.92TB 컨트롤러당 168.96TB | 없음 | 없음 |
| RAID 6 (PAS7700) | 7.68TB NVMe SSD 2배열 × 배열당 SSD 23개 | 전체 322.56TB 컨트롤러당 161.28TB | 2개 | 없음 |
| RAID 6 (PAS7700) | 7.68TB NVMe SSD 2배열 × 배열당 SSD 22개 | 전체 307.2TB 컨트롤러당 153.6TB | 2개 | 2개 |
HDD를 12개씩 네 배열로 구성하면 합계 480TB입니다. 11개씩 네 배열과 핫스페어 네 개는 합계 432TB입니다. 같은 배치를 3.84TB SSD에 적용하면 각각 합계 153.6TB와 138.24TB이며, 매체의 성능과 비용을 용량과 별도로 비교합니다.
PAS7700에서 24개씩 두 RAID 6 배열을 사용하면 계산상 전체 337.92TB이며 별도 핫스페어는 없습니다. 23개씩 두 배열과 핫스페어 두 개는 전체 322.56TB로, 예비 디스크를 확보하는 대신 저장 공간을 줄입니다.
22개씩 두 배열과 핫스페어 두 개는 전체 307.2TB와 빈 베이 두 개를 남깁니다. 이 값들은 패리티 공간만 반영한 상담용 계산이며 실제 사용 가능 공간은 더 작습니다.
HDD 및 SAS/SATA SSD 예시의 네 독립 배열은 RAID 60 하나를 구성한 것과 다릅니다. 배열마다 두 디스크 장애에 대응하며, 하나의 RAID 60으로 묶으려면 해당 컨트롤러와 OS의 지원 범위 및 전체 장애 영향도 다시 확인해야 합니다.
PAS7700의 Dual Pool은 용량을 두 컨트롤러에 절반씩 배분합니다. 하나의 볼륨은 한쪽 컨트롤러의 공간만 사용할 수 있으므로 전체 합계를 단일 볼륨의 용량으로 판단하지 않습니다.
PAS7700 공식 구성 가이드는 배열당 예비 디스크 한 개를 확보하도록 권장합니다. 따라서 예비 디스크가 없는 첫 PAS7700 행은 용량 비교용이며, 권장 예비 디스크 배치를 충족하지 않습니다. RAID 6의 장애 허용 범위는 각 배열 기준이며 이중 컨트롤러도 이를 늘려주지는 않습니다.
HDD 및 SAS/SATA SSD 구성은 해당 서버의 컨트롤러, HBA, 백플레인과 OS가 지원하는 경로를 따릅니다. 매체만 SSD로 바꾸어도 기존 RAID에 디스크를 추가할 수 있는 방식이 자동으로 바뀌지는 않습니다.
PAS7700의 추가 SSD 배치는 DSM Enterprise에서 배열당 최대 24개와 실제 배치 결과를 대조합니다. 확장 후에도 필요한 볼륨을 한쪽 컨트롤러의 공간에 담을 수 있어야 하므로, 전체 합계와 컨트롤러별 용량을 각각 계산합니다.
HDD 장비의 디스크 교체나 RAID 50 및 RAID 60 절차를 PAS7700에 그대로 적용하지 않습니다. 실제 볼륨 크기는 모델 및 메모리 조건의 단일 볼륨 한도 안에서 정합니다.
HIGH DENSITY / DATA BAYS
Synology HD6500의 데이터용 60베이를 기준으로 한 신규 구성 가정입니다. HDD 행은 동일한 12TB SAS HDD, SSD 행은 동일한 3.84TB SATA SSD를 사용합니다. SATA SSD 장착에는 별도 2.5인치 트레이와 공식 호환 조건을 확인합니다.
별도 시스템용 SATA SSD 두 개는 데이터용 60베이와 표의 용량에 포함하지 않습니다. 아래는 배열마다 별도 풀을 만드는 가정이며, 표의 합계를 단일 풀 또는 볼륨 용량으로 해석하지 않습니다.
| RAID 방식 | 디스크 배치 | 계산상 용량 | 핫스페어 | 빈 베이 |
|---|---|---|---|---|
| RAID 6 (독립 배열) | 12TB SAS HDD 3배열 × 배열당 20개 | 각 216TB 합계 648TB | 없음 | 없음 |
| RAID 6 (독립 배열) | 12TB SAS HDD 3배열 × 배열당 19개 | 각 204TB 합계 612TB | 3개 | 없음 |
| RAID 6 (독립 배열) | 12TB SAS HDD 3배열 × 배열당 18개 | 각 192TB 합계 576TB | 3개 | 3개 |
| RAID 6 (독립 배열) | 12TB SAS HDD 5배열 × 배열당 12개 | 각 120TB 합계 600TB | 없음 | 없음 |
| RAID 6 (독립 배열) | 3.84TB SATA SSD 3배열 × 배열당 20개 | 각 69.12TB 합계 207.36TB | 없음 | 없음 |
20개 RAID 6 배열 세 개는 각각 216TB, 합계 648TB입니다. 19개씩 세 배열과 핫스페어 세 개는 합계 612TB이며 빈 베이는 없습니다. 18개씩 세 배열과 핫스페어 세 개는 합계 576TB와 빈 베이 세 개를 남깁니다.
12개씩 다섯 배열로 나누면 합계 600TB입니다. 배열을 더 작게 나누는 대신 패리티에 쓰는 공간이 늘어납니다. 동일한 20개씩 세 배열에 3.84TB SATA SSD를 사용하면 합계 207.36TB입니다.
RAID 6의 두 디스크 장애 허용 조건은 각 배열에 적용합니다. 한 배열에 장애가 집중되면 다른 배열에 여유가 있어도 그 배열의 보호 한도를 대신할 수 없습니다.
이 표는 배열마다 별도 풀을 구성합니다. 여러 배열을 하나의 Synology RAID Group으로 만들 경우에는 생성 시 정한 배열별 최대 수와 새 배열 추가 조건이 적용됩니다. 예를 들어 최대 20개로 정했다면 기존 배열이 20개에 도달한 뒤 새 배열을 추가하므로, 표의 19개씩 세 독립 풀 배치를 그대로 재현하는 경로로 보지 않습니다.
HD6500은 RX6025sas 네 대를 연결해 데이터 베이를 최대 300개까지 확장할 수 있습니다. 본체와 확장 장치별 배열 및 풀 배치를 먼저 정한 뒤 각 풀의 용량과 볼륨 한도를 계산합니다. 전체 연결 한도는 한 RAID 또는 볼륨의 디스크 수를 뜻하지 않습니다.
예비 디스크와 교체 절차, 재구축 중 서비스 부하, 본체 및 확장 장치의 공통 장애 범위까지 함께 계획합니다.
EXPANSION UNITS / PHYSICAL BAY COUNT
아래 숫자는 본체와 확장 장치를 합친 물리 슬롯 수입니다. 실제 장착된 디스크 수, RAID 참여 수와 파일 저장 용량은 별도로 계산합니다. 각 모델의 공식 지원 장치와 최대 연결 수를 기준으로 하며 시스템용 드라이브는 제외합니다.
HD6500과 PAS7700은 매체와 운영체제, 확장 방식이 다릅니다. 연결 가능한 베이가 늘어나도 모든 디스크를 하나의 RAID 또는 볼륨으로 사용할 수 있다는 의미는 아닙니다.
| 본체 모델 | 확장 장치 | 베이 계산 | 전체 베이 | 수량 |
|---|---|---|---|---|
| HD6500 | RX6025sas | 60 + 60 × 1 | 120베이 | 1대 |
| HD6500 | RX6025sas | 60 + 60 × 2 | 180베이 | 2대 |
| HD6500 | RX6025sas | 60 + 60 × 3 | 240베이 | 3대 |
| HD6500 | RX6025sas | 60 + 60 × 4 | 300베이 | 4대 |
| PAS7700 | PAX224 | 48 + 24 × 1 | 72베이 | 1대 |
| PAS7700 | PAX224 | 48 + 24 × 7 | 216베이 | 7대 |
확장 장치마다 독립 풀을 구성하는 방법과 지원되는 기존 풀 확장을 비교합니다. 장치 하나가 연결 해제됐을 때 영향을 받는 배열, 풀과 서비스를 먼저 식별합니다.
서로 다른 장치의 RAID 6 배열을 별도 저장소로 운영한다면 각각의 용량과 장애 조건을 기록합니다. 하나의 풀로 묶는 기능을 사용하면 배열별 한도와 전체 풀의 장애 영향까지 함께 확인합니다.
정확한 본체 모델, OS 버전, 확장 장치, 연결 카드 및 케이블 조합을 확인합니다. 인터페이스 모양이나 같은 제조사라는 이유만으로 연결을 지원한다고 판단하지 않습니다.
확장 연결 대역폭, 공유되는 경로, 전원과 냉각, 랙 공간 및 유지보수 접근을 함께 확인합니다. 예비 경로나 전원이 있어도 실제 배선과 설정이 그 이점을 사용하는지 검증합니다.
현재 장착 수, 다음에 추가할 디스크 수와 목표 시점을 장치별로 기록합니다. 지원 최대 베이 수를 처음부터 모두 채울 필요는 없으며, 필요한 실제 사용 가능 용량과 복원 목표에 맞춰 증설 단위를 정합니다.
추가 장치 연결, 드라이브 편입, 배열 및 풀 확장, 볼륨 확장과 서비스 검증을 구분합니다. 변경 전 별도 백업을 확보하고 작업 후 실제 용량과 데이터 접근을 확인합니다.
핫스페어는 개수와 보호 범위를 함께 정합니다. 장비에 따라 특정 RAID 그룹 전용 또는 여러 그룹이 공유하는 예비 디스크로 지정할 수 있습니다. QTS 5.2.x의 공용 예비 디스크는 같은 인클로저 안의 그룹을 대상으로 하므로, NAS 본체와 확장 장치 전체에서 공동으로 쓴다고 해석하지 않습니다.
핫스페어 두 개 이상이나 RAID 10용 핫스페어도 지원 환경에서 구성할 수 있습니다. QTS 5.2.x의 그룹 핫스페어 절차는 복수 디스크 선택을 안내하며, DSM은 RAID 10을 핫스페어 보호 대상으로 명시합니다. 적용 전에는 지정 가능한 개수, 디스크 용량과 유형, 보호 대상 풀 또는 그룹을 확인합니다.
핫스페어는 재구축에 사용할 예비 디스크이며 RAID 자체의 장애 허용 수를 늘리지 않습니다. 동시에 여러 장애가 발생했을 때의 선택 순서와 재구축 방식은 OS 및 컨트롤러 조건에 따릅니다. 한 디스크가 재구축에 편입된 뒤 남은 예비 수와 보충 시점까지 정합니다.
03 / CAPACITY AND PROTECTION
보관할 데이터의 종류와 저장 위치를 나누고, 증가량과 보호에 필요한 공간을 더해 용량 예산을 정합니다. 계산한 예산이 실제 가용 용량과 복원 목표를 충족하는지 함께 판단합니다.
03A / INPUTS
측정 대상, 기준 시점과 저장 위치를 함께 적습니다. 원본 NAS와 별도 백업 장비의 용량 예산은 따로 계산합니다.
| 측정 대상 | 저장 위치와 용량 예산에 반영할 내용 |
|---|---|
| 현재 파일과 업무 데이터 | 원본 NAS에 보관할 파일과 업무 데이터의 범위, 현재 용량과 측정 시점을 기록합니다. |
| 앱 및 패키지 데이터 | NAS 내부의 앱 데이터, 데이터베이스와 인덱스 등이 파일 용량에 포함됐는지 구분합니다. 별도 사용량은 해당 풀 또는 볼륨의 예산에 추가합니다. |
| 계획 기간의 증가량 | 연간 증가량과 운영 기간으로 추가 용량을 산정하고, 데이터가 늘어날 저장소에 반영합니다. |
| 파일 버전과 스냅샷 | 보존 기간과 변경량으로 예상 사용량을 잡습니다. 원본 NAS 내부에 보관하는 공간과 다른 장비로 복제하는 공간을 나눕니다. |
| 운영 여유 | 데이터와 버전 등을 보관한 뒤에도 비워둘 공간입니다. 운영할 풀 또는 볼륨별로 기준을 정합니다. |
| 별도 백업 저장공간 | 별도 장비에 보관하는 백업은 그 장비의 예산으로 계산합니다. 이 NAS가 PC나 서버의 백업 저장소라면 해당 백업 데이터는 이 NAS의 예산에 포함합니다. |
| 기존 풀 또는 볼륨 사용량 | 파일 외의 앱 데이터, 버전이나 예약 공간 등이 포함됐는지 확인합니다. 표시된 사용량을 그대로 이전할 데이터량으로 보지 않습니다. |
03B / CALCULATION
기존 HDD 및 SSD 구성 사례 16개를 바탕으로 필요한 용량과 구성 후보를 비교합니다. 실제 고객의 측정 결과가 아닌 상담용 가정이며, 새로 보완한 버전 보관량과 임시 공간은 각 사례의 산출 조건에 표시합니다. 고객의 사용 기록과 보관 정책에 맞춰 다시 산정합니다.
OFFICE FILE SHARING
현재 8TB, 연간 증가량 2TB, 운영 기간 4년, 동시 사용자 5명과 2.5GbE를 가정합니다. 증가량 2TB는 측정값이 아닙니다. 상담에서는 사용량 기록과 신규 업무 계획을 기준으로 조정합니다. 사용자 수와 네트워크 속도는 성능 검토 조건이며 용량 계산의 배수로 사용하지 않습니다.
원본 NAS의 파일 및 업무 데이터와 버전 보관 공간을 계산합니다. 기존 사례의 버전 보관 2TB에는 이 분석에서 스냅샷 예상 사용량도 포함한다고 가정합니다. 별도 앱 및 패키지 데이터가 있으면 추가하며, 다른 백업 장비에 저장하는 사본의 공간은 그 장비에서 따로 산정합니다.
최종 공간의 20%를 비워두기 위해 18TB를 0.8로 나눕니다. 18TB에 20%를 단순 가산하는 계산이 아닙니다. 20%는 이 사례의 가정이며 모든 NAS에 적용하는 고정 기준은 아닙니다. 계산표의 합계와 운영 여유를 다시 더하지 않습니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 현재 파일 및 업무 데이터 | 현재 보관량 가정 | 8TB |
| 향후 증가량 | 연간 2TB × 4년 | 8TB |
| 버전 및 스냅샷 예상 사용량 | 이 사례에서 합계 2TB로 가정 | 2TB |
| 데이터 및 버전 합계 | 8TB + 8TB + 2TB | 18TB |
| 필요 용량 예산 | 18TB ÷ (1 − 0.2) | 22.5TB |
| 예산에 포함된 운영 여유 | 22.5TB − 18TB | 4.5TB |
운영 기간이 5년이면 필요 용량은 25TB입니다. 버전 및 스냅샷 2TB와 여유율 20%를 유지하면 (8 + 2 × 5 + 2) ÷ 0.8 = 25TB입니다. 계산상 24TB인 두 후보 모두 이 조건에서는 부족합니다.
버전 및 스냅샷 예상량이 4TB로 늘어도 필요 용량은 25TB입니다. 운영 기간 4년을 유지하면 (8 + 2 × 4 + 4) ÷ 0.8 = 25TB입니다. 각 예시는 한 조건만 바꾼 비교이며, 기간과 보관량이 함께 늘면 두 변경을 모두 반영합니다.
12TB HDD 3개, RAID 5: 계산상 24TB. (3 − 1) × 12TB이며 4베이에서 빈 베이 1개를 남깁니다. 정상 상태에서 디스크 1개 장애에 대응합니다. 빈 베이를 통한 기존 RAID 확장은 모델과 OS의 지원 조건에 따릅니다.
12TB HDD 4개, RAID 6: 계산상 24TB. (4 − 2) × 12TB이며 4베이를 모두 사용합니다. 정상 상태에서 디스크 2개 장애에 대응합니다. 빈 베이가 필요하면 더 많은 베이의 장비를 비교합니다.
두 후보는 동일 용량 HDD를 사용하는 지원 모델의 신규 구성 예시입니다. 기존 RAID의 온라인 변경 절차를 뜻하지 않으며, 성능과 업무 중단 및 백업 복원 조건은 별도로 검토합니다.
운영 여유의 포함 범위: 운영 여유 4.5TB는 이미 필요 용량 22.5TB에 포함되어 있습니다. 계산상 24TB와의 차이 1.5TB를 운영 여유 전체로 해석하지 않습니다.
실제 가용 용량과 예약 공간: 같은 단위와 저장 범위에서 데이터, 버전 및 스냅샷, 운영 여유에 배분할 총용량을 비교합니다. 현재 남은 빈 공간과 구분하고 시스템 및 파일시스템 공간의 반영 여부, 예약 공간의 중복 계산과 풀 및 볼륨 한도를 확인합니다. 미사용 스냅샷 예약 공간을 일반 데이터의 운영 여유로 잡지 않습니다.
예산을 충족하지 못할 때: 더 큰 디스크, 다른 배치 또는 저장소 분리를 비교합니다. 운영 여유를 임의로 줄여 구성에 맞추지 않습니다.
서비스와 데이터 보호: 파일 잠금과 권한, 별도 백업 및 복원 시험은 기존 구성 사례와 함께 확인합니다.
HOME STORAGE
현재 2TB, 연간 증가량 0.5TB, 4년 후 예상 4TB. 가족 3명이 1GbE 또는 같은 네트워크의 Wi-Fi로 접속하는 환경을 가정합니다.
버전 및 스냅샷 합계 0.5TB를 추가 가정합니다. 휴대전화와 PC에 남긴 사본을 NAS 사용량에 다시 더하지 않으며, 같은 사진을 NAS의 다른 폴더에 별도로 복사하면 그 사용분은 포함합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 현재 파일과 사진 | 기존 사례의 현재 보관량 | 2TB |
| 계획 기간 증가량 | 연간 0.5TB × 4년 | 2TB |
| 버전 및 스냅샷 | 분석용 추가 가정: 합계 0.5TB | 0.5TB |
| 예산에 반영할 사용량 합계 | 2TB + 2TB + 0.5TB | 4.5TB |
| 필요 용량 예산 | 4.5TB ÷ (1 − 0.2) | 5.625TB |
| 예산에 포함된 운영 여유 | 5.625TB − 4.5TB | 1.125TB |
연간 증가량이 1TB가 되면 필요 용량은 8.125TB입니다. (2 + 1 × 4 + 0.5) ÷ 0.8 = 8.125TB. 기존 후보의 계산상 8TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
버전 보관량이 2TB가 되면 필요 용량은 7.5TB입니다. (2 + 0.5 × 4 + 2) ÷ 0.8 = 7.5TB. 계산상 8TB보다 0.5TB 작지만, 그 차이를 실제 가용 공간으로 확정하지 않습니다.
8TB HDD 2개, RAID 1, 계산상 8TB. 2베이 중 2개를 사용하며 여유 베이는 없습니다. 버전 보관량과 운영 여유를 제외한 공간이 예상 데이터 4TB를 수용하는지 확인합니다.
계산상 용량과 필요 용량의 비교 차이는 2.375TB입니다. 운영 여유 1.125TB는 이미 5.625TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
포함 범위: 사진 원본 외에 NAS가 만드는 미리보기와 앱 데이터가 0.5TB 예산에 포함됐는지 확인합니다. 별도 사용량이 있으면 더합니다.
확장 조건: 2베이를 모두 쓰는 RAID 1 후보이므로 빈 슬롯 추가 방식은 사용할 수 없습니다. 용량 교체 확장 지원과 이전 방법을 함께 정합니다.
보호 계획: 삭제 이력의 보관 기간과 가족별 권한을 정하고, NAS 밖의 사본으로 필요한 사진을 복원해 봅니다.
PHOTO ORIGINALS
현재 원본 8TB, 연간 2TB 증가, 4년 후 16TB. 동시 사용자 3명과 2.5GbE를 가정하며 편집용 임시 파일은 작업 컴퓨터에 둡니다.
NAS 내부 미리보기 및 앱 데이터 0.5TB, 버전 및 스냅샷 합계 2TB를 추가 가정합니다. 작업 컴퓨터에 두는 편집용 임시 파일과 카탈로그는 이 NAS 예산에서 제외합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 현재 사진 원본 | 기존 보관량 | 8TB |
| 향후 원본 증가량 | 연간 2TB × 4년 | 8TB |
| 미리보기 및 앱 데이터 | 분석용 추가 가정 | 0.5TB |
| 버전 및 스냅샷 | 분석용 추가 가정: 합계 2TB | 2TB |
| 예산에 반영할 사용량 합계 | 8TB + 8TB + 0.5TB + 2TB | 18.5TB |
| 필요 용량 예산 | 18.5TB ÷ (1 − 0.2) | 23.125TB |
| 예산에 포함된 운영 여유 | 23.125TB − 18.5TB | 4.625TB |
미리보기 및 앱 데이터가 1.5TB가 되면 필요 용량은 24.375TB입니다. (8 + 2 × 4 + 1.5 + 2) ÷ 0.8 = 24.375TB. 기존 후보의 계산상 24TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
연간 원본 증가량이 3TB가 되면 필요 용량은 28.125TB입니다. (8 + 3 × 4 + 0.5 + 2) ÷ 0.8 = 28.125TB. 기존 후보의 계산상 24TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
12TB HDD 3개, RAID 5, (3 − 1) × 12TB = 24TB. 4베이 중 3개 사용, 여유 1개입니다. 미리보기 파일, 버전과 운영 여유를 고려해 실제 용량을 다시 산정합니다.
계산상 용량과 필요 용량의 비교 차이는 0.875TB입니다. 운영 여유 4.625TB는 이미 23.125TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
생성 데이터: 썸네일, 색인과 버전 보관량을 사진 개수 및 실제 변경량과 대조합니다. 원본 용량과 같은 비율로 증가한다고 단정하지 않습니다.
예산 여유: 계산상 24TB와의 작은 차이를 실제 여유로 확정하지 않습니다. 시스템 및 파일시스템 공간을 반영한 같은 범위의 용량으로 비교합니다.
자료 보존: 원본과 카탈로그의 저장 위치를 기록하고, 다시 촬영할 수 없는 원본은 별도 장치나 위치에도 보관합니다.
VIDEO STORAGE
현재 12TB, 연간 4TB 증가, 3년 후 24TB. 동시 사용자 2명, 2.5GbE 환경에서 원본을 작업 컴퓨터로 복사한 뒤 사용하는 경우입니다.
버전과 NAS 내부 부가 데이터의 합계 2TB를 추가 가정합니다. 작업 컴퓨터로 복사해 편집하는 공간과 별도 백업 장비의 공간은 각각 따로 산정합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 현재 보관 영상 | 기존 보관량 | 12TB |
| 향후 영상 증가량 | 연간 4TB × 3년 | 12TB |
| 버전 및 부가 데이터 | 분석용 추가 가정 | 2TB |
| 예산에 반영할 사용량 합계 | 12TB + 12TB + 2TB | 26TB |
| 필요 용량 예산 | 26TB ÷ (1 − 0.2) | 32.5TB |
| 예산에 포함된 운영 여유 | 32.5TB − 26TB | 6.5TB |
운영 기간이 4년이 되면 필요 용량은 37.5TB입니다. (12 + 4 × 4 + 2) ÷ 0.8 = 37.5TB. 기존 후보의 계산상 36TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
연간 증가량이 6TB가 되면 필요 용량은 40TB입니다. (12 + 6 × 3 + 2) ÷ 0.8 = 40TB. 기존 후보의 계산상 36TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
12TB HDD 4개, RAID 5, (4 − 1) × 12TB = 36TB. 6베이 중 4개 사용, 여유 2개입니다. 예상 데이터 24TB 외에 버전 보관과 운영 공간이 확보되는지 확인합니다.
계산상 용량과 필요 용량의 비교 차이는 3.5TB입니다. 운영 여유 6.5TB는 이미 32.5TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
중복 사본: 원본, 납품본과 별도 인코딩본을 모두 NAS에 보관한다면 서로 다른 저장분을 각각 반영합니다.
다음 확장: 기존 후보의 빈 베이 2개와 RAID 확장 지원은 별개입니다. 목표 기간이 늘면 추가 디스크 조건과 이전 필요 여부를 검토합니다.
전송 및 복원: 필요한 기간의 데이터를 수용하는지와, 실제 복사 및 백업 복원이 업무 시간 안에 가능한지를 각각 판단합니다.
VIDEO EDITING
활성 작업 데이터 4TB, 편집자 2명, NAS부터 스위치와 작업 컴퓨터까지 10GbE가 연결된 환경을 가정합니다. 완성 영상과 백업은 별도 공간에 보관합니다.
활성 작업 데이터 4TB와 중복되지 않는 NAS 프록시 1TB, NAS에서 실제 생성하는 임시 작업분 0.5TB를 추가 가정합니다. 프로그램이 작업 컴퓨터에 두도록 하는 캐시와, 별도 보관소로 옮긴 완료 영상 및 백업은 제외합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 활성 작업 데이터 | 기존 사례의 원본 및 작업 데이터 | 4TB |
| NAS에 보관할 프록시 | 분석용 추가 가정 | 1TB |
| NAS 내부 임시 작업분 | 분석용 추가 가정: 최대 동시 사용량 | 0.5TB |
| 예산에 반영할 사용량 합계 | 4TB + 1TB + 0.5TB | 5.5TB |
| 필요 용량 예산 | 5.5TB ÷ (1 − 0.2) | 6.875TB |
| 예산에 포함된 운영 여유 | 6.875TB − 5.5TB | 1.375TB |
동시 활성 작업 데이터가 6TB가 되면 필요 용량은 9.375TB입니다. (6 + 1 + 0.5) ÷ 0.8 = 9.375TB. 기존 후보의 계산상 8TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
프록시 보관량이 2TB가 되면 필요 용량은 8.125TB입니다. (4 + 2 + 0.5) ÷ 0.8 = 8.125TB. 기존 후보의 계산상 8TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
4TB SATA SSD 4개, RAID 10, 4 × 4TB ÷ 2 = 8TB. SATA SSD 저장소를 지원하는 6베이 중 4개 사용, 여유 2개입니다. 프록시는 NAS에 보관하는 경우 NAS 필요 용량에 포함합니다. 미디어 캐시와 캐시 데이터베이스의 위치는 프로그램 기준을 따릅니다. Premiere Productions에서는 각 작업 컴퓨터의 부팅 드라이브 또는 직접 연결된 별도 SSD에 둡니다.
계산상 용량과 필요 용량의 비교 차이는 1.125TB입니다. 운영 여유 1.375TB는 이미 6.875TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
최대 점유량: 원본 가져오기, 프록시 생성과 완료 자료 이전이 겹치는 시점의 사용량을 기준으로 봅니다. 단순 연간 증가량을 적용하는 장기 보관 사례와 구분합니다.
저장 위치: 임시 파일이 기존 4TB에 이미 포함됐으면 다시 더하지 않습니다. 작업용 스냅샷을 추가로 보관하면 그 증가분을 별도로 반영합니다.
편집 성능: 필요 용량 충족만으로 동시 편집 성능을 확정하지 않습니다. 기존 사례의 코덱, 스트림 수와 실제 10GbE 경로 조건으로 시험합니다.
DESIGN AND CAD
활성 프로젝트와 계획 기간 증가량을 합해 2TB, 동시 작업자 4명, 2.5GbE를 가정합니다. 완료 프로젝트는 별도 보관 저장소로 옮기는 방식입니다.
기존 2TB는 활성 프로젝트와 계획 기간 증가량을 이미 합한 값입니다. 버전 및 스냅샷 0.5TB와 NAS 내부 임시 파일 0.25TB만 추가 가정하며, 완료 자료를 옮기는 보관소의 예산은 분리합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 계획 기간의 활성 프로젝트 | 기존 사례: 현재와 증가량을 포함 | 2TB |
| 프로젝트 버전 및 스냅샷 | 분석용 추가 가정 | 0.5TB |
| NAS 내부 임시 파일 | 기존 프로젝트 용량 밖의 추가 가정 | 0.25TB |
| 예산에 반영할 사용량 합계 | 2TB + 0.5TB + 0.25TB | 2.75TB |
| 필요 용량 예산 | 2.75TB ÷ (1 − 0.2) | 3.4375TB |
| 예산에 포함된 운영 여유 | 3.4375TB − 2.75TB | 0.6875TB |
활성 프로젝트 예산이 3TB가 되면 필요 용량은 4.6875TB입니다. (3 + 0.5 + 0.25) ÷ 0.8 = 4.6875TB. 기존 후보의 계산상 4TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
버전 및 스냅샷이 1TB가 되면 필요 용량은 4.0625TB입니다. (2 + 1 + 0.25) ÷ 0.8 = 4.0625TB. 기존 후보의 계산상 4TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
4TB SATA SSD 2개, RAID 1, 계산상 4TB. SATA SSD 저장소를 지원하는 4베이 중 2개 사용, 여유 2개입니다. 프로젝트 버전과 운영 여유는 이 공간 안에서 따로 산정합니다.
계산상 용량과 필요 용량의 비교 차이는 0.5625TB입니다. 운영 여유 0.6875TB는 이미 3.4375TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
계산 범위: 계획 기간 증가량이 포함된 2TB에 같은 증가량을 다시 더하지 않습니다. 참조 파일과 프로젝트별 복사본은 실제 저장 위치를 확인합니다.
공동 작업: 용량이 충분해도 파일 잠금과 참조 경로가 맞지 않으면 공동 작업이 성립하지 않습니다. 프로그램이 지원하는 방식으로 확인합니다.
완료 자료 이전: 완료 시점에 자료가 옮겨진다는 가정이 지연되면 활성 저장소 사용량이 늘어납니다. 이전 주기와 별도 보관소의 예산을 함께 정합니다.
PC BACKUP
PC 10대의 백업 원본 합계 8TB, 변경 이력과 보존 기간을 반영한 예상 백업 보관량 16TB. 동시 백업 2개와 NAS 측 2.5GbE를 가정하며 압축과 중복 제거 효과는 미리 차감하지 않습니다.
기존 16TB에는 원본 8TB를 백업한 공간과 변경 이력이 포함되어 있습니다. 이번 분석은 그 보관분을 지우기 전에 압축 및 중복 제거 없이 8TB 전체 백업 한 번을 별도 생성하는 상황을 추가 가정합니다. 원본을 중복 합산하는 것이 아니라 실제로 동시에 존재할 추가 사본을 더합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 정책상 백업 보관량 | 기존 사례: 원본 8TB와 이력 포함 | 16TB |
| 추가 전체 백업 한 번 | 분석용 추가 가정: 별도 8TB 사본 동시 유지 | 8TB |
| 예산에 반영할 사용량 합계 | 16TB + 8TB | 24TB |
| 필요 용량 예산 | 24TB ÷ (1 − 0.2) | 30TB |
| 예산에 포함된 운영 여유 | 30TB − 24TB | 6TB |
추가 전체 백업을 이 저장소에 중복 생성하지 않는 정책이라면 필요 용량은 20TB입니다. 16 ÷ 0.8 = 20TB. 계산상 24TB보다 4TB 작지만, 그 차이를 실제 가용 공간으로 확정하지 않습니다.
정책상 보관량 자체가 20TB로 늘면 필요 용량은 35TB입니다. (20 + 8) ÷ 0.8 = 35TB. 기존 후보의 계산상 24TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
12TB HDD 3개, RAID 5, (3 − 1) × 12TB = 24TB. 4베이 중 3개 사용, 여유 1개입니다. 백업 정리 작업과 운영 여유를 고려해 보관량 상한을 설정합니다.
이번 산출 조건에서는 기존 후보가 부족합니다. 필요 용량 30TB가 계산상 24TB보다 큽니다. 원래 사례의 후보를 바꿔 적지 않고, 추가로 가정한 보관 및 작업 조건이 기존 후보에 미치는 영향을 구분합니다.
추가 사본의 발생 여부: 실제 백업 방식과 작업 기록으로 추가 전체 백업의 공간을 확인합니다. 기존 16TB 예산에 이미 포함됐다면 8TB를 다시 더하지 않습니다.
작업 중 최대 사용량: 이 계산은 추가 전체 사본 한 번을 모델링한 값입니다. 체인 변환, 병합과 복원 시험의 별도 작업공간이 더 필요한 방식이면 추가 산정합니다.
구성 재검토: 기존 24TB 후보는 이번 30TB 가정을 충족하지 못합니다. 보관 정책과 별도 작업 저장소 또는 더 큰 구성을 비교하며 필요한 복원 시점을 임의로 줄이지 않습니다.
검증: PC별 백업 완료, 실패 재시도와 파일 복원을 확인하고 NAS 장애에 대비한 다른 위치의 사본을 준비합니다.
SERVER AND VM BACKUP
원본 12TB, 변경 이력과 보존 정책을 반영한 예상 백업 보관량 24TB. 동시 백업 작업 2개와 NAS 측 10GbE를 가정합니다. 원본 서버의 연결 속도도 별도로 확인합니다.
기존 24TB 보관량에 원본 12TB를 다시 더하는 계산이 아닙니다. 기존 백업을 유지한 채 압축 및 중복 제거 없이 별도 전체 사본 12TB를 한 번 더 생성하는 상황을 추가 가정합니다. 원본 서버의 운영 저장소는 별도 예산입니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 정책상 백업 보관량 | 기존 사례: 원본 12TB와 이력 포함 | 24TB |
| 추가 전체 백업 한 번 | 분석용 추가 가정: 별도 12TB 사본 동시 유지 | 12TB |
| 예산에 반영할 사용량 합계 | 24TB + 12TB | 36TB |
| 필요 용량 예산 | 36TB ÷ (1 − 0.2) | 45TB |
| 예산에 포함된 운영 여유 | 45TB − 36TB | 9TB |
추가 전체 사본을 이 저장소에 만들지 않는 정책이라면 필요 용량은 30TB입니다. 24 ÷ 0.8 = 30TB. 계산상 36TB보다 6TB 작지만, 그 차이를 실제 가용 공간으로 확정하지 않습니다.
정책상 보관량이 30TB로 늘면 필요 용량은 52.5TB입니다. (30 + 12) ÷ 0.8 = 52.5TB. 기존 후보의 계산상 36TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
12TB HDD 4개, RAID 5, (4 − 1) × 12TB = 36TB. 6베이 중 4개 사용, 여유 2개입니다. 도입 시 비교할 대안은 12TB HDD 5개, RAID 6, (5 − 2) × 12TB = 36TB입니다. 이 경우 6베이 중 5개 사용, 여유 1개이며 기존 RAID의 변경 절차를 안내하는 예시는 아닙니다. 압축 효과를 미리 차감하지 않고 실제 백업 증가량으로 보관 정책을 조정합니다.
이번 산출 조건에서는 기존 후보가 부족합니다. 필요 용량 45TB가 계산상 36TB보다 큽니다. 원래 사례의 후보를 바꿔 적지 않고, 추가로 가정한 보관 및 작업 조건이 기존 후보에 미치는 영향을 구분합니다.
백업 방식별 공간: 추가 전체 백업, 합성 전체 백업과 체인 변환의 공간은 같은 값으로 취급하지 않습니다. 사용하는 도구의 방식과 실제 작업 최대치를 기준으로 산정합니다.
작업공간의 추가 반영: 45TB는 추가 12TB 사본 한 번과 운영 여유를 반영한 예산입니다. 별도 변환 및 복원 작업공간이 필요하면 더해야 합니다.
구성 재검토: 기존 RAID 5와 RAID 6 후보는 모두 계산상 36TB이므로 이번 가정에서는 부족합니다. 보관 정책을 유지할 저장공간과 추가 전체 백업의 생성 위치를 함께 재설계합니다.
복원 목표: 업무 앱의 일관성, 전체 복원에 필요한 시간과 네트워크 경로를 실제 복원 시험으로 확인합니다.
VIRTUAL MACHINE OPERATIONS
가상 디스크의 예상 실제 사용량 합계 2TB, 동시 VM 3개, 클라이언트 연결 2.5GbE를 가정합니다. VM 개수는 부하를 보장하는 기준이 아니며 각 VM의 작업을 따로 확인합니다.
VM 스냅샷 0.5TB와 가상 디스크 밖에서 NAS가 사용하는 임시 공간 0.25TB를 추가 가정합니다. 게스트 OS 내부의 임시 파일이 기존 2TB에 포함돼 있으면 다시 더하지 않습니다. VM 세 개라는 개수 자체로 같은 용량을 세 번 곱하지 않습니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 가상 디스크 예상 실제 사용량 | 기존 사례의 VM 3개 합계 | 2TB |
| VM 스냅샷 보관분 | 분석용 추가 가정 | 0.5TB |
| 가상 디스크 밖의 NAS 임시 공간 | 분석용 추가 가정 | 0.25TB |
| 예산에 반영할 사용량 합계 | 2TB + 0.5TB + 0.25TB | 2.75TB |
| 필요 용량 예산 | 2.75TB ÷ (1 − 0.2) | 3.4375TB |
| 예산에 포함된 운영 여유 | 3.4375TB − 2.75TB | 0.6875TB |
가상 디스크 실제 사용량이 3TB까지 늘면 필요 용량은 4.6875TB입니다. (3 + 0.5 + 0.25) ÷ 0.8 = 4.6875TB. 기존 후보의 계산상 4TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
스냅샷 보관분이 1TB가 되면 필요 용량은 4.0625TB입니다. (2 + 1 + 0.25) ÷ 0.8 = 4.0625TB. 기존 후보의 계산상 4TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
4TB SATA SSD 2개, RAID 1, 계산상 4TB. SATA SSD 저장소를 지원하는 4베이 중 2개 사용, 여유 2개입니다. VM 스냅샷, 임시 파일과 운영 공간을 별도로 고려합니다.
계산상 용량과 필요 용량의 비교 차이는 0.5625TB입니다. 운영 여유 0.6875TB는 이미 3.4375TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
할당량과 사용량: 동적 할당 환경의 예상 사용량 예산입니다. 공간을 미리 확보하는 방식이나 할당 상한까지 보장해야 하는 조건이면 그 확보량을 기준으로 다시 계산합니다.
스냅샷 관리: 스냅샷 개수만으로 사용량을 계산하지 않습니다. 실제 변경량, 유지 기간과 정리 중의 최대 사용량을 확인합니다.
운영 및 복원: CPU와 메모리, 저장소 응답시간은 용량과 별도 검증합니다. 같은 NAS의 스냅샷 외에 다른 장치의 백업에서 VM을 복원해 봅니다.
DATABASE AND APPLICATIONS
계획 기간 말의 활성 데이터 2TB, 로그와 임시 공간 1TB, 동시 접속 10명과 서버 연결 10GbE를 가정합니다. 이 예시는 외부 업무 서버가 프로그램에서 지원하는 방식으로 NAS 저장공간을 사용하는 환경입니다. 거래량, 쓰기 비중과 허용 응답시간은 별도 측정합니다.
기존 활성 데이터 2TB와 로그 및 임시 공간 1TB에 버전 및 스냅샷 합계 0.5TB를 추가 가정합니다. 별도 백업 저장소의 공간은 제외하며, 같은 NAS에 DB 백업을 보관한다면 별도 사용분을 추가합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 계획 기간 말 활성 데이터 | 기존 사례의 예상 데이터 | 2TB |
| 로그 및 임시 공간 | 기존 사례에서 별도로 잡은 사용량 | 1TB |
| 추가 버전 및 스냅샷 | 분석용 추가 가정 | 0.5TB |
| 예산에 반영할 사용량 합계 | 2TB + 1TB + 0.5TB | 3.5TB |
| 필요 용량 예산 | 3.5TB ÷ (1 − 0.2) | 4.375TB |
| 예산에 포함된 운영 여유 | 4.375TB − 3.5TB | 0.875TB |
로그 및 임시 공간이 4TB까지 증가하면 필요 용량은 8.125TB입니다. (2 + 4 + 0.5) ÷ 0.8 = 8.125TB. 기존 후보의 계산상 8TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
일시적인 정비 작업공간 2TB가 추가로 필요하면 필요 용량은 6.875TB입니다. (2 + 1 + 0.5 + 2) ÷ 0.8 = 6.875TB. 계산상 8TB보다 1.125TB 작지만, 그 차이를 실제 가용 공간으로 확정하지 않습니다.
4TB SATA SSD 4개, RAID 10, 4 × 4TB ÷ 2 = 8TB. SATA SSD 저장소를 지원하는 6베이 중 4개 사용, 여유 2개입니다. 버전과 운영 여유를 차감한 실제 공간을 확인합니다.
계산상 용량과 필요 용량의 비교 차이는 3.625TB입니다. 운영 여유 0.875TB는 이미 4.375TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
최대 점유량: 로그 보존, 대량 작업과 정비 중의 공간이 기존 1TB에 들어가는지 확인합니다. 평균 사용량만으로 최대치를 대신하지 않습니다.
데이터 일관성: 스냅샷을 보관했다는 사실만으로 DB 복원이 성립하지 않습니다. 프로그램에 맞는 일관성 확보와 DB 전용 복원 절차를 시험합니다.
성능과 전원: 실제 요청 크기와 쓰기 부하, SSD 전원 차단 보호 및 UPS 조건은 기존 구성 사례와 함께 점검합니다.
VIDEO SURVEILLANCE
카메라 8대, 대당 평균 4Mbps, 하루 24시간 연속 녹화, 30일 보관을 가정합니다. 영상 합계 32Mbps는 초당 4MB이며, 4MB × 86,400 × 30 = 10,368,000MB = 10.368TB로 약 10.37TB입니다. 오디오와 부가 데이터는 별도입니다.
영상 외 오디오 및 부가 데이터의 30일 합계 0.5TB를 추가 가정합니다. Mbps, MB와 TB는 십진수이며 8bit = 1byte로 환산합니다. 10.368TB는 4MB/s를 30일 유지한 영상량이며 10.37TB로 먼저 반올림해 계산하지 않습니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 30일 영상 녹화량 | 8대 × 4Mbps ÷ 8 × 86,400초 × 30일 ÷ 1,000,000 | 10.368TB |
| 오디오 및 부가 데이터 | 분석용 추가 가정: 30일 합계 | 0.5TB |
| 예산에 반영할 사용량 합계 | 10.368TB + 0.5TB | 10.868TB |
| 필요 용량 예산 | 10.868TB ÷ (1 − 0.2) | 13.585TB |
| 예산에 포함된 운영 여유 | 13.585TB − 10.868TB | 2.717TB |
동일 비트레이트로 45일 보관하면 필요 용량은 20.3775TB입니다. (15.552 + 0.75) ÷ 0.8 = 20.3775TB. 기존 후보의 계산상 16TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
30일 평균 비트레이트가 대당 5Mbps가 되면 필요 용량은 16.825TB입니다. (12.96 + 0.5) ÷ 0.8 = 16.825TB. 기존 후보의 계산상 16TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
8TB HDD 4개, RAID 6, (4 − 2) × 8TB = 16TB. 해당 RAID를 지원하는 6베이 중 4개 사용, 여유 2개입니다. 실제 녹화량과 운영 여유를 반영해 30일 보관이 가능한지 확인합니다.
계산상 용량과 필요 용량의 비교 차이는 2.415TB입니다. 운영 여유 2.717TB는 이미 13.585TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
변경 조건: 45일 예시는 영상량과 부가 데이터가 보관 일수에 비례한다고 가정합니다. 5Mbps 예시는 부가 데이터 0.5TB를 유지한 비교입니다. 두 조건을 동시에 바꾸면 함께 다시 계산합니다.
보관 가능 일수: 실제 녹화량, 저장공간 할당량과 자동 삭제 정책으로 목표 일수가 유지되는지 확인합니다. 단순 용량 계산이 녹화 처리 성능을 보장하지 않습니다.
별도 보존: 사건 영상의 별도 사본, 수동 보관과 다른 백업이 같은 저장소를 사용하면 그 공간을 더합니다. 필요한 보관 일수와 라이선스 조건은 기존 사례와 함께 확인합니다.
ARCHIVE AND REMOTE BACKUP
현재 16TB, 연간 2TB 증가, 4년 후 24TB. 동시 사용자 2명, 로컬 1GbE와 원격 업로드 100Mbps를 가정합니다. 파일 이력과 추가 사본의 용량은 별도로 산정합니다.
이 저장소에 남기는 파일 이력 및 추가 보관분 3TB를 추가 가정합니다. 다른 NAS에 저장하는 원격 사본의 공간은 그 장비의 예산으로 구분하고, 같은 자료를 서로 다른 폴더에 별도 저장하면 그 사용량은 포함합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 현재 보관 자료 | 기존 사례의 사용량 | 16TB |
| 계획 기간 증가량 | 연간 2TB × 4년 | 8TB |
| 파일 이력 및 추가 보관분 | 분석용 추가 가정 | 3TB |
| 예산에 반영할 사용량 합계 | 16TB + 8TB + 3TB | 27TB |
| 필요 용량 예산 | 27TB ÷ (1 − 0.2) | 33.75TB |
| 예산에 포함된 운영 여유 | 33.75TB − 27TB | 6.75TB |
운영 기간이 5년이 되면 필요 용량은 36.25TB입니다. (16 + 2 × 5 + 3) ÷ 0.8 = 36.25TB. 기존 후보의 계산상 36TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
추가 보관분이 6TB가 되면 필요 용량은 37.5TB입니다. (16 + 2 × 4 + 6) ÷ 0.8 = 37.5TB. 기존 후보의 계산상 36TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
12TB HDD 5개, RAID 6, (5 − 2) × 12TB = 36TB. 8베이 중 5개 사용, 여유 3개입니다. 계획 기간 말의 24TB 전체를 압축이나 중복 제거 없이 100Mbps로 전송하면 프로토콜 부하를 제외해도 이론상 약 22.2일이 필요합니다. 현재 16TB의 초기 전송과 장애 후 전체 복원 시간은 각각의 데이터량과 연결 경로로 계획합니다.
계산상 용량과 필요 용량의 비교 차이는 2.25TB입니다. 운영 여유 6.75TB는 이미 33.75TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
보관 범위: 장기 원본과 버전, 삭제된 자료의 보존 정책을 따로 정합니다. 보관 정책상 필요한 사본을 운영 여유라는 이름으로 제외하지 않습니다.
전송 계획: 기존 사례의 100Mbps는 용량 계산에 곱하는 값이 아닙니다. 초기 전송량, 이후 변경분과 전체 복원량의 전송 시간을 각각 계획합니다.
장기 검증: 정기 읽기와 무결성 검사, 실제 복원 시험, 암호화 키 보관 및 장비 교체 계획을 함께 관리합니다.
MEDIA SERVER AND STREAMING
현재 영상 6TB, 연간 증가량 2TB, 3년 후 예상 12TB. 동시 재생 2대, 원본 스트림당 평균 40Mbps와 NAS 유선 1GbE를 가정합니다. 영상 전송량 합계는 평균 80Mbps이며 순간 최대 비트레이트와 다른 통신에 필요한 여유는 별도로 봅니다.
미디어 정보와 썸네일 0.5TB, NAS 내부 변환 임시 공간 0.5TB를 추가 가정합니다. 동시 재생 두 대라는 이유로 전체 영상 라이브러리를 두 배로 잡지 않습니다. 별도 해상도의 변환본을 계속 보관한다면 그 용량은 추가합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 현재 영상 라이브러리 | 기존 사례의 원본 영상 | 6TB |
| 계획 기간 증가량 | 연간 2TB × 3년 | 6TB |
| 미디어 정보 및 썸네일 | 분석용 추가 가정 | 0.5TB |
| 변환 임시 공간 | 분석용 추가 가정: 최대 동시 사용량 | 0.5TB |
| 예산에 반영할 사용량 합계 | 6TB + 6TB + 0.5TB + 0.5TB | 13TB |
| 필요 용량 예산 | 13TB ÷ (1 − 0.2) | 16.25TB |
| 예산에 포함된 운영 여유 | 16.25TB − 13TB | 3.25TB |
연간 영상 증가량이 4TB가 되면 필요 용량은 23.75TB입니다. (6 + 4 × 3 + 0.5 + 0.5) ÷ 0.8 = 23.75TB. 계산상 24TB보다 0.25TB 작지만, 그 차이를 실제 가용 공간으로 확정하지 않습니다.
변환 임시 공간이 4TB까지 필요하면 필요 용량은 20.625TB입니다. (6 + 2 × 3 + 0.5 + 4) ÷ 0.8 = 20.625TB. 계산상 24TB보다 3.375TB 작지만, 그 차이를 실제 가용 공간으로 확정하지 않습니다.
12TB HDD 3개, RAID 5, 계산상 24TB. 4베이 중 3개 사용, 여유 1개입니다. 예상 영상 12TB 외에 미디어 정보, 썸네일, 변환 임시 파일과 운영 여유를 고려합니다. SSD 캐시는 기본 구성으로 가정하지 않습니다.
계산상 용량과 필요 용량의 비교 차이는 7.75TB입니다. 운영 여유 3.25TB는 이미 16.25TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
일시 사용과 보관: 변환 임시 파일과 장기 보관용 변환본은 다릅니다. 정리되지 않는 임시 파일이 있으면 운영 여유가 소모되므로 실제 정리 정책을 확인합니다.
원본 재생과 변환: 용량이 충분해도 앱, 코덱, 재생 장치와 NAS의 변환 처리 조건에 따라 동시 재생 가능 범위가 달라집니다.
원격 사용: 평균 전송량과 순간 최대 비트레이트, Wi-Fi 및 원격 업로드 조건을 따로 확인하고 보존할 원본은 별도로 백업합니다.
NAS BACKUP AND REPLICATION
원본 8TB, 하루 변경량 200GB, 매일 1회 전송과 30일 이력 보관을 가정합니다. 단순 용량 예산은 8TB + 0.2TB × 30일 = 14TB이며 실제 이력 사용량은 백업 방식에 따라 달라집니다. 원격 업로드 200Mbps, 허용 데이터 손실 시점은 최대 24시간 전을 목표로 합니다.
기존 사례의 백업 대상 NAS 예산을 그대로 풉니다. 하루 변경량 200GB = 0.2TB이며, 30일 이력을 일별 변경량의 합으로 잡은 상담용 가정입니다. 압축 및 중복 제거 효과는 차감하지 않고, 원본 NAS의 공간은 별도로 산정합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 대상 NAS의 원본 사본 | 기존 사례: 운영 NAS 원본 8TB | 8TB |
| 30일 변경 이력 | 0.2TB/일 × 30일의 단순 예산 | 6TB |
| 예산에 반영할 사용량 합계 | 8TB + 6TB | 14TB |
| 필요 용량 예산 | 14TB ÷ (1 − 0.2) | 17.5TB |
| 예산에 포함된 운영 여유 | 17.5TB − 14TB | 3.5TB |
하루 변경량이 400GB가 되면 필요 용량은 25TB입니다. (8 + 0.4 × 30) ÷ 0.8 = 25TB. 기존 후보의 계산상 24TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
동일 변경량으로 60일 보관하면 필요 용량은 25TB입니다. (8 + 0.2 × 60) ÷ 0.8 = 25TB. 기존 후보의 계산상 24TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
백업 대상에 12TB HDD 3개, RAID 5, 계산상 24TB. 대상 NAS는 4베이 중 3개 사용, 여유 1개입니다. 보관량 14TB에 운영 여유 20%를 가정하면 14 ÷ 0.8 = 17.5TB가 필요합니다. 압축과 중복 제거 효과는 미리 차감하지 않으며 원본 NAS의 용량은 별도로 산정합니다.
계산상 용량과 필요 용량의 비교 차이는 6.5TB입니다. 운영 여유 3.5TB는 이미 17.5TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
이력 사용량: 변경량 합계가 모든 백업 또는 복제 방식의 실제 사용량과 같지는 않습니다. 재작성, 삭제 이력과 보존 방식으로 실제 대상 사용량을 확인합니다.
작업 중 공간: 추가 전체 백업이나 재동기화가 별도 공간을 사용하면 이 예산에 더합니다. 사본 8TB와 이력 6TB를 이미 합한 14TB에 원본을 다시 더하지 않습니다.
복원 시점: 매일 한 번 전송하는 일정과 최근 24시간 이내의 복원 시점을 실제로 확보하는 것은 다릅니다. 작업 완료, 실패 재시도와 복원 시험까지 확인합니다.
CLOUD WORKSPACE BACKUP
백업 대상 계정 합계 20개, 메일 1TB, 개인 파일 3TB, 공유 데이터 2TB로 현재 합계 6TB를 가정합니다. 전체 연간 증가량 1TB와 3년 계획이면 원본 예상량은 9TB입니다. 1년 버전 보존에 추가 3TB가 필요하다고 가정하되 실제 변경량과 보존 정책으로 다시 산정합니다.
기존 사례의 메일 1TB, 개인 파일 3TB와 공유 데이터 2TB는 합계입니다. 계정 20개를 다시 곱하지 않습니다. 1년 버전 보존에 필요한 3TB도 사례의 가정이며 계정 수나 기간만으로 자동 결정되는 값은 아닙니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 현재 메일 | 기존 사례의 대상 메일 | 1TB |
| 현재 개인 파일 | 기존 사례의 대상 파일 | 3TB |
| 현재 공유 데이터 | 기존 사례의 공유 데이터 | 2TB |
| 계획 기간 증가량 | 전체 연간 1TB × 3년 | 3TB |
| 버전 보존 추가량 | 기존 사례의 1년 보존 가정 | 3TB |
| 예산에 반영할 사용량 합계 | 1TB + 3TB + 2TB + 3TB + 3TB | 12TB |
| 필요 용량 예산 | 12TB ÷ (1 − 0.2) | 15TB |
| 예산에 포함된 운영 여유 | 15TB − 12TB | 3TB |
버전 보존 추가량이 9TB가 되면 필요 용량은 22.5TB입니다. (1 + 3 + 2 + 1 × 3 + 9) ÷ 0.8 = 22.5TB. 계산상 24TB보다 1.5TB 작지만, 그 차이를 실제 가용 공간으로 확정하지 않습니다.
전체 연간 증가량이 4TB가 되면 필요 용량은 26.25TB입니다. (1 + 3 + 2 + 4 × 3 + 3) ÷ 0.8 = 26.25TB. 기존 후보의 계산상 24TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
12TB HDD 3개, RAID 5, 계산상 24TB. 4베이 중 3개 사용, 여유 1개입니다. 예상 원본 9TB와 버전 3TB를 합한 12TB에 운영 여유 20%를 적용하면 필요한 공간은 15TB입니다. 서비스 간 같은 파일의 중복 제거를 가정해 용량을 줄이지 않습니다.
계산상 용량과 필요 용량의 비교 차이는 9TB입니다. 운영 여유 3TB는 이미 15TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
백업 대상 범위: 메일, 개인 파일과 공유 드라이브의 대상 범위를 먼저 확정합니다. 동일 파일의 서비스 간 중복 제거 효과를 임의로 가정하지 않습니다.
보존 정책: 퇴사자 데이터와 삭제 항목, 공유 데이터의 버전 보관이 3TB 예산에 포함됐는지 확인합니다. 앱이 별도 DB나 임시 수집 공간을 사용하면 추가합니다.
실제 복원: 앱의 지원 범위, API 제한과 관리자 권한을 확인하고 원본 형식 및 권한을 필요한 대상에 복원할 수 있는지 시험합니다.
ISCSI BLOCK STORAGE
외부 서버 2대가 각각 별도 LUN을 사용하고 계획 기간 말 활성 데이터 합계 3TB, 스냅샷 예산 1TB와 전용 10GbE 연결을 가정합니다. 예시 검증 기준은 8KiB 임의 입출력, 읽기 70%와 쓰기 30%, 합계 5,000 IOPS에서 평균 응답시간 5ms 이하이며 실제 업무의 요구값으로 조정합니다.
기존 사례의 활성 데이터 3TB는 서버 두 대의 합계이며 두 번 곱하지 않습니다. 스냅샷 1TB를 더하고 전체 공간의 20%를 남기는 기존 5TB 예산을 풉니다. 별도 백업 저장소의 공간은 제외합니다.
전체 공간의 20%를 운영 여유로 남기는 상담용 가정입니다. 합산한 사용량을 0.8로 나누며, 모든 NAS에 적용하는 고정 기준은 아닙니다. TB는 십진수 기준입니다.
| 산출 항목 | 계산 근거 | 용량 |
|---|---|---|
| 계획 기간 말 활성 데이터 | 기존 사례: 서버 2대 합계 | 3TB |
| 스냅샷 예산 | 기존 사례의 추가 공간 | 1TB |
| 예산에 반영할 사용량 합계 | 3TB + 1TB | 4TB |
| 필요 용량 예산 | 4TB ÷ (1 − 0.2) | 5TB |
| 예산에 포함된 운영 여유 | 5TB − 4TB | 1TB |
활성 데이터가 6TB로 늘면 필요 용량은 8.75TB입니다. (6 + 1) ÷ 0.8 = 8.75TB. 기존 후보의 계산상 8TB부터 부족하므로 구성 또는 저장 범위를 다시 검토합니다.
스냅샷 예산이 2TB가 되면 필요 용량은 6.25TB입니다. (3 + 2) ÷ 0.8 = 6.25TB. 계산상 8TB보다 1.75TB 작지만, 그 차이를 실제 가용 공간으로 확정하지 않습니다.
4TB SATA SSD 4개, RAID 10, 계산상 8TB. SATA SSD 저장소와 iSCSI를 지원하는 6베이 중 4개 사용, 여유 2개입니다. 데이터와 스냅샷 예산 합계 4TB에 운영 여유 20%를 적용하면 5TB가 필요합니다. 이 후보가 제시한 성능 기준을 충족하는지는 서버에서 부하 시험으로 확인합니다.
계산상 용량과 필요 용량의 비교 차이는 3TB입니다. 운영 여유 1TB는 이미 5TB에 포함되어 있습니다. 실제 장비의 시스템 및 파일시스템, 예약 공간을 반영한 같은 범위의 가용 용량으로 최종 비교합니다.
LUN 할당 방식: 실제 사용량 기준 예산과 미리 확보하는 LUN 공간을 구분합니다. 할당 상한 전체를 확보해야 한다면 그 확보량을 기준으로 다시 계산하며 예약 스냅샷 공간과 중복 합산하지 않습니다.
성능 판정: 기존 사례의 8KiB, 읽기 70% 및 쓰기 30%, 5,000 IOPS와 평균 5ms 목표는 별도 부하 시험 조건입니다. 용량 5TB가 확보됐다고 이 성능이 보장되지는 않습니다.
운영 안정성: 호스트별 접근 범위와 다중 경로 전환, 데이터 일관성과 별도 백업 복원을 기존 구성 사례의 조건에 따라 검증합니다.
03C / RESERVATION
03B 사무실 사례의 2TB는 파일 버전과 스냅샷에 사용할 것으로 예상한 합계이며, 제품에서 설정한 스냅샷 예약값을 뜻하지 않습니다. 다른 사례도 예상 사용량과 실제 예약 설정을 구분해 비교합니다.
| 구분 | 의미 | 용량 예산에 반영하는 기준 |
|---|---|---|
| 예상 사용량 | 앞으로 파일 버전과 스냅샷에 사용할 것으로 예상하는 용량 | 변경량과 보존 정책을 바탕으로 산정합니다. 03B 사무실 사례의 2TB는 이 예상량입니다. |
| 예약 공간 | 제품 설정에서 특정 용도를 위해 확보하는 공간 | 예약값과 예상 사용량의 포함 관계를 확인합니다. 2TB를 예약했다고 실제 데이터가 항상 2TB를 사용하는 것은 아닙니다. |
| 실제 사용량 | 현재 버전 또는 스냅샷 데이터가 실제로 사용하는 공간 | 데이터 변경량, 보존 정책과 제품의 저장 방식에 따라 달라집니다. 사용 기록을 바탕으로 예상량과 예약 설정을 점검합니다. |
파일 버전, 스냅샷과 별도 백업은 저장 위치와 보관 정책을 나눠 기록합니다. QTS의 스냅샷 예약 공간은 아직 사용하지 않았더라도 일반 데이터용 운영 여유와 같은 공간으로 잡지 않습니다.
03D / UNITS
제조사 HDD의 12TB 표기와 NAS 화면의 숫자는 단위 기준에 따라 다르게 보일 수 있습니다. RAID 계산, 필요 데이터량과 실제 NAS 표시 용량을 같은 단위와 저장 범위로 맞춰 비교합니다.
| 비교 대상 | 십진수 TB | 환산값 TiB |
|---|---|---|
| RAID 계산상 용량 | 24TB | 약 21.83TiB |
| 필요 용량 예산 | 22.5TB | 약 20.46TiB |
이 페이지의 RAID 계산은 미러 또는 패리티 공간만 반영한 십진수 TB 기준입니다. 단위 환산에 따른 숫자 차이는 시스템이나 파일시스템이 실제 사용하는 공간과 구분합니다.
시스템, 파일시스템과 예약 공간은 이미 반영됐는지 확인한 뒤 계산합니다. NAS 화면의 가용 용량에서 이미 빠진 항목을 다시 차감하지 않습니다.
03B의 예산에 포함한 버전 및 스냅샷 공간도 예약 설정과 대조해 한 번만 반영하고, 필요 용량과 실제 가용 용량의 비교 범위를 일치시킵니다.
볼륨 한도는 용량에서 빼는 값이 아니라 구성 가능 여부를 판단하는 조건입니다. 모델, OS와 필요한 메모리 조건에서 계산된 공간을 원하는 풀 및 볼륨으로 사용할 수 있는지 확인합니다.
전체 합계가 충분해도 한 볼륨에 담을 수 없다면 볼륨 분리나 다른 장비 구성을 비교합니다.
필요 용량을 충족하지 못하면 디스크 용량과 개수 또는 저장소 분리안을 다시 선택합니다. 합의한 운영 여유를 임의로 없애서 계산만 맞추지 않습니다.
03E / PROTECTION
물리적 확장 공간, 디스크 장애 대응과 데이터 복원 수단을 구분합니다. 각 수단이 담당하는 역할과 대신할 수 없는 것을 함께 봅니다.
| 수단 | 담당하는 역할 | 대신할 수 없는 것 |
|---|---|---|
| 빈 베이 | 이후 디스크 추가, 핫스페어 또는 별도 저장소 구성에 사용할 물리 공간 | 현재 디스크 장애 대응이나 데이터 사본 |
| 핫스페어 | 지원 조건에 따라 장애 디스크를 대신해 자동 재구축에 사용하는 예비 디스크 | RAID 자체의 장애 허용 수 증가 |
| RAID 중복 보호 | 정해진 수와 위치 조건의 디스크 장애에 대응 | 삭제, 랜섬웨어와 파일 손상에 대비한 과거 사본 |
| 같은 저장소의 스냅샷 | 보존된 특정 시점의 데이터 상태로 되돌리기 | 원본 NAS 또는 저장소 전체 장애 시 사용할 독립 사본 |
| 별도 장치 또는 위치의 백업 | 원본 NAS와 분리해 보관하는 복원용 데이터 | 실제 복원 가능 여부와 소요시간을 확인하는 시험 |
핫스페어의 전용 및 공용 범위, 복수 지정과 RAID 10 적용 조건은 02D에서 이어서 확인할 수 있습니다. 여기서는 저장 공간과 보호 수단의 역할을 구분해 예산에 반영합니다.
장애나 사고가 발생했을 때 최근 얼마 동안의 데이터 손실까지 감수할 수 있는지 정합니다. 이 범위를 기준으로 필요한 사본 생성 간격을 판단합니다.
삭제 및 손상 사고에 대비해 얼마나 이전 시점의 사본까지 남아 있어야 하는지 정합니다. 필요한 과거 시점으로 되돌릴 수 있는 사본이 보관되어 있는지 확인합니다.
장애 발생 후 업무를 얼마 안에 다시 시작해야 하는지 정합니다. 실제 복원 가능 여부와 소요시간을 시험해 목표를 충족하는지 확인합니다.
04 / MIGRATION OPTIONS
아래 표는 Synology DSM 7 도움말과 QNAP QTS 5.2.x 공식 절차의 주요 변경 경로입니다. 다른 운영체제나 버전에 그대로 적용하지 않으며, 실제 장비의 저장소 구조와 지원 조건을 함께 확인합니다.
04A / COMPARISON
아래 표는 Synology DSM 7 도움말과 QNAP QTS 5.2.x 공식 절차의 주요 변경 경로입니다. 다른 운영체제나 버전에 그대로 적용하지 않으며, 실제 장비의 저장소 구조와 지원 조건을 함께 확인합니다.
| 현재 구성과 목표 | DSM 7 안내 | QTS 5.2.x 안내 | 실제 적용 판단 |
|---|---|---|---|
| 단일 디스크 → RAID 1 | Basic에서 1개 추가 | Single에서 1개 추가 | Basic / Single 구성 기준입니다. 단일 디스크 SHR과 구분합니다. |
| 단일 디스크 → RAID 5 | Basic에서 2개 추가 | Single → RAID 1 → RAID 5 각 단계에서 디스크 추가 | QTS는 단계별 변경입니다. 각 단계의 디스크 조건과 완료 상태를 확인합니다. |
| RAID 1 → RAID 5 | 2디스크 미러: 1개 추가 3개 이상 미러: 추가 없음 | 1개 이상 추가 | DSM의 다중 미러 조건을 QTS에 그대로 적용하지 않습니다. |
| RAID 5 → RAID 6 | 1개 추가 일부 모델은 변경 미지원 | 1개 이상 추가 | RAID 6 신규 생성 지원과 기존 RAID 5의 변경 지원을 구분합니다. |
| SHR-1 → SHR-2 | 현재 구성에 따라 1개 또는 2개 추가 | 해당 없음: Synology 방식 | 변경 후 구성에 따라 총 4개 또는 5개가 필요합니다. 현재 디스크 수와 용량 조합을 확인합니다. |
표의 숫자는 현재 구성에 추가하는 디스크 수입니다. DSM 7과 QTS 5.2.x의 해당 변경 절차를 비교한 주요 경로이며, 다른 OS나 모든 NAS의 변경 목록을 뜻하지 않습니다.
SHR-1은 구성에 따라 추가 디스크가 두 개 필요할 수 있습니다. 기존 디스크가 두 개뿐이거나, 모든 디스크의 용량이 서로 다르거나, 세 개 이상 구성에서 가장 큰 두 디스크의 용량이 나머지보다 큰 경우가 해당합니다. SHR-2 신규 구성의 최소 개수만으로 기존 SHR-1의 변경 조건을 판단하지 않습니다.
04B / COMMON CONDITIONS
목표 RAID를 새로 만들 수 있는지와 현재 저장소에서 변경할 수 있는지는 별개입니다. 저장소 상태, 추가 디스크 조건과 지원 경로를 함께 판단합니다.
RAID 6 신규 구성의 최소 디스크 수는 네 개입니다. 기존 네 디스크 RAID 5를 추가 디스크 없이 RAID 6로 변경할 수 있다는 뜻은 아닙니다.
QTS 5.2.x의 해당 변경에는 추가 디스크가 필요합니다. 모든 베이를 현재 RAID가 사용하고 있고 지원되는 추가 편입 수단도 없다면 해당 온라인 변경 경로를 적용할 수 없습니다.
DSM은 정상(Healthy) 저장소 풀을 전제로 하며, RAID Group 기능으로 구성한 풀은 해당 RAID 종류 변경 대상이 아닙니다. 모델별 변경 지원과 호환 드라이브 조건을 확인합니다.
QTS 5.2.x는 저장소 풀 또는 정적 볼륨의 RAID 그룹을 선택해 변경합니다. 현재 저장소가 사용하는 OS와 구성 단위를 기준으로 지원 절차를 적용합니다.
DSM 7의 추가 드라이브는 기존 풀의 최소 드라이브 용량 이상이며 같은 드라이브 유형이어야 합니다. QTS 5.2.x의 해당 변경에서도 추가 디스크 각각이 기존 RAID 그룹의 최소 디스크 용량 이상이어야 합니다. 필요한 개수와 실제 편입 가능한 장착 위치를 함께 확인합니다.
두 OS 모두 새로 편입하는 디스크의 기존 데이터가 삭제됩니다. 다른 풀이나 백업에 사용 중인 디스크라면 필요한 데이터를 별도 위치에 보존합니다. 기존 저장소의 데이터 유지와 추가 디스크의 초기화는 구분합니다.
디스크 추가 확장이나 장애 수리가 목적이라면 그 작업의 공식 드라이브 조건을 따릅니다. RAID 종류 변경 조건을 다른 작업에 그대로 적용하지 않습니다.
DSM의 RAID 5 → RAID 1 역방향 변경과 RAID 1 및 SHR 사이의 직접 전환은 지원되지 않습니다. 지원 경로가 없다면 별도 백업과 새 저장소 구성을 검토합니다.
목표 저장소의 용량과 복원 계획이 성립하기 전에 기존 풀부터 삭제하지 않습니다. 조건별 대안은 아래에서 이어서 비교합니다.
04C / ALTERNATIVES
변경 버튼이 없거나 필요한 디스크를 추가할 수 없을 때는 원인을 구분합니다. “백업 후 다시 만들면 된다”는 설명만으로는 임시 공간, 복원 용량과 업무 중단 문제를 해결할 수 없습니다.
| 막히는 조건 | 현재 판단 | 비교할 대안 |
|---|---|---|
| 추가 디스크를 편입할 위치가 없음 | 해당 추가 디스크 기반 변경 경로를 적용할 수 없습니다. | 지원되는 장비 이전, 다른 NAS로의 데이터 이전, 별도 백업 후 재구성 |
| 현재 RAID와 목표 RAID 사이의 지원 경로가 없음 | 기존 데이터를 유지하는 직접 변경으로 계획하지 않습니다. | 새 저장소를 만든 뒤 데이터와 서비스를 이전 |
| 목표 저장소의 용량이 부족함 | 백업을 확보해도 전체 복원이 불가능합니다. | 더 큰 디스크, 더 많은 베이 또는 목적별 저장소 분리 |
| 저장소에 경고나 접근 이상이 있음 | 계획된 변경의 진행 여부를 먼저 재판단합니다. | 상태 진단과 데이터 보존, 재구축 또는 복구 방향 검토 |
| 보호 대상 데이터의 백업이나 복원 가능성이 확인되지 않음 | 계획된 RAID 변경, 확장과 재구성을 보류합니다. | 별도 저장소를 확보하고 백업 및 복원 시험을 거쳐 진행 여부를 정합니다. |
| 허용할 수 있는 업무 중단 시간이 짧음 | 같은 장비를 지우고 복원하는 방식이 맞는지 다시 판단합니다. | 별도 장비에 먼저 이전한 뒤 최종 전환하는 방식 비교 |
지원 경로와 디스크 조건뿐 아니라 현재 저장소 상태도 변경 가능 여부에 영향을 줍니다. 변경 메뉴가 비활성화되면 해당 OS의 조건을 확인해야 하며, 메뉴를 표시하기 위해 임의로 풀이나 디스크 구성을 변경하지 않습니다.
04D / SPACE AND TIME
임시 사본을 보관할 공간과 최종 운영 공간을 각각 계산합니다. 데이터 전송에 필요한 시간과 실제 업무를 멈춰야 하는 구간도 나눠 계획합니다.
옮겨둘 데이터, 백업 도구가 사용하는 공간과 작업 중 여유를 수용해야 합니다. 압축이나 중복 제거 효과를 미리 확정값으로 차감하지 않습니다.
이전할 데이터뿐 아니라 이후 증가량, 보존할 버전과 운영 여유까지 포함합니다. 임시로 데이터가 들어가는 공간과 몇 년간 운영할 공간은 같은 기준이 아닙니다.
상담용 가정으로 28TB를 일정한 실효 전송속도 200MB/s로 옮기면 한 방향의 순수 전송에 약 38.9시간이 필요합니다. TB와 MB/s는 모두 십진수 기준입니다.
28,000,000MB ÷ 200MB/s ÷ 3,600 ≈ 38.9시간. TB를 MB로 환산해 계산하며, 백업과 복원을 각각 같은 조건으로 한 번씩 수행하면 합계는 약 77.8시간입니다.
전송량과 가정한 속도로 계산한 예시입니다. 실제 소요시간이나 서비스 중단 시간을 보장하는 값은 아닙니다.
전체 이전 시간과 서비스를 멈춰야 하는 시간은 구분합니다. 초기 복사를 서비스 운영 중에 수행할 수 있는지, 최종 변경분을 언제 반영할지 확인합니다.
업무 앱을 정지하고 다시 확인해야 하는 구간을 따로 정합니다. 전송 시간의 합계를 그대로 업무 중단 시간으로 잡지 않습니다.
기존 저장소를 지우기 전에는 임시 사본, 최종 용량, 복원 방법과 서비스 전환 계획이 모두 성립해야 합니다.
05 / CHANGE EXAMPLES
아래는 실제 구축 실적이 아니라 가정형 상담 사례입니다. 보호할 기존 데이터가 있는 변경 작업은 백업과 복원 가능성을 확인한 상태를 전제로 합니다. 표시 용량은 십진수 TB 기준의 계산상 데이터 용량이며, 실제 가용 용량과 운영 여유는 별도로 판단합니다.
05A / SYNOLOGY DSM
DSM 7.4 계열을 우선 기준으로 작성했으며 현재 검증 기준점은 DSM 7.4.1-90080입니다. 실제 지원 여부는 NAS 모델, 설치된 DSM 버전, 현재 스토리지 풀의 RAID 또는 SHR 유형과 상태, 드라이브 수와 용량에 따라 달라질 수 있습니다. 정상적인 구성 변경 사례는 스토리지 풀이 Healthy 상태이고 선택한 변경 방식에 필요한 드라이브와 장착 조건을 충족한 상태를 전제로 합니다. Degraded 상태의 사례는 별도로 판단합니다.
SECOND DRIVE FOR PROTECTION
업무 자료를 HDD 한 개에 저장해 사용하고 있으며, 디스크 장애에 대비해 두 번째 HDD 추가를 검토하는 상황입니다.
2베이 이상 Synology NAS에서 12TB HDD 한 개를 사용합니다.
현재 스토리지 풀이 SHR인지 Basic인지에 따라 변경 방법이 다릅니다.
기존 데이터를 유지하면서 HDD 한 개의 장애에 대응할 수 있는 구성을 확보합니다.
현재 구성이 SHR이라면 두 번째 12TB HDD를 기존 SHR 스토리지 풀에 추가하는 방법을 검토합니다.
현재 구성이 Basic이라면 SHR의 Add Drive 절차와 동일하게 처리하지 않고, DSM의 Change RAID Type에서 Basic에서 RAID 1로의 변경을 검토합니다.
두 경우 모두 새 HDD의 상태와 유형, 용량 조건과 해당 모델의 RAID 지원 여부를 확인합니다. 단일 드라이브 SHR에 HDD 한 개를 추가하면 보호는 생기지만 저장 용량은 증가하지 않습니다. Basic에서 RAID 1로의 변경은 별도의 RAID 유형 변경 절차입니다.
12TB HDD 한 개의 SHR에 두 번째 12TB HDD를 추가하면 계산상 데이터 용량은 12TB로 유지되고 HDD 한 개 장애에 대응할 수 있게 됩니다.
Basic에서 RAID 1로 변경하는 경우에도 12TB HDD 두 개의 계산상 데이터 용량은 12TB입니다.
즉 HDD는 한 개 더 사용하지만 저장 용량이 두 배로 증가하는 것은 아닙니다.
새 HDD 비용과 동기화 또는 RAID 변경 작업이 발생합니다.
이번 변경의 핵심은 저장 공간 증가가 아니라 디스크 장애에 대한 보호 확보입니다.
현재 모델에서 필요한 RAID 유형이나 변경 경로를 지원하지 않으면 보호 구성을 새로 만들 수 있는 다른 스토리지 풀 또는 다른 NAS로 데이터를 이전하는 방법을 검토합니다.
저장 용량 증가가 우선 목적이라면 두 번째 HDD 한 개를 추가하는 방법이 목표에 맞는지도 다시 확인합니다.
SHR에 두 번째 HDD를 추가하는 것과 Basic을 RAID 1로 변경하는 것은 결과가 비슷해 보여도 서로 다른 변경 절차입니다.
SHR DRIVE ADDITION
기존의 디스크 장애 보호는 유지하면서 저장 공간 부족에 대응하기 위해 HDD를 추가하려는 상황입니다.
3베이 이상 Synology NAS에서 12TB HDD 두 개의 SHR-1을 사용합니다.
계산상 데이터 용량은 12TB이며 추가 HDD를 장착할 수 있다고 가정합니다.
HDD 한 개 장애에 대응하는 SHR-1을 유지하면서 저장 용량을 늘립니다.
스토리지 풀이 Healthy 상태이고 NAS 안에 사용할 수 있는 미사용 HDD가 있어야 합니다.
새 HDD는 Healthy 상태이고 기존 스토리지 풀과 같은 드라이브 유형이어야 합니다. 추가 드라이브의 용량 조건과 모델별 최대 드라이브 수도 확인합니다.
12TB HDD 한 개를 추가하고 SHR 확장 작업이 정상 완료되면 세 개의 12TB HDD로 구성된 SHR-1의 계산상 데이터 용량은 24TB가 됩니다.
확장 작업 중 스토리지 부하가 발생하고 완료까지 시간이 필요할 수 있습니다.
HDD를 장착한 직후의 상태를 최종 결과로 판단하지 않고 DSM에서 확장 작업 완료와 스토리지 풀 상태를 확인합니다.
추가 HDD를 장착할 수 없거나 기존 SHR에 드라이브를 편입할 수 없는 조건이라면 더 큰 HDD로 순차 교체하거나 더 많은 베이의 NAS로 이전하는 방법을 비교합니다.
MIXED CAPACITY SHR ADDITION
기존 SHR에 서로 다른 용량의 HDD를 추가할 수 있는지 확인하는 상황입니다.
4TB, 8TB, 8TB HDD 세 개의 SHR-1을 사용합니다.
계산상 데이터 용량은 12TB이며 추가 HDD를 장착할 수 있다고 가정합니다.
기존 SHR-1의 보호 수준을 유지하면서 저장 공간을 늘립니다.
이 사례에서는 새로 추가하는 HDD를 8TB로 한정합니다.
SHR에 추가할 HDD의 용량 조건은 Synology 공식 문서의 버전과 언어에 따라 표현 차이가 확인되므로, 이 사례에서는 기존 드라이브 용량 중 하나와 동일한 8TB HDD를 사용합니다.
대상 DSM과 모델에서 실제로 선택 가능한 드라이브 조건도 함께 확인합니다.
4TB + 8TB + 8TB SHR-1에 8TB HDD를 추가하고 확장 작업이 완료되면 계산상 데이터 용량은 12TB에서 20TB로 증가합니다.
SHR이라고 해서 어떤 용량의 HDD든 같은 효율로 사용할 수 있는 것은 아닙니다.
추가하는 HDD의 용량에 따라 실제 활용되는 공간과 이후 HDD 교체 전략이 달라질 수 있습니다.
추가하려는 HDD가 DSM에서 선택되지 않거나 용량 조건이 명확하지 않다면 기존 HDD와 같은 용량 또는 현재 최대 HDD 이상의 용량을 사용하는 방법을 우선 검토합니다.
SHR에서 서로 다른 HDD 용량을 사용할 수 있다는 것과 특정 용량의 HDD를 기존 스토리지 풀에 추가할 수 있다는 것은 같은 의미가 아닙니다.
RAID 1 TO RAID 5
현재의 디스크 장애 보호를 유지하면서 저장 용량을 늘리기 위해 RAID 1에 HDD를 추가하려는 상황입니다.
4베이 Synology NAS에서 12TB HDD 두 개의 RAID 1을 사용합니다.
계산상 데이터 용량은 12TB이며 변경에 사용할 12TB HDD 한 개를 추가할 수 있다고 가정합니다.
HDD 한 개 장애에 대응하는 구성을 유지하면서 계산상 데이터 용량을 늘립니다.
스토리지 풀이 Healthy 상태이고 대상 모델이 RAID 5와 RAID 유형 변경을 지원해야 합니다.
12TB HDD 한 개를 미사용 드라이브로 준비한 뒤 기존 RAID 1 스토리지 풀에서 Change RAID Type을 실행합니다. 2디스크 RAID 1에서 RAID 5로 변경할 때는 추가 HDD 한 개가 필요합니다.
12TB HDD 세 개의 RAID 5로 변경이 완료되면 계산상 데이터 용량은 24TB가 됩니다.
저장 방식이 미러 구조에서 패리티 기반 RAID로 변경됩니다.
RAID 유형 변경이 완료될 때까지 스토리지 부하와 작업 시간을 고려하고 다른 구성 변경은 완료 후 다시 판단합니다.
현재 모델이나 스토리지 풀에서 직접 RAID 유형 변경을 지원하지 않으면 다른 저장소에 RAID 5를 새로 구성하고 데이터를 이전하는 방법을 검토합니다.
RAID 5 TO RAID 6
저장 용량 증가보다 디스크 장애에 대한 보호 수준을 높이는 것이 중요해져 RAID 6 변경을 검토하는 상황입니다.
4베이 Synology NAS에서 12TB HDD 세 개의 RAID 5를 사용합니다.
계산상 데이터 용량은 24TB이며 변경에 사용할 12TB HDD 한 개를 추가할 수 있다고 가정합니다.
HDD 한 개 장애에 대응하는 RAID 5에서 HDD 두 개 장애에 대응하는 RAID 6로 변경합니다.
스토리지 풀이 Healthy 상태이고 해당 모델이 RAID 6 자체와 RAID 5에서 RAID 6로의 변경 기능을 모두 지원해야 합니다.
12TB HDD 한 개를 미사용 드라이브로 준비하고 Change RAID Type 과정에서 편입합니다. 모델에 따라 RAID 5에서 RAID 6로의 직접 변경을 지원하지 않을 수 있습니다.
네 개의 12TB HDD로 RAID 6 변경이 완료되면 계산상 데이터 용량은 24TB로 유지됩니다.
저장 용량은 증가하지 않지만 디스크 장애 허용 범위는 한 개에서 두 개로 강화됩니다.
HDD 한 개를 추가로 사용하고 RAID 변경 작업을 수행하지만 저장 용량 증가 효과는 없습니다.
작업 중 스토리지 부하와 소요 시간을 고려해야 합니다.
현재 모델이 RAID 6 신규 구성은 지원하지만 RAID 5에서 RAID 6로의 직접 변경만 지원하지 않는다면 백업과 복원 가능성을 확보한 뒤 RAID 6를 새로 구성하는 방법을 검토합니다.
모델 자체가 RAID 6를 지원하지 않으면 RAID 6을 지원하는 다른 NAS로 이전하는 방법을 비교합니다.
SHR-1 TO SHR-2
저장 공간 증가보다 두 개의 HDD 장애에 대응하는 보호 수준이 필요해져 SHR-2 변경을 검토하는 상황입니다.
4베이 이상 Synology NAS에서 12TB HDD 세 개의 SHR-1을 사용합니다.
계산상 데이터 용량은 24TB이며 변경에 사용할 12TB HDD 한 개를 장착할 수 있다고 가정합니다.
HDD 한 개 장애에 대응하는 SHR-1에서 HDD 두 개 장애에 대응하는 SHR-2로 변경합니다.
스토리지 풀이 Healthy 상태이고 대상 모델이 SHR-2와 RAID 유형 변경을 지원해야 합니다.
새 12TB HDD는 NAS에 장착해 미사용 드라이브 상태로 준비합니다.
이 HDD를 기존 SHR-1에 Add Drive로 먼저 편입하지 않습니다. 기존 스토리지 풀에서 Change RAID Type을 선택하고 SHR-2를 목표 유형으로 지정한 뒤, 변경 과정에서 해당 미사용 HDD를 선택합니다. 공식 절차도 목표 RAID 유형을 선택한 뒤 추가할 드라이브를 선택하는 순서입니다.
12TB HDD 세 개의 SHR-1에 새 12TB HDD 한 개를 RAID 유형 변경 과정에서 편입해 네 개의 12TB SHR-2가 완성되면 계산상 데이터 용량은 24TB로 유지됩니다.
이번 사례의 목적은 용량 증가가 아니라 보호 수준 강화입니다.
SHR-1에서 SHR-2로 변경할 때 필요한 추가 HDD 수는 기존 SHR-1의 드라이브 구성에 따라 달라질 수 있습니다.
따라서 3개의 동일한 12TB HDD로 구성된 이 사례의 조건을 다른 SHR 구성에 그대로 적용하지 않습니다.
대상 모델이 SHR-2를 지원하고 백업과 복원에 필요한 공간을 확보할 수 있다면 SHR-2를 새로 구성하는 방법을 검토할 수 있습니다.
모델이 SHR-2를 지원하지 않거나 필요한 구성 조건을 충족할 수 없다면 SHR-2를 지원하는 다른 NAS로 이전하는 방법을 비교합니다.
새 HDD를 NAS에 장착하는 것과 기존 SHR-1에 Add Drive로 편입하는 것은 다른 작업입니다.
이 사례에서는 새 HDD를 미사용 상태로 준비한 뒤 Change RAID Type 과정에서 편입합니다.
LARGER DRIVES IN FULL-BAY SHR
NAS의 모든 베이를 사용하고 있어 HDD를 추가할 수 없지만 기존 SHR을 유지하면서 더 큰 HDD로 순차 교체해 용량을 늘리려는 상황입니다.
4베이 Synology NAS에서 8TB HDD 네 개의 SHR-1을 사용합니다.
모든 베이를 사용하고 있으며 계산상 데이터 용량은 24TB입니다.
16TB HDD로 한 개씩 교체한다고 가정합니다.
드라이브 수와 SHR-1을 그대로 유지하면서 저장 용량을 단계적으로 늘립니다.
모든 베이를 사용 중이므로 이 사례에서는 미사용 HDD가 필요한 Replace Drive를 전제로 하지 않습니다.
한 번에 HDD 한 개를 교체하고 스토리지 풀을 Repair한 뒤, 해당 작업과 상태 확인이 완료된 후 다음 HDD를 교체합니다. Synology는 여러 HDD를 교체할 때 한 번에 한 개씩 진행하도록 안내합니다.
각 단계의 교체와 Repair 및 필요한 확장 처리가 완료된 뒤의 계산상 데이터 용량입니다.
| 완료 단계 | HDD 구성 | 계산상 데이터 용량 |
|---|---|---|
| 시작 | 8TB + 8TB + 8TB + 8TB | 24TB |
| 첫 번째 교체 완료 | 16TB + 8TB + 8TB + 8TB | 24TB |
| 두 번째 교체 완료 | 16TB + 16TB + 8TB + 8TB | 32TB |
| 세 번째 교체 완료 | 16TB + 16TB + 16TB + 8TB | 40TB |
| 네 번째 교체 완료 | 16TB + 16TB + 16TB + 16TB | 48TB |
동일 용량 HDD로 구성된 SHR-1은 최소 두 개의 HDD를 더 큰 용량으로 교체해야 새 공간을 활용할 수 있습니다.
수동 교체 방식에서는 HDD 교체 후 Repair가 완료될 때까지 스토리지 풀이 Degraded 상태가 될 수 있습니다.
따라서 여러 HDD를 동시에 제거하지 않고 각 단계의 복구와 상태 확인을 끝낸 뒤 다음 교체를 진행합니다.
기존 HDD의 상태가 불안정하거나 반복되는 Repair의 위험과 작업 시간을 감당하기 어렵다면 더 큰 HDD로 구성한 새 NAS 또는 별도 저장소로 데이터를 이전하는 방법을 비교합니다.
빈 베이와 적합한 미사용 HDD가 있는 다른 환경이라면 Replace Drive를 사용할 수 있는지도 확인할 수 있습니다.
첫 번째 16TB HDD 교체만으로 계산상 데이터 용량이 증가하지 않습니다.
또한 Full Bay 환경의 수동 교체와 미사용 HDD를 이용하는 Replace Drive는 작업 방식이 다릅니다.
MIXED SHR DRIVE REPLACEMENT
서로 다른 용량으로 구성한 SHR에서 작은 HDD를 더 큰 HDD로 교체할 때 어느 단계부터 추가 용량을 사용할 수 있는지 확인하는 상황입니다.
4TB, 8TB, 12TB HDD 세 개의 SHR-1을 사용합니다.
계산상 데이터 용량은 12TB입니다.
작은 HDD부터 12TB HDD로 교체한다고 가정합니다.
기존 SHR-1을 유지하면서 작은 HDD를 교체해 저장 용량을 늘립니다.
기존 HDD 용량이 서로 다른 SHR에서는 새 교체 HDD가 현재 가장 큰 HDD 이상이어야 합니다.
용량 활용을 높이기 위해 작은 HDD부터 교체하고, 한 단계의 Replace Drive 또는 Repair가 완료된 뒤 다음 교체를 진행합니다.
각 단계의 교체와 복구 및 필요한 확장 작업이 완료된 뒤의 계산상 데이터 용량입니다.
| 완료 단계 | HDD 구성 | 계산상 데이터 용량 |
|---|---|---|
| 시작 | 4TB + 8TB + 12TB | 12TB |
| 첫 번째 교체 완료 | 12TB + 8TB + 12TB | 20TB |
| 두 번째 교체 완료 | 12TB + 12TB + 12TB | 24TB |
동일 용량 SHR 사례와 달리 작은 HDD를 교체한 첫 단계부터 계산상 데이터 용량이 증가할 수 있습니다.
어떤 HDD를 먼저 교체하는지가 용량 활용에 영향을 줍니다.
신규 SHR을 만들었을 때의 RAID Calculator 결과만 보고 기존 스토리지 풀의 교체 순서를 결정하지 않습니다.
현재 최대 HDD 이상의 교체 HDD를 준비할 수 없다면 교체를 보류하고 용량 계획에 맞는 HDD를 먼저 확보합니다.
남은 HDD의 상태가 불안정하면 반복 교체보다 새 저장소로 이전하는 방법을 함께 비교합니다.
DEGRADED SHR AND EXPANSION
HDD 한 개가 고장 난 상태에서 장애 HDD 교체와 저장 용량 확장을 함께 검토하는 상황입니다.
6베이 Synology NAS에서 12TB HDD 네 개의 SHR-1을 사용합니다.
정상 구성의 계산상 데이터 용량은 36TB이며 현재 HDD 한 개의 장애로 스토리지 풀이 Degraded 상태라고 가정합니다.
추가 HDD를 장착할 수 있는 베이는 남아 있습니다.
기존 데이터의 보존 가능성을 먼저 확인하고 스토리지 풀을 정상화한 뒤, 조건이 충족되면 12TB HDD 한 개를 추가해 저장 용량을 확장합니다.
Degraded 상태에서는 정상적인 Add Drive 확장을 먼저 진행하지 않습니다. Add Drive를 사용하려면 대상 스토리지 풀이 Healthy 상태여야 합니다.
먼저 데이터 접근 여부, 백업과 복원 가능성, 장애 HDD와 남아 있는 HDD의 상태를 확인합니다.
디스크 한 개가 고장 난 SHR-1은 데이터에 접근할 수 있더라도 추가 HDD 장애를 허용하는 중복 보호 여유가 남아 있지 않습니다.
교체 HDD와 나머지 저장장치 상태가 적절하다면 결함 HDD를 교체한 뒤 Repair를 검토합니다.
12TB 교체 HDD를 사용해 Repair를 완료하고 스토리지 풀이 Healthy 상태로 복구되면 계산상 데이터 용량은 36TB입니다.
그 뒤 확장 조건을 다시 확인하고 다섯 번째 12TB HDD를 Add Drive로 편입해 작업이 완료되면 계산상 데이터 용량은 48TB가 됩니다.
장애 복구와 용량 확장은 하나의 작업으로 묶지 않습니다.
먼저 현재 스토리지 풀의 데이터 보존과 정상화 가능성을 판단하고, Healthy 상태가 확인된 이후에 용량 확장을 별도 단계로 검토합니다.
남은 HDD에서도 오류나 불안정 징후가 확인되거나 백업과 복원 가능성이 확보되지 않았다면 무조건 Repair를 시작하지 않습니다.
필요한 데이터를 먼저 확보하거나 데이터 복구 가능성을 검토한 뒤 기존 스토리지 풀 복구, 새 저장소 구성 또는 다른 NAS로의 이전을 비교합니다.
Degraded 상태에서 가장 먼저 판단할 것은 확장 용량이 아니라 현재 데이터를 보존하면서 Repair를 진행할 수 있는 상태인지 여부입니다.
POOL EXPANDED, VOLUME UNCHANGED
HDD 추가와 SHR 확장 후 기존 볼륨의 용량이 예상한 만큼 증가하지 않은 원인을 확인하는 상황입니다.
12TB HDD 두 개의 SHR-1을 사용하며 SHR 계산상 데이터 용량은 12TB입니다.
이 스토리지 풀 안의 볼륨 할당량은 10TB라고 가정합니다.
여기에 12TB HDD 한 개를 추가합니다.
스토리지 풀 확장으로 확보된 공간을 기존 볼륨에서도 사용할 수 있도록 합니다.
먼저 SHR 확장이 정상적으로 완료됐는지 확인합니다.
그다음 현재 스토리지 풀이 여러 볼륨을 지원하는 구성인지, 기존 볼륨을 별도로 확장해야 하는지, 모델별 최대 단일 볼륨 크기는 얼마인지 확인합니다.
SHR 확장 작업이 완료되면 SHR 계산상 데이터 용량은 12TB에서 24TB로 증가합니다.
하지만 10TB는 볼륨 할당량 가정이므로 다른 종류의 값입니다.
구성에 따라 스토리지 풀에 여유 공간이 생긴 뒤 기존 볼륨의 크기를 별도로 늘려야 할 수 있습니다.
HDD 추가, SHR 계산상 데이터 용량 증가, 스토리지 풀의 가용 공간 증가와 볼륨 할당량 증가는 같은 값이나 같은 단계가 아닙니다.
공유폴더에서 실제 사용할 수 있는 남은 공간도 볼륨 할당량과 실제 사용량에 따라 달라집니다.
기존 볼륨이 해당 모델의 최대 단일 볼륨 크기에 도달했다면 더 이상 같은 볼륨을 확장하지 못할 수 있습니다.
이 경우 스토리지 풀의 남은 공간에 추가 볼륨을 만들거나 다른 저장소 구성을 검토합니다.
FULL BAY SHR PROTECTION UPGRADE
NAS의 모든 베이를 사용하고 있으며, 저장 용량보다 두 개의 HDD 장애 대응을 우선해 SHR-2로 보호 수준을 높이려는 상황입니다.
4베이 Synology NAS에서 12TB HDD 네 개의 SHR-1을 사용합니다.
계산상 데이터 용량은 36TB입니다.
새 저장소로 이전해야 할 실제 데이터가 십진수 기준 28TB라고 가정합니다. 향후 증가량과 스냅샷, 운영 여유는 포함하지 않은 값입니다.
본체의 모든 베이를 사용 중이며, 이 사례에서는 지원되는 추가 HDD 편입 수단도 사용할 수 없다고 가정합니다.
SHR-1을 SHR-2로 변경해 HDD 두 개 장애에 대응할 수 있는 보호 수준을 확보합니다.
기존 SHR-1에서 SHR-2로 변경하려면 현재 구성에 맞는 추가 미사용 HDD가 필요합니다.
하지만 이 사례에서는 필요한 HDD를 편입할 방법이 없으므로 현재 스토리지 풀에서 해당 온라인 변경 경로를 사용할 수 없습니다.
현재 4×12TB SHR-1의 계산상 데이터 용량은 36TB입니다.
같은 네 개의 12TB HDD를 사용해 SHR-2를 새로 구성한다면 계산상 데이터 용량은 24TB입니다.
이 값은 기존 스토리지 풀의 온라인 변경 결과가 아니라 신규 구성의 계산입니다.
또한 24TB는 이전 대상 데이터 28TB보다 작으므로 같은 HDD 네 개를 이용한 신규 SHR-2 구성도 이 사례의 데이터를 모두 수용하지 못합니다.
기존 장비를 비우고 SHR-2를 새로 구성하려면 이전 대상 데이터를 보관할 임시 저장소와 복원 계획이 필요합니다.
최종 저장소는 현재 데이터뿐 아니라 향후 증가량, 스냅샷 예상 사용량과 운영 여유까지 포함해 충분한 실제 가용 용량을 확보해야 합니다.
보호 수준을 SHR-2로 높인다는 목표를 유지하면서 더 큰 HDD 또는 더 많은 베이의 NAS를 비교합니다.
예를 들어 신규 구성의 계산값은 다음과 같습니다.
20TB HDD 네 개의 SHR-2 → 40TB
12TB HDD 다섯 개의 SHR-2 → 36TB
두 값 모두 시스템 영역 등을 반영하기 전의 계산상 데이터 용량입니다. 실제 이전 대상과 운영 예산을 수용할 수 있는지는 별도로 확인해야 합니다.
더 큰 HDD로 교체하는 것만으로 기존 SHR-1의 보호 수준이 SHR-2로 바뀌는 것은 아닙니다.
RAID TO SHR CONVERSION
SHR의 확장 특성을 활용하기 위해 Synology NAS의 기존 일반 RAID를 SHR로 직접 변경할 수 있는지 확인하는 상황입니다.
12TB HDD 네 개의 RAID 5를 사용합니다.
계산상 데이터 용량은 36TB입니다.
기존 데이터를 유지하면서 RAID 5를 SHR-1로 직접 변경합니다.
DSM의 Change RAID Type에서 현재 RAID 5에서 SHR-1로의 변경 경로가 지원되는지 확인합니다.
지원되는 RAID 유형 변경은 정해진 경로만 제공되며 RAID 5에서 SHR로의 직접 변경은 포함되지 않습니다.
12TB HDD 네 개로 SHR-1을 새로 구성하면 계산상 데이터 용량은 36TB가 될 수 있습니다.
그러나 신규 SHR-1의 계산값이 기존 RAID 5와 같다는 사실은 기존 스토리지 풀을 SHR로 직접 변환할 수 있다는 의미가 아닙니다.
해당 직접 변경 경로는 지원되지 않습니다.
SHR을 사용하려면 다른 스토리지 풀이나 다른 NAS에 SHR을 새로 구성해 데이터를 이전하거나, 전체 백업 후 기존 RAID 5 스토리지 풀을 제거하고 SHR을 새로 구성해야 합니다.
대상 NAS가 SHR을 지원하는지 확인한 뒤 별도 SHR 스토리지 풀을 구성해 데이터를 이전합니다.
같은 NAS에서 재구성해야 한다면 전체 백업과 복원 가능성, 임시 저장 공간과 서비스 중단 범위를 먼저 확보합니다.
REDUCING DRIVE COUNT WITH LARGER DRIVES
더 큰 HDD로 교체해 저장 용량을 유지하거나 늘리면서, 기존 SHR의 HDD 수를 줄여 빈 베이를 확보할 수 있는지 검토하는 상황입니다.
6베이 이상 Synology NAS에서 8TB HDD 여섯 개의 SHR-1을 사용합니다.
계산상 데이터 용량은 40TB입니다.
이를 16TB HDD 네 개의 SHR-1로 변경해 빈 베이 두 개를 확보하려고 합니다.
현재보다 계산상 저장 용량을 늘리면서 사용 HDD 수를 여섯 개에서 네 개로 줄여 빈 베이 두 개를 확보합니다.
16TB HDD 네 개로 신규 SHR-1을 구성할 수 있는지 확인하는 것과 현재 6디스크 스토리지 풀의 멤버 수를 줄일 수 있는지는 별개의 문제입니다.
Synology는 기존 스토리지 풀의 드라이브 수를 줄이는 기능을 지원하지 않으며, 드라이브 수를 줄여야 한다면 데이터를 백업하고 기존 스토리지 풀을 제거한 뒤 원하는 구성으로 새로 만드는 절차를 안내합니다.
현재 6×8TB SHR-1의 계산상 데이터 용량은 40TB입니다.
4×16TB SHR-1을 새로 구성하면 계산상 데이터 용량은 48TB입니다.
하지만 이것은 서로 다른 두 스토리지 풀 구성의 계산을 비교한 것입니다.
기존 6디스크 SHR-1에서 HDD 두 개를 제거하면서 그대로 4디스크 SHR-1로 축소하는 직접 변경 경로는 지원되지 않습니다.
원하는 4×16TB 구성으로 바꾸려면 기존 데이터를 다른 저장소에 확보한 뒤 기존 스토리지 풀을 제거하고 새 SHR을 구성해 복원해야 합니다.
따라서 충분한 임시 저장 공간, 백업 검증, 복원 시간과 서비스 중단 범위를 함께 계획해야 합니다.
전체 데이터를 수용할 백업 공간이나 필요한 중단 시간을 확보하기 어렵다면 기존 6디스크 스토리지 풀을 유지하면서 더 큰 HDD로 순차 교체해 용량만 확장하는 방법을 검토할 수 있습니다.
다만 이 방법은 HDD 수가 여섯 개로 유지되므로 빈 베이 두 개를 확보한다는 원래 목표는 충족하지 못합니다.
빈 베이 확보가 반드시 필요하다면 새 4디스크 스토리지 풀 구성과 데이터 복원 또는 다른 NAS로의 이전을 검토해야 합니다.
더 큰 HDD를 사용해 저장 용량을 늘리는 것과 기존 스토리지 풀의 드라이브 수를 줄여 빈 베이를 확보하는 것은 서로 다른 목표입니다.
해당 직접 변경 경로는 지원되지 않으므로 빈 베이가 필요하면 신규 구성과 데이터 이전 또는 복원을 검토합니다.
공식 참고자료: DSM 7.4 Storage Management 기술 사양
05B / QNAP QTS
05 공통 안내를 전제로 하며, 이 영역은 QTS 5.2 계열을 우선 기준으로 작성합니다. 현재 검증 기준점은 QTS 5.2.10.3577 build 20260731입니다.
실제 지원 여부는 NAS 모델, 설치된 QTS 버전, RAID 유형과 상태, 스토리지 풀과 볼륨 구성, 사용 가능한 드라이브와 확장 장치에 따라 달라질 수 있습니다. 사례 오른쪽의 QTS 5.2 배지는 해당 사례의 검증 기준을 표시하며 모든 모델에서 동일한 작업을 지원한다는 의미는 아닙니다.
SINGLE TO RAID 1
QNAP NAS를 HDD 한 개로 사용하고 있으며, 디스크 장애에 대비해 두 번째 HDD 추가를 검토하는 상황입니다.
2베이 이상 QNAP NAS에서 12TB HDD 한 개를 Single 구성으로 사용합니다. 계산상 데이터 용량은 12TB입니다.
기존 데이터를 유지하면서 HDD 한 개 장애에 대응하는 RAID 1을 구성합니다.
QTS에서 Single → RAID 1 RAID Migration을 사용할 수 있어야 합니다. 12TB HDD 한 개를 사용 가능한 드라이브로 준비합니다. 추가 HDD의 용량은 기존 RAID 그룹에서 가장 작은 HDD 이상이어야 하며, Migration에 선택한 HDD의 기존 데이터는 삭제됩니다.
QTS 5.2.x는 Single에서 RAID 1로의 Migration을 공식 지원합니다.
12TB HDD 두 개의 RAID 1이 되며 계산상 데이터 용량은 12TB로 유지됩니다. 두 번째 HDD는 동일 데이터를 보호하는 미러 역할을 하므로 HDD 수가 두 배가 되어도 저장 가능한 계산상 데이터 용량은 두 배로 증가하지 않습니다.
새 HDD 구입과 RAID Migration 작업이 발생합니다. Migration을 시작하면 RAID 그룹 상태가 Rebuilding...으로 변경되고, 작업 완료 후 Ready로 돌아옵니다.
현재 구성에서 직접 Migration을 사용할 수 없다면 RAID 1을 새로 구성할 수 있는 저장소에 데이터를 이전하거나, 별도 백업과 복원 가능성을 확보한 뒤 RAID 1을 새로 구성하는 방법을 검토합니다.
RAID 1 TO RAID 5
RAID 1을 사용하고 있지만 저장 공간이 부족해져 HDD를 추가하면서 RAID 5로 변경하려는 상황입니다.
4베이 QNAP NAS에서 12TB HDD 두 개의 RAID 1을 사용합니다. 계산상 데이터 용량은 12TB이며 12TB HDD 한 개를 추가할 수 있다고 가정합니다.
RAID 변경 완료 후에도 HDD 한 개 장애에 대응하면서 저장 용량을 늘립니다.
QTS에서 RAID 1 → RAID 5 Migration을 사용할 수 있어야 합니다. 이 사례에서는 12TB HDD 한 개를 추가 드라이브로 준비합니다. 추가 HDD는 기존 RAID 그룹의 가장 작은 HDD 이상이어야 하며, 선택한 HDD의 기존 데이터는 삭제됩니다.
12TB HDD 세 개의 RAID 5가 완성되면 계산상 데이터 용량은 (3 - 1) × 12TB = 24TB가 됩니다.
계산상 데이터 용량은 12TB에서 24TB로 증가합니다. Migration 중에는 RAID 그룹이 Rebuilding 상태가 되므로, 변경 작업 완료와 Ready 상태 복귀를 확인한 뒤 후속 작업을 판단합니다.
추가 HDD를 준비할 수 없거나 현재 구성에서 Migration을 사용할 수 없다면 대용량 HDD를 활용하는 신규 구성이나 다른 저장소에 RAID 5를 구성해 데이터를 이전하는 방법을 비교합니다.
RAID 5 TO RAID 6
저장 용량 증가보다 HDD 두 개 장애에 대응하는 보호 수준이 필요해 RAID 6 변경을 검토하는 상황입니다.
4베이 이상 QNAP NAS에서 12TB HDD 세 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 24TB이며 12TB HDD 한 개를 추가할 수 있다고 가정합니다.
HDD 한 개 장애에 대응하는 RAID 5에서 HDD 두 개 장애에 대응하는 RAID 6로 변경합니다.
QTS에서 RAID 5 → RAID 6 Migration을 사용할 수 있어야 합니다. 새 12TB HDD를 사용 가능한 드라이브로 준비한 뒤 Migrate RAID Group 과정에서 선택합니다.
12TB HDD 네 개의 RAID 6가 완성되면 계산상 데이터 용량은 (4 - 2) × 12TB = 24TB입니다. 용량은 그대로지만 변경 완료 후 장애 허용 범위는 HDD 한 개에서 두 개로 강화됩니다.
HDD 한 개가 추가되고 Migration 작업이 발생하지만 저장 용량 증가 효과는 없습니다.
직접 Migration을 사용할 수 없다면 현재 NAS가 RAID 6 신규 구성을 지원하는지 별도로 확인합니다. RAID 6 신규 구성을 지원한다면 백업과 복원 공간을 확보한 뒤 새로 구성하는 방법을 검토하고, RAID 6 자체를 지원하지 않는 장비라면 지원 가능한 NAS로 이전합니다.
RAID GROUP DISK ADDITION
저장 공간이 부족하지만 현재 RAID 5는 유지하면서 빈 베이에 HDD를 추가하려는 상황입니다.
6베이 QNAP NAS에서 12TB HDD 세 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 24TB입니다.
RAID 5와 HDD 한 개 장애 대응을 유지하면서 저장 용량을 늘립니다.
확장할 RAID 그룹의 상태가 Ready여야 합니다. 추가 HDD는 기존 RAID 그룹과 같은 드라이브 유형이어야 하며, HDD RAID 그룹에는 HDD를 사용합니다. 추가 HDD의 용량은 기존 그룹에서 가장 작은 HDD 이상이어야 합니다. 확장 대상으로 선택한 HDD의 기존 데이터는 삭제됩니다.
QTS는 RAID 1, RAID 5, RAID 6, RAID 50, RAID 60 그룹의 디스크 추가 확장을 지원합니다.
12TB HDD 한 개를 추가하고 RAID Rebuilding이 정상 완료되면 네 개 RAID 5의 계산상 데이터 용량은 (4 - 1) × 12TB = 36TB가 됩니다.
계산상 데이터 용량은 24TB에서 36TB로 증가하지만 RAID 5의 HDD 한 개 장애 대응 수준은 그대로입니다. Rebuilding이 완료된 후 스토리지 풀 용량이 증가합니다. Thick Volume이나 Thin Volume을 사용하는 경우 새로 확보된 공간을 볼륨에도 할당해야 하는지는 별도로 확인합니다.
RAID 그룹이 Ready가 아니거나 새 HDD가 유형 또는 용량 조건을 충족하지 못하면 확장을 진행하지 않습니다. 빈 베이가 있다는 이유만으로 HDD가 기존 RAID 그룹에 자동으로 편입되는 것도 아닙니다. 대용량 HDD 교체, 새 RAID 그룹 추가, 다른 NAS 이전을 비교합니다.
REPLACE DISKS ONE BY ONE
모든 베이를 사용하고 있어 HDD를 추가할 수 없지만 기존 RAID 5를 유지하면서 더 큰 HDD로 순차 교체하려는 상황입니다.
4베이 QNAP NAS에서 8TB HDD 네 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 24TB입니다. 12TB HDD 네 개로 순차 교체한다고 가정합니다.
HDD 수와 RAID 5를 유지하면서 계산상 데이터 용량을 36TB로 늘립니다.
지원되는 RAID 유형에서 Replace Disks One by One 절차를 사용합니다. RAID 그룹에 할당된 Hot Spare 또는 Global Hot Spare가 있다면 공식 절차에 따라 먼저 해제 여부를 확인합니다. 새 HDD는 교체 대상 HDD보다 큰 용량이어야 합니다.
HDD 한 개를 교체한 뒤 RAID Rebuilding이 완료될 때까지 기다리고, 정상 상태를 확인한 뒤 다음 HDD를 교체합니다. 모든 RAID 멤버를 더 큰 HDD로 교체한 뒤 마지막으로 Expand Capacity를 실행해야 합니다.
QNAP은 이 절차를 RAID 1, RAID 5, RAID 6, RAID 10에서 지원합니다.
| 완료 단계 | HDD 구성 | RAID 계산상 데이터 용량 |
|---|---|---|
| 시작 | 8TB + 8TB + 8TB + 8TB | 24TB |
| 일부 HDD 교체 완료 | 12TB와 8TB 혼합 | 24TB 기준 |
| 전체 교체 및 Expand Capacity 완료 | 12TB + 12TB + 12TB + 12TB | 36TB |
RAID의 최종 용량은 가장 작은 RAID 멤버 HDD를 기준으로 하므로 일부 HDD만 12TB로 교체한 상태에서는 최종 36TB를 사용할 수 없습니다.
네 차례의 HDD 교체와 반복되는 RAID Rebuilding이 필요합니다. 각 단계가 정상적으로 끝난 것을 확인하고 다음 HDD로 넘어갑니다. 모든 HDD가 큰 용량으로 바뀌었다는 사실과 최종 Expand Capacity 작업까지 완료했다는 사실도 구분해야 합니다.
남은 HDD의 상태가 좋지 않거나 반복되는 Rebuilding의 부하와 시간을 감당하기 어렵다면 더 큰 HDD로 새 RAID를 구성한 별도 NAS 또는 저장소로 데이터를 이전하는 방법을 비교합니다.
FULL BAY RAID 6 ALTERNATIVES
모든 베이를 RAID 5가 사용하고 있지만 HDD 두 개 장애에 대응하기 위해 RAID 6로 보호 수준을 높이려는 상황입니다.
QTS 5.2 환경의 4베이 NAS에서 12TB HDD 네 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 36TB입니다.
새 저장소로 이전해야 할 실제 데이터가 십진수 기준 28TB라고 가정합니다. 향후 증가량과 스냅샷, 운영 여유는 포함하지 않은 값입니다.
RAID 5를 RAID 6로 변경해 HDD 두 개 장애에 대응합니다.
QTS의 RAID 5에서 RAID 6 Migration에는 사용 가능한 추가 HDD가 필요합니다. 이 사례에서는 모든 베이를 사용하고 있으며 지원되는 다른 추가 HDD 편입 수단도 사용할 수 없다고 가정합니다.
따라서 현재 RAID 그룹에서는 해당 온라인 Migration 경로를 사용할 수 없습니다.
같은 12TB HDD 네 개로 RAID 6를 새로 구성하면 계산상 데이터 용량은 (4 - 2) × 12TB = 24TB입니다.
이 값은 기존 RAID 5의 온라인 변경 결과가 아니라 신규 RAID 6 구성의 계산입니다. 또한 계산상 24TB는 이전 대상 28TB보다 작으므로 동일 HDD 네 개의 신규 RAID 6도 전체 데이터를 수용하지 못합니다.
기존 장비를 비우고 RAID 6를 새로 구성하려면 이전 데이터를 보관할 임시 저장소와 복원 계획이 필요합니다. 최종 저장소는 현재 데이터뿐 아니라 향후 증가량과 운영 여유까지 수용할 수 있어야 합니다.
보호 수준을 RAID 6로 높인다는 목표를 유지하면서 더 큰 HDD 또는 더 많은 베이의 NAS를 비교합니다.
예를 들면 신규 구성 기준으로:
실제 장비의 HDD 지원과 최종 가용 용량은 별도로 확인합니다.
DEGRADED RAID AND EXPANSION
RAID 5의 HDD 한 개가 고장 난 상태에서 장애 HDD 교체와 저장 용량 확장을 함께 검토하는 상황입니다.
6베이 QNAP NAS에서 12TB HDD 네 개의 RAID 5를 사용합니다. 정상 구성의 계산상 데이터 용량은 36TB입니다.
현재 HDD 한 개 장애로 RAID 그룹과 해당 스토리지 풀이 Degraded 상태라고 가정합니다. QTS는 장애 수가 RAID 유형의 허용 범위 안에 있으면 이 상태에서도 데이터가 계속 접근 가능할 수 있다고 안내합니다.
추가 HDD를 장착할 베이는 남아 있습니다.
현재 데이터의 보존 가능성을 확인하고 RAID 그룹을 정상 상태로 복구한 뒤, 조건을 충족하면 HDD 한 개를 추가해 용량을 확장합니다.
Degraded RAID 그룹은 Rebuild RAID Group을 이용해 복구합니다. 하지만 기존 RAID 그룹에 HDD를 추가하는 확장 작업은 그룹 상태가 Ready여야 합니다.
따라서 Degraded 상태에서 용량 확장을 먼저 진행하지 않습니다.
적절한 12TB HDD로 RAID Rebuilding을 완료해 RAID 그룹이 Ready로 복구되면 계산상 데이터 용량은 36TB입니다.
그 뒤 12TB HDD 한 개를 추가하고 확장이 완료되면 다섯 HDD RAID 5의 계산상 데이터 용량은 (5 - 1) × 12TB = 48TB가 됩니다.
HDD 한 개가 이미 실패한 RAID 5는 데이터에 접근할 수 있더라도 추가 HDD 장애를 허용하는 보호 여유가 없습니다. 상담 단계에서는 백업 상태, 데이터 접근 가능 여부와 남아 있는 HDD 상태를 확인한 뒤 Rebuild를 진행할지, 필요한 데이터를 먼저 확보할지 판단합니다.
남은 HDD에서도 오류나 불안정 징후가 확인되고 별도 데이터 사본이 없다면 Rebuild를 자동적인 첫 단계로 보지 않고 데이터 확보 또는 복구 가능성을 먼저 검토합니다. RAID가 정상화된 후 용량 확장을 별도로 판단합니다.
POOL EXPANDED, THICK VOLUME UNCHANGED
RAID 그룹 확장 후에도 Thick Volume의 용량이 그대로여서 추가 공간을 할당하는 방법을 확인하는 상황입니다.
12TB HDD 세 개의 RAID 5를 사용하며 계산상 데이터 용량은 24TB입니다. 스토리지 풀 안에 18TB가 할당된 Thick Volume이 있다고 가정합니다. 여기에 12TB HDD 한 개를 추가합니다.
RAID와 스토리지 풀 확장으로 확보한 새 공간을 기존 Thick Volume에서도 사용할 수 있도록 합니다.
먼저 RAID Rebuilding과 스토리지 풀 확장이 정상 완료됐는지 확인합니다.
QTS에서 Static Volume의 부모 저장공간은 RAID 그룹이며, Thick Volume과 Thin Volume의 부모는 스토리지 풀입니다. Thick Volume은 부모 스토리지 풀의 여유 공간 범위에서 별도로 크기를 늘릴 수 있습니다.
QTS의 Volume 확장 절차는 Action > Resize Volume을 사용합니다.
RAID 5의 계산상 데이터 용량은 24TB → 36TB로 증가합니다.
하지만 18TB는 Thick Volume 할당량이므로 RAID 계산값과는 다른 값입니다. 스토리지 풀에 새 여유 공간이 생겼더라도 기존 Thick Volume이 자동으로 전체 공간을 사용하는 것으로 판단하지 않고 필요한 경우 별도로 Resize합니다.
다음 세 가지를 각각 확인해야 합니다.
따라서 HDD 추가 후 공유폴더 용량이 그대로인 상황이 RAID 확장 실패를 의미하는 것은 아닐 수 있습니다.
스토리지 풀에 실제 여유 공간이 부족하다면 다른 볼륨, 스냅샷 예약 공간 등 Pool 사용 상태를 먼저 확인합니다.
EXISTING RAID GROUP VS NEW RAID GROUP
기존 RAID 그룹의 HDD보다 큰 HDD를 추가할 때 기존 그룹에 편입할지, 새 RAID 그룹으로 만들어 같은 스토리지 풀에 추가할지 비교하는 상황입니다.
6베이 이상 QNAP NAS에서 8TB HDD 세 개의 RAID 5를 사용합니다. 기존 RAID 그룹의 계산상 데이터 용량은 (3 - 1) × 8TB = 16TB입니다.
새로 16TB HDD 세 개를 준비했다고 가정합니다.
새 HDD 용량을 활용하면서 기존 스토리지 공간을 확장합니다.
QTS는 스토리지 풀 확장 방법으로 다음 두 가지를 제공합니다.
두 방식은 최종 용량과 장애 영향 범위가 다르므로 단순히 TB 수치만 비교하지 않습니다.
16TB HDD 세 개를 기존 8TB RAID 5 그룹에 편입하면 가장 작은 8TB HDD가 용량 계산의 기준이 됩니다.
(6 - 1) × 8TB = 40TB
반면 16TB HDD 세 개를 별도의 RAID 5로 만들면 신규 RAID 그룹의 계산상 데이터 용량은 (3 - 1) × 16TB = 32TB입니다.
기존 RAID 그룹 16TB와 새 RAID 그룹 32TB를 같은 스토리지 풀에 포함하면 계산상 데이터 용량 합계는 48TB입니다.
새 RAID 그룹을 추가하면 서로 다른 HDD 용량을 더 효율적으로 사용할 수 있지만 장애 영향 범위가 커질 수 있습니다.
QTS는 여러 RAID 그룹을 포함하는 스토리지 풀에 데이터를 선형적으로 기록하며, RAID 그룹 하나가 실패하면 해당 스토리지 풀의 모든 데이터가 손실될 수 있다고 공식적으로 경고합니다.
따라서 40TB와 48TB라는 계산값만으로 선택하지 않습니다.
한 RAID 그룹의 장애가 다른 데이터까지 영향을 주는 구조를 원하지 않는다면 새 RAID 그룹을 기존 스토리지 풀에 합치는 대신 별도의 스토리지 풀이나 다른 NAS로 구성하는 방식을 비교합니다.
HOT SPARE AND CAPACITY
RAID 장애에 대비할 Hot Spare를 추가할 때 저장 용량도 함께 늘어나는지 확인하는 상황입니다.
5베이 이상 QNAP NAS에서 12TB HDD 네 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 36TB이며 빈 베이에 12TB HDD 한 개를 추가한다고 가정합니다.
RAID 멤버 HDD가 고장 났을 때 자동으로 대체해 Rebuilding을 빠르게 시작할 수 있는 대기 HDD를 확보합니다.
12TB HDD를 기존 RAID 그룹의 Hot Spare로 지정합니다. Hot Spare로 선택한 HDD의 기존 데이터는 삭제됩니다.
QTS의 Hot Spare는 정상 상태에서는 사용되지 않고 데이터를 저장하지 않습니다. RAID 멤버가 실패하면 Hot Spare가 결함 HDD를 자동으로 대체하고 RAID Rebuilding이 시작됩니다.
데이터 멤버는 기존 12TB HDD 네 개 그대로이므로 RAID 5의 계산상 데이터 용량은 36TB로 유지됩니다. 추가한 12TB Hot Spare는 정상적인 데이터 용량 계산에 포함되지 않습니다.
HDD 한 개와 베이 한 개를 추가로 사용하지만 평상시 저장 용량은 증가하지 않습니다.
또한 Hot Spare를 추가했다고 RAID 5가 RAID 6처럼 동시에 두 HDD 장애를 허용하는 RAID 유형으로 바뀌는 것도 아닙니다. Hot Spare의 역할은 장애 발생 후 교체와 Rebuilding 시작을 자동화하고 지연 시간을 줄이는 데 있습니다.
저장 용량 증가가 목적이라면 Hot Spare가 아니라 기존 RAID 그룹에 데이터 멤버로 HDD를 추가할 수 있는지 확인합니다. 장애 후 빠른 자동 대응이 우선이면 Hot Spare 구성을 검토합니다.
RAID 50 AND RAID 60 EXPANSION
여러 하위 그룹으로 구성한 RAID 50 또는 RAID 60에서 남은 베이에 HDD를 추가해 저장 용량을 늘리려는 상황입니다.
8베이 QNAP NAS에서 12TB HDD 여섯 개의 RAID 50을 사용한다고 가정합니다. 두 개의 3디스크 RAID 5 하위 그룹으로 구성되어 있으므로 계산상 데이터 용량은 (3 - 1) × 12TB × 2 = 48TB입니다.
빈 베이는 두 개입니다.
아래 용량 계산은 RAID 50 예시입니다. RAID 60도 모든 하위 그룹을 동일한 수의 HDD로 확장해야 한다는 조건은 같지만, RAID 6 기반 하위 그룹이므로 용량 계산은 다릅니다.
RAID 50 구조를 유지하면서 12TB HDD 두 개를 추가해 저장 용량을 늘립니다.
확장 대상 RAID 그룹의 상태가 Ready여야 합니다. 추가 HDD는 기존 그룹과 같은 HDD 또는 SSD 유형이어야 하며, 가장 작은 기존 HDD 이상의 용량이어야 합니다.
QTS는 RAID 50 또는 RAID 60을 HDD 추가 방식으로 확장할 때 모든 하위 그룹을 동일한 수의 HDD로 확장해야 한다고 명시합니다.
따라서 한 하위 그룹에만 HDD 하나를 추가해서 끝내지 않습니다.
각 3디스크 RAID 5 하위 그룹에 12TB HDD 한 개씩 추가하면 각 하위 그룹은 4디스크 RAID 5가 됩니다.
계산상 데이터 용량은 (4 - 1) × 12TB × 2 = 72TB입니다. 따라서 전체 계산상 데이터 용량은 48TB에서 72TB로 증가합니다.
일반 RAID 5 하나를 확장하는 것과 달리 RAID 50과 RAID 60은 하위 그룹 구성을 함께 확인해야 합니다. QTS는 각 하위 그룹에 대해 확장 작업을 반복하도록 안내합니다.
빈 베이가 한 개뿐이거나 모든 하위 그룹을 같은 수만큼 확장할 수 없다면 이 방식으로 확장하지 않습니다. 더 큰 HDD로 교체하는 방법, 다른 저장소 추가, 장비 확장을 비교합니다.
RAID 50과 RAID 60은 빈 베이 한 개에 HDD를 추가해 임의의 하위 그룹만 확장하는 방식으로 처리하지 않습니다.
REDUCING RAID MEMBER COUNT
더 큰 HDD로 교체해 저장 용량을 유지하거나 늘리면서, 기존 RAID 그룹의 HDD 수를 줄여 빈 베이를 확보하려는 상황입니다.
6베이 이상 QNAP NAS에서 8TB HDD 여섯 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 (6 - 1) × 8TB = 40TB입니다.
이를 16TB HDD 네 개의 RAID 5로 변경해 빈 베이 두 개를 확보하려고 합니다.
저장 용량을 유지하거나 늘리면서 RAID 멤버 수를 여섯 개에서 네 개로 줄여 빈 베이 두 개를 확보합니다.
4×16TB RAID 5를 새로 구성할 수 있는지와 기존 6디스크 RAID 그룹을 4디스크로 축소할 수 있는지는 서로 다른 문제입니다.
QNAP은 RAID 그룹이 구성된 이후에는 Spare를 제외하고 RAID 그룹의 HDD 수를 줄일 수 없다고 명시합니다.
현재 6×8TB RAID 5의 계산상 데이터 용량은 40TB입니다.
4×16TB RAID 5를 신규 구성하면 (4 - 1) × 16TB = 48TB입니다.
하지만 이 값은 새로운 RAID 그룹을 만들었을 때의 계산입니다. 기존 6디스크 RAID 5에서 HDD 두 개를 제거하면서 그대로 4디스크 RAID 5로 축소하는 직접 변경 경로는 지원되지 않습니다.
원하는 4×16TB 구성을 만들려면 데이터를 외부에 백업하고 기존 볼륨과 스토리지 풀을 제거한 뒤, 적은 HDD 수로 새 스토리지 구성을 만든 다음 데이터를 복원해야 합니다.
충분한 백업 공간이나 서비스 중단 시간을 확보하기 어렵다면 기존 6디스크 RAID 5를 유지하면서 모든 HDD를 더 큰 용량으로 순차 교체해 용량만 늘리는 방법을 검토할 수 있습니다.
예를 들어 여섯 HDD를 모두 16TB로 바꾸고 확장을 완료하면 계산상 데이터 용량은 (6 - 1) × 16TB = 80TB가 될 수 있습니다.
하지만 HDD 여섯 개를 계속 사용하므로 빈 베이 두 개를 확보한다는 원래 목표는 달성하지 못합니다. 빈 베이 확보가 반드시 필요하면 신규 RAID 구성과 데이터 이전 또는 다른 NAS로의 이전을 검토합니다.
더 큰 HDD로 저장 용량을 늘리는 것과 기존 RAID 그룹의 멤버 수를 줄여 빈 베이를 확보하는 것은 서로 다른 목표입니다.
해당 직접 축소 경로는 지원되지 않으므로 빈 베이가 필요하면 신규 구성과 데이터 이전 또는 복원을 검토합니다.
05C / QNAP QuTS hero
05 공통 안내를 전제로 하며, 이 영역은 QuTS hero h6.0 계열을 우선 기준으로 작성합니다. 현재 검증 기준점은 h6.0.2.3591 build 20260819입니다.
QuTS hero는 ZFS 기반이므로 QTS와 화면이나 용어가 비슷하더라도 RAID 확장 방식, RAID 유형 변경 조건, 대용량 HDD 교체 후 용량 확장, Shared Folder 구조가 다를 수 있습니다. 실제 지원 여부는 NAS 모델, 설치 버전, RAID 유형, 스토리지 풀 상태, 사용할 수 있는 HDD와 확장 장치에 따라 달라질 수 있습니다. 사례 오른쪽의 QuTS hero h6.0 배지는 해당 사례의 검증 기준을 표시하며 모든 모델에서 동일한 작업을 지원한다는 의미는 아닙니다.
RAID 1 TO TRIPLE MIRROR
HDD 두 개의 RAID 1에 세 번째 HDD를 추가할 때 저장 용량과 장애 보호가 어떻게 달라지는지 확인하는 상황입니다.
12TB HDD 두 개의 RAID 1을 사용합니다. 계산상 데이터 용량은 12TB입니다.
세 번째 12TB HDD를 추가해 두 개의 HDD 장애에도 대응할 수 있는 구성을 만듭니다.
현재 QuTS hero 기능표는 RAID 1에서 RAID Triple Mirror로 변경할 때 HDD 한 개를 추가하는 경로를 명시합니다. Triple Mirror는 동일 데이터의 사본을 세 HDD에 저장하는 구성입니다.
12TB HDD 세 개의 Triple Mirror가 되면 계산상 데이터 용량은 12TB로 유지됩니다. HDD를 한 개 추가했지만 저장 공간 증가가 목적이 아니라 장애 허용 수준이 높아지는 구성입니다.
RAID 1은 HDD 한 개 장애에 대응하지만 Triple Mirror는 HDD 두 개 장애에 대응할 수 있습니다. 따라서 세 번째 HDD를 추가했다고 RAID 5처럼 저장 용량이 증가한다고 판단하지 않습니다.
저장 용량 증가가 주목적이라면 Triple Mirror가 요구에 맞는지 다시 판단하고, RAID 5 계열이나 다른 스토리지 풀 구성 등 지원되는 대안을 검토합니다.
QuTS hero에서 RAID 1에 세 번째 HDD를 추가하는 사례는 단순 용량 확장과 보호 수준 강화 중 무엇을 원하는지 먼저 구분해야 합니다.
RAID 5 DISK ADDITION
기존 RAID 5의 보호 수준은 유지하면서 빈 베이에 HDD 한 개를 추가해 저장 용량을 늘리려는 상황입니다.
12TB HDD 세 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 24TB입니다.
RAID 5를 유지하면서 12TB HDD 한 개를 추가해 저장 용량을 늘립니다.
QuTS hero h6.0에서는 기존 RAID 그룹에 HDD를 추가하는 확장을 공식 지원합니다.
대상 스토리지 풀의 상태가 Ready 또는 Warning (Threshold Reached)여야 하며, 추가 HDD는 기존 RAID 그룹과 같은 HDD 또는 SSD 유형이어야 합니다. 용량은 기존 그룹의 가장 작은 HDD 이상이어야 하고 선택한 HDD의 기존 데이터는 삭제됩니다.
잠긴 Shared Folder, LUN 또는 Snapshot Vault가 있는 스토리지 풀에서는 해당 확장을 진행할 수 없습니다.
12TB HDD 한 개를 추가하고 RAID Rebuilding이 완료되면 (4 - 1) × 12TB = 36TB의 계산상 데이터 용량이 됩니다. 따라서 24TB에서 36TB로 증가합니다.
확장 중에도 스토리지 풀은 온라인 상태로 접근할 수 있지만 RAID Rebuilding이 수행됩니다. Pool의 저장 용량은 Rebuilding 완료 후 증가합니다.
Pool 상태, HDD 유형, 용량 또는 잠금 상태 때문에 기존 RAID 그룹에 HDD를 추가할 수 없다면 더 큰 HDD로의 순차 교체나 새 RAID 그룹 추가 방식을 비교합니다.
과거 QuTS hero 버전의 확장 제한을 현재 h6.0에 그대로 적용하지 않습니다. 현재 QuTS hero는 기존 RAID 5 또는 RAID 6 그룹에 단일 HDD를 추가하는 확장을 공식 지원합니다.
RAID 5 TO RAID 6
RAID 5를 사용하고 있지만 두 HDD 장애에 대응하는 보호 수준이 필요하고, 남은 베이를 활용해 용량도 함께 늘리려는 상황입니다.
12TB HDD 세 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 24TB입니다.
RAID 6로 보호 수준을 높이면서 저장 용량도 늘립니다.
현재 QuTS hero 기능표는 RAID 5(Z)에서 RAID 6(Z2)로 변경할 때 최소 HDD 두 개를 추가하도록 안내합니다. 이 조건은 QTS의 RAID 5에서 RAID 6 사례와 다르므로 QTS 절차를 그대로 적용하지 않습니다.
12TB HDD 세 개의 RAID 5에 12TB HDD 두 개를 추가해 다섯 HDD RAID 6가 완성되면 (5 - 2) × 12TB = 36TB입니다.
계산상 데이터 용량은 24TB에서 36TB로 증가하고, 최종 구성에서는 HDD 두 개 장애에 대응합니다.
이 사례에서는 보호 수준 증가와 저장 용량 증가가 동시에 발생합니다. 따라서 QTS의 3×12TB RAID 5 → 4×12TB RAID 6 = 24TB 사례와 동일하게 설명하면 안 됩니다.
추가 HDD 두 개를 준비할 수 없거나 모델과 현재 Pool 조건에서 변경 경로를 사용할 수 없다면 RAID 6 신규 구성과 데이터 이전 또는 다른 장비로의 이전을 검토합니다.
RAID 6 TO RAID-TP
중요 업무 데이터를 저장하는 환경에서 RAID 6보다 더 높은 장애 허용 수준이 필요해 RAID-TP를 검토하는 상황입니다.
12TB HDD 네 개의 RAID 6를 사용합니다. 계산상 데이터 용량은 24TB입니다.
최대 세 HDD 장애에 대응하는 RAID-TP로 보호 수준을 높입니다.
현재 QuTS hero 기능표는 RAID 6(Z2)에서 RAID-TP(Z3)로 변경할 때 최소 HDD 두 개를 추가하도록 명시합니다.
RAID-TP는 세 HDD 상당 용량을 패리티에 사용하며 세 HDD 장애를 허용하는 QuTS hero 특화 RAID 구성입니다.
12TB HDD 네 개 RAID 6에 12TB HDD 두 개를 추가해 여섯 HDD RAID-TP가 되면 (6 - 3) × 12TB = 36TB의 계산상 데이터 용량입니다.
기존 24TB에서 36TB로 증가하면서 최종 장애 허용 범위는 세 HDD로 강화됩니다.
RAID-TP는 높은 보호 수준을 제공하지만 패리티에 사용하는 공간도 커집니다. 따라서 단순히 HDD를 많이 사용할수록 좋은 구성으로 판단하지 않고 업무 중요도, 필요한 용량, 베이 수와 향후 확장을 함께 검토합니다.
RAID-TP 변경에 필요한 HDD와 베이를 확보할 수 없다면 기존 RAID 6 유지, 더 많은 베이 장비 이전 또는 별도 RAID-TP 신규 구성을 비교합니다.
LARGER DRIVE REPLACEMENT
모든 베이를 사용 중이어서 HDD를 추가할 수 없지만 기존 RAID 그룹과 스토리지 풀을 유지하면서 더 큰 HDD로 용량을 확장하려는 상황입니다.
8TB HDD 네 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 24TB입니다. 12TB HDD 네 개로 순차 교체한다고 가정합니다.
RAID 5와 HDD 수를 유지하면서 계산상 데이터 용량을 36TB로 늘립니다.
QNAP의 공식 절차는 QuTS hero h5.3.0 이상에 적용되므로 h6.0도 포함됩니다.
먼저 Hot Spare가 있다면 일시적으로 비활성화합니다. 기존 HDD보다 큰 HDD를 준비하고 한 번에 한 HDD씩 교체합니다. 각 HDD를 교체한 뒤 RAID Rebuilding이 완료되고 RAID 그룹이 정상 상태로 복귀한 것을 확인한 뒤 다음 HDD를 교체합니다.
Rebuilding 중 다른 HDD를 제거하면 데이터 손실 또는 손상이 발생할 수 있으므로 다음 교체는 반드시 현재 Rebuilding 완료 후 진행합니다.
| 완료 단계 | HDD 구성 | 계산상 데이터 용량 |
|---|---|---|
| 시작 | 8TB + 8TB + 8TB + 8TB | 24TB |
| 일부 HDD 교체 완료 | 12TB와 8TB 혼합 | 24TB 기준 |
| 마지막 HDD Rebuild 완료 | 12TB + 12TB + 12TB + 12TB | 36TB |
마지막 HDD의 Rebuilding이 완료되면 RAID 그룹과 부모 스토리지 풀이 확장됩니다.
QTS 사례와 가장 중요한 차이가 있습니다. QTS에서는 모든 HDD 교체 후 Expand Capacity를 별도로 실행하는 절차가 있지만, 현재 QuTS hero의 공식 절차에서는 마지막 HDD Rebuild 완료 후 RAID 그룹과 부모 스토리지 풀이 확장됩니다.
남은 HDD 상태가 불안정하거나 반복적인 Rebuilding 작업을 감당하기 어렵다면 더 큰 HDD로 새로운 스토리지 풀을 구성해 데이터를 이전하는 방법을 검토합니다.
EXPAND RAID GROUP VS ADD RAID GROUP
빈 베이와 추가 HDD가 여러 개 있을 때 기존 RAID 5를 크게 만들지, 새로운 RAID 5 그룹을 만들어 기존 스토리지 풀에 추가할지 비교하는 상황입니다.
12TB HDD 세 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 24TB입니다. 추가로 12TB HDD 세 개를 사용할 수 있다고 가정합니다.
저장 용량을 늘리면서 향후 보호 구조와 확장 방식을 결정합니다.
QuTS hero h6.0에서는 기존 RAID 그룹에 HDD를 추가하는 방식과 새 RAID 그룹을 기존 스토리지 풀에 추가하는 방식을 모두 공식 지원합니다.
새 RAID 그룹은 기존 스토리지 풀의 RAID 그룹과 같은 RAID 유형이어야 합니다. h6.0 공식 절차는 RAID 5 풀에 RAID 5 그룹을 추가하면 풀 RAID 유형이 RAID 50으로, RAID 6 풀에 RAID 6 그룹을 추가하면 RAID 60으로 변경된다고 안내합니다.
추가 HDD 세 개를 기존 RAID 5에 모두 편입하면 (6 - 1) × 12TB = 60TB의 단일 RAID 5 계산상 데이터 용량입니다.
반대로 12TB HDD 세 개로 별도 RAID 5를 만들면:
h6.0 공식 절차 기준으로 후자는 RAID 50 Pool 구조가 됩니다.
두 방식은 단순 용량 차이만 있는 것이 아닙니다. 기존 그룹에 모두 넣으면 계산상 용량 효율은 높지만 하나의 큰 RAID 5 그룹이 됩니다. 새 RAID 5 그룹을 추가하면 계산상 용량은 줄지만 여러 RAID 5 하위 그룹을 사용하는 구조를 검토하게 됩니다.
따라서 Rebuild 범위, 장애 허용 구조, 성능과 향후 확장을 함께 판단해야 합니다.
대상 모델이나 현재 스토리지 풀에서 새 RAID 그룹 추가 조건을 충족하지 못하면 기존 RAID 그룹 확장, 별도 스토리지 풀 구성 또는 다른 NAS로의 이전을 비교합니다.
POOL EXPANDED, THICK SHARED FOLDER UNCHANGED
RAID 그룹 확장 후에도 Thick Shared Folder의 최대 용량이 그대로여서 추가 공간을 할당하는 방법을 확인하는 상황입니다.
12TB HDD 세 개의 RAID 5를 사용합니다. 계산상 데이터 용량은 24TB입니다. 부모 스토리지 풀 안에 18TB로 설정된 Thick Shared Folder가 있다고 가정합니다. 12TB HDD 한 개를 RAID 5에 추가합니다.
스토리지 풀 확장으로 확보한 공간을 기존 Thick Shared Folder에서도 사용할 수 있도록 합니다.
QuTS hero h6.0에서 Thick Shared Folder는 생성 시 부모 스토리지 풀의 공간을 미리 할당받습니다. Thin Shared Folder는 실제 데이터가 기록될 때 공간을 할당합니다.
따라서 RAID와 스토리지 풀이 확장됐다고 Thick Shared Folder가 자동으로 Pool 전체 용량을 사용한다고 판단하지 않습니다. QNAP의 QuTS hero h6.0 공식 절차에서는 Resize Shared Folder를 이용해 Thick Shared Folder에 부모 스토리지 풀의 추가 여유 공간을 할당할 수 있습니다.
RAID 5 확장 완료 후 계산상 데이터 용량은 24TB → 36TB로 증가합니다.
그러나 18TB는 Thick Shared Folder의 할당 용량이므로 RAID 계산값과는 별도입니다. Pool에 충분한 여유 공간이 있다면 Shared Folder를 별도로 Resize해 용량을 늘립니다.
QuTS hero에서는 다음 값을 서로 구분해야 합니다.
또한 ZFS 스냅샷과 시스템 예약 공간 등이 있기 때문에 RAID 단순 계산값 전체를 Shared Folder에 그대로 할당할 수 있다고 판단해서는 안 됩니다.
부모 스토리지 풀의 실제 여유 공간이 부족하면 Shared Folder 크기를 먼저 늘리는 것이 아니라 Snapshot 예약, 다른 Shared Folder, Pool 사용량 등을 확인합니다.
DEGRADED RAID AND EXPANSION
RAID 5의 HDD 한 개가 고장 난 상태에서 장애 HDD 교체와 추가 HDD를 통한 용량 확장을 함께 검토하는 상황입니다.
6베이 QNAP NAS에서 QuTS hero를 사용하며 12TB HDD 네 개의 RAID 5를 구성합니다. 정상 상태의 계산상 데이터 용량은 36TB입니다.
현재 RAID 멤버 한 개가 실패해 RAID 그룹이 Degraded 상태라고 가정합니다.
기존 데이터의 보존 가능성을 확인한 뒤 RAID 그룹을 정상화하고, 조건을 충족하면 12TB HDD 한 개를 추가해 용량을 확장합니다.
QuTS hero h6.0은 RAID 그룹 상태를 Online, Degraded, Rebuilding, Failed 등으로 구분합니다. Degraded는 실패하거나 연결이 끊긴 HDD 수가 아직 해당 RAID 그룹의 장애 허용 범위 안에 있는 상태입니다.
반면 기존 RAID 그룹에 HDD를 추가하는 Pool 확장은 스토리지 풀이 Ready 또는 Warning (Threshold Reached) 상태여야 합니다. 따라서 장애 상태에서 용량 확장을 먼저 진행하지 않습니다.
장애 HDD를 정상 HDD로 교체하고 RAID Rebuilding이 완료되어 RAID 그룹이 정상 상태로 복구되면 계산상 데이터 용량은 36TB입니다.
그 뒤 12TB HDD 한 개를 기존 RAID 5에 추가하고 확장 작업이 완료되면 (5 - 1) × 12TB = 48TB의 계산상 데이터 용량이 됩니다.
HDD 한 개가 고장 난 RAID 5는 장애 허용분을 이미 사용하고 있으므로 정상 확장보다 데이터 보존과 RAID 복구 판단이 우선입니다. 장애 HDD와 남은 HDD, 백업 상태를 확인하고 적절한 교체와 Rebuilding으로 RAID 그룹을 정상 상태로 복구한 뒤 스토리지 풀 확장을 별도 작업으로 검토합니다.
남은 HDD에서도 이상 징후가 확인되거나 데이터 백업이 확보되지 않았다면 무조건 Rebuild부터 시작하지 않고 데이터 확보와 복구 가능성을 먼저 검토합니다.
또한 Recover Storage Pool은 실제 HDD 고장을 복구하기 위한 일반적인 Rebuild 기능으로 사용하지 않습니다. QNAP은 이 기능이 일시적인 HDD 제거 또는 SATA 연결 끊김 후 재연결된 경우에 도움되며 실제 디스크 고장에는 도움이 되지 않는다고 안내합니다.
RAID가 정상 상태로 돌아온 뒤 용량 확장을 별도 작업으로 판단합니다.
06 / WORK DECISIONS
현재 상태에 따라 출발점이 다릅니다. 정상 저장소의 계획 변경과 이미 경고 또는 접근 이상이 있는 저장소를 하나의 순차 절차로 취급하지 않습니다.
06A / PLANNED CHANGE
지유넷은 보호할 기존 데이터가 있는 계획된 RAID 변경, 확장과 재구성에서 백업과 복원 가능성을 먼저 확인하는 것을 작업 원칙으로 삼습니다. 기존 데이터를 유지하는 온라인 변경도 이 확인에 포함합니다.
현재 상태가 정상인 저장소를 대상으로, 백업 확인 → 대상과 디스크 조건 확인 → 지원 절차 실행 → 작업 중 상태 확인의 순서로 진행 여부를 판단합니다. 경고나 접근 이상이 있는 저장소는 아래의 별도 판단 흐름을 따릅니다.
| 준비 항목 | 기록하거나 확인할 내용 | 충족하지 못했을 때 |
|---|---|---|
| 현재 구성 식별 | NAS와 OS, 대상 풀과 볼륨, RAID, 디스크 모델과 일련번호, 베이 위치 | 대상이 명확해질 때까지 변경을 실행하지 않습니다. |
| 백업과 복원 범위 | 필요한 파일, 설정, 권한과 업무 데이터, 암호화 키, 시험 복원 결과 | 계획된 RAID 변경, 확장과 재구성을 보류하고 백업 및 복원 조건부터 보완합니다. |
| 추가 또는 교체 디스크 | 공식 호환성, 용량, 인터페이스와 섹터 형식 등 해당 OS의 요구 조건, 기존 데이터 유무 | 적합한 디스크를 확보하거나 다른 구성안을 선택합니다. |
| 작업 시간과 전원 | 업무 부하, 작업 시간대, 전원 장애 대응, 알림 수신 담당자 | 감시와 대응이 가능한 일정으로 조정합니다. |
| 목표 구성과 서비스 전환 | 변경 후 RAID와 용량, 접근 경로, 앱과 백업의 변경 사항 | 데이터와 서비스 이전 계획을 먼저 보완합니다. |
06B / DEGRADED STORAGE
이미 장애가 발생한 저장소는 계획된 변경과 구분하고 데이터 보존 가능성을 먼저 판단합니다. 현재 상태와 오류 기록, 남은 디스크와 별도 사본을 확인한 뒤 다음 교체, 재구축 또는 복구 방향을 정합니다.
아래 항목은 증상에 따른 판단 기준이며, 순서대로 악화되는 단계표가 아닙니다. RAID 그룹, 스토리지 풀, 볼륨과 공유폴더 중 어디에 경고가 표시됐는지 먼저 구분합니다. DSM 7 계열 도움말, QTS 5.2.x와 QuTS hero h6.0.x 문서의 예시를 함께 보되, 같은 증상이라도 모델과 OS 버전에 따라 원인과 복구 조건이 다를 수 있습니다.
현재 데이터 접근, 별도 사본과 남은 디스크 상태를 함께 확인합니다. 문제 디스크의 모델과 일련번호, 베이 위치, 읽기 오류와 최근 분리 및 교체 이력을 기록합니다. 관리 화면의 표시 하나만으로 재구축 성공을 보장하지 않습니다.
Degraded는 스토리지 풀의 보호가 저하된 상태입니다. Repair 적용 조건을 확인하되, 추가 디스크 이상이 의심되면 다음 교체와 확장을 보류하고 데이터 확보를 우선할지 판단합니다.
RAID 그룹의 Degraded는 장애 디스크 수가 허용 범위 안에 있지만 모든 장애 디스크를 대체할 예비 디스크가 충분하지 않은 상태로 설명합니다.
RAID 그룹의 Degraded와 상위 풀의 Warning (Degraded)를 구분합니다. 그룹의 장애 또는 연결 끊김이 허용 범위 안인지, 재구축이 이미 진행 중인지 확인합니다.
쓰기가 제한된 대상과 원인을 확인하고, 접근 가능한 데이터의 별도 확보를 우선 검토합니다. 읽기 전용 표시만으로 고장 디스크를 정하거나 교체를 계속하지 않습니다.
볼륨 Read-only는 드라이브나 파일 시스템 문제뿐 아니라, 이전한 볼륨의 기능을 현재 모델 또는 OS가 지원하지 않아 발생할 수도 있습니다. 호환성 문제와 하드웨어 이상을 구분합니다.
Warning (Degraded - Readonly)는 디스크 교체로 RAID 그룹이 비활성화될 수 있어, 디스크 변경 전에 다른 장치로 데이터를 확보하도록 안내합니다. 이 FAQ의 적용 대상은 QTS와 QuTS hero이며, 실제 경고 문구에 해당하는지 확인합니다.
풀 상태표의 Read Only는 읽기만 가능한 상태를 뜻합니다. 이 표시만으로 위 FAQ의 특정 RAID 경고와 원인까지 같다고 판단하지 않고, 그룹 상태와 로그를 함께 확인합니다.
일반적인 재구축이나 새 풀 생성으로 시작하지 않습니다. 원래 디스크 구성과 분리 이력을 보존하고, 네트워크 및 권한 문제인지 저장소 자체의 장애인지 구분합니다. 초기화 전에 백업, 제조사 지원과 데이터 복구 필요성을 확인합니다.
풀의 Crashed는 Degraded에 사용하는 일반 Repair 절차와 구분해 장애 원인 및 지원 안내를 확인합니다. Crashed라는 표시만으로 모든 데이터가 복구 불가능하다고 단정하지 않습니다.
RAID 그룹 Not Active는 상태표에서 장애 허용 범위 초과로 설명합니다. QNAP 장애 FAQ는 자동 조립 실패와 디스크별 RAID 정보 불일치 가능성도 안내하므로 실제 원인을 구분합니다.
RAID 그룹의 Failed와 상위 풀의 Error를 확인합니다. QTS의 Not Active와 같은 이름으로 바꾸어 설명하거나 동일한 복구 절차를 적용하지 않습니다.
관리 화면 접속, 공유폴더 열림과 필요한 데이터의 정상 읽기는 각각 확인할 대상입니다.
일시적인 연결 끊김과 실제 디스크 고장을 구분합니다. 원래 베이 위치, 모델과 일련번호, 분리 시점과 직전 작업을 기록합니다. 재장착 여부와 전원 조건은 해당 모델의 공식 안내로 판단합니다.
분리 후의 풀과 볼륨 상태를 각각 확인합니다. Degraded의 Repair 조건과 Crashed의 장애 대응을 구분하고, 원래 구성과 분리 이력을 제조사 지원 판단에 전달합니다.
일시적인 분리나 SATA 연결 문제로 RAID 그룹 Error, 풀 및 볼륨 Inactive가 된 경우에는 원래 디스크와 베이를 대조하고 RAID Recovery 조건을 확인합니다. 복구 후 재구축이 시작될 수 있어 이후 상태도 확인합니다.
일시적으로 분리된 디스크를 원래 베이에 다시 연결하는 경우의 Recover Storage Pool 조건을 확인합니다. QTS와 QuTS hero의 연결 복구 기능은 물리적으로 고장 난 디스크를 고치는 기능이 아닙니다.
06C / DURING WORK
계획된 변경이나 재구축을 시작한 뒤 새로운 디스크 오류 또는 상태 변화가 나타났다면, 오류 시점과 대상 디스크, 현재 진행 상태를 기록하고 다음 작업의 진행 여부를 다시 판단합니다.
| 관찰한 상황 | 다음 작업 판단 | 우선 확인할 내용 |
|---|---|---|
| 추가 디스크 경고 또는 읽기 오류 | 다음 디스크 교체와 새 변경 작업을 보류합니다. | 오류 시점과 대상 디스크, 남은 디스크 상태, 데이터 접근과 별도 사본을 확인합니다. |
| 읽기 전용 전환 또는 새 쓰기 제한 | 기존 교체 절차를 계속 적용하기 전에 원인을 확인합니다. | 제한된 대상과 실제 경고 문구, 접근 가능한 데이터와 확보 방법을 확인합니다. |
| 풀, 볼륨 또는 필요한 데이터에 접근 불가 | 임의 초기화나 새 풀 생성으로 해결하려 하지 않습니다. | 접근 경로와 권한, RAID 및 풀 상태, 원래 디스크 구성과 제조사별 복구 조건을 확인합니다. |
| 재구축 실패 반복 또는 진행 상태 이상 | 새 RAID 작업을 겹쳐 실행하지 않습니다. | 작업 로그와 읽기 오류, 최근 진행 변화와 업무 부하를 확인합니다. 완료 예상시간이 늘었다는 사실만으로 실패를 단정하지 않습니다. |
| 디스크 연결 끊김 또는 재인식 | 일시적인 연결 문제인지 실제 디스크 고장인지 구분합니다. | 연결 이력과 원래 베이, 전원 및 장착 조건을 확인하고 해당 OS의 복구 적용 범위를 판단합니다. |
실제 경고 대상과 OS 버전을 기록한 뒤 06B의 증상별 기준으로 판단합니다. QNAP 공식 안내에서 재구축의 반복 Skip은 추가 불량 디스크 가능성이 있는 별도 확인 항목입니다. 이를 모든 OS의 공통 상태명으로 사용하지 않습니다.
07 / COMPLETION AND OPERATION
RAID 작업이 완료 상태로 표시됐다고 해서 모든 확인이 끝난 것은 아닙니다. 목표한 저장소 구성이 만들어졌는지와 서비스, 데이터와 백업을 실제로 사용할 수 있는지를 나누어 확인합니다.
07A / COMPARISON
저장소 구성, 서비스, 데이터와 백업을 각각 확인하고 검사 범위와 결과를 기록합니다.
| 확인 대상 | 확인 방법과 범위 | 결과에 남길 내용 |
|---|---|---|
| 저장소 구성 | 변경 전후의 디스크, RAID, 스토리지 풀과 볼륨, 사용 가능 용량과 최종 상태를 대조합니다. | 목표 구성과 실제 구성, 확인 시점, 남은 경고와 오류 |
| 서비스 | 합의한 계정과 권한, 공유 접근, 업무 앱과 연결 경로를 확인합니다. | 확인한 계정과 기능, 정상 동작 범위, 미확인 항목 |
| 데이터 | 지정한 데이터의 파일 목록, 개수, 크기, 내용 또는 프로그램별 검사 결과를 비교합니다. | 대상과 기준 시점, 검사 방법, 제외 항목과 발견된 차이 |
| 백업 | 정한 백업 시점의 데이터를 별도 위치에 복원하고 필요한 파일이나 서비스를 실제로 확인합니다. | 복원 시점과 대상, 방법, 소요시간, 성공 및 실패 범위 |
QTS 5.2에서 기존 RAID 그룹에 디스크를 추가해 스토리지 풀을 확장하면 RAID 재구축이 진행되며, 재구축이 완료된 뒤 스토리지 풀 용량이 증가합니다. QTS는 RAID 그룹의 Ready 상태를 정상적으로 동작하는 상태로 별도 정의합니다. 시스템의 작업 완료 상태와 실제 서비스 및 데이터 확인은 각각 기록합니다.
07B / DATA CHECKS
파일 목록, 개수와 크기 비교는 누락이나 크기 차이를 확인하는 데 사용할 수 있습니다. 그러나 이것만으로 파일 내용까지 동일하다고 판단하지 않습니다.
파일 내용 비교가 필요하면 변경 전후의 기준 데이터에 대해 SHA-256과 같은 해시값을 비교할 수 있습니다. 비교 대상과 기준 시점을 먼저 정하고, 작업 중 변경된 파일, 검사하지 않은 파일과 읽지 못한 파일을 별도로 기록합니다.
해시값의 일치는 비교한 데이터의 내용이 같다는 판단 근거입니다. 원본 데이터 자체가 정상인지, 파일 권한이 올바른지, 업무 프로그램에서 정상적으로 사용할 수 있는지까지 확인해 주지는 않습니다. 이미 손상된 원본을 그대로 복사했다면 해시값이 같더라도 정상적인 업무 데이터라는 의미는 아닙니다.
데이터베이스, 가상머신과 업무 애플리케이션 데이터는 단순 파일 비교뿐 아니라 해당 프로그램에서 요구하는 일관성 확인과 실제 복원 또는 동작 확인 방법을 별도로 정합니다.
07C / SCRUBBING
스크러빙은 저장소가 지원하는 범위에서 데이터 일관성이나 오류를 검사하고 복구를 시도하는 기능입니다. 파일 내용의 변경 전후 비교, 업무 데이터의 일관성 확인과 별도 백업의 복원 시험은 각각 구분합니다.
DSM 7 계열은 파일 시스템 스크러빙과 RAID 스크러빙을 구분합니다. Btrfs 공유폴더의 파일 데이터를 체크섬으로 검사하고 복구를 시도하려면 데이터 체크섬 기능이 활성화되어 있어야 합니다.
RAID 스크러빙은 3개 이상 드라이브의 SHR, RAID 5, RAID 6 또는 RAID F1 등 문서에서 정한 구성에 적용합니다. 파일 시스템과 RAID의 지원 조건을 각각 확인합니다.
QTS 5.2.x의 RAID Scrubbing은 RAID 5 또는 RAID 6 그룹의 섹터를 검사하고 발견한 오류의 복구를 시도합니다. 수동 실행 절차는 그룹이 Ready 상태일 것을 요구합니다.
이 결과를 모든 파일의 내용이나 업무 프로그램의 정상 동작까지 확인한 것으로 해석하지 않습니다. 검사 중에는 그룹의 읽기 및 쓰기 성능이 낮아질 수 있습니다.
QuTS hero h6.0.x의 Pool Scrubbing은 풀 안의 각 RAID 그룹의 파일 시스템을 검사하고 불량 블록의 복구를 시도합니다.
QTS의 RAID 5 및 RAID 6 검사 조건을 그대로 옮기지 않습니다. 풀과 그룹의 실제 구성 및 해당 버전의 조건을 확인하고, 성능 영향을 고려해 부하가 적은 시간에 계획합니다.
OS 버전, 대상 풀과 볼륨 또는 공유폴더, 실행한 검사와 발견된 오류 및 미해결 항목을 기록합니다. 스크러빙 완료나 일부 표본 파일의 정상 열림을 전체 파일의 변경 전후 검증 완료로 확대하지 않습니다. 손상 복구 가능 여부와 필요한 과거 사본에서의 복원 가능성은 별도로 확인합니다.
07D / RESULTS
완료 결과에는 저장소 구성, 실제 사용 확인, 미확인 범위와 다음 확장 조건을 구분해 안내합니다.
변경 전후 저장소 구성과 최종 상태, 확인한 서비스와 접근 범위, 데이터 검증 대상과 방법, 백업 복원 시험의 대상과 결과를 기록합니다.
확인하지 않은 데이터나 서비스가 있다면 미확인 범위로 표시하고, 남아 있는 경고, 오류와 제한사항도 함께 기록합니다.
향후 디스크 추가나 교체가 예상된다면 현재 구성에서 가능한 다음 확장 방법과 필요한 조건도 함께 안내합니다.
07E / OPERATION
변경 직후 정상 상태가 확인됐다고 해서 같은 상태가 장기간 유지된다고 가정하지 않습니다. 운영 중 확인할 항목과 담당자를 정하고, 다음 증설이나 교체를 준비할 수 있도록 기준을 남깁니다.
디스크, 저장소와 백업 관련 경고를 누가 확인할 것인지 정하고 실제 알림 수신 여부를 시험합니다.
디스크 상태 경고나 저장 공간 부족 경고가 반복되면 단순히 알림을 해제하기보다 원인을 확인하고 다음 증설이나 교체 판단에 반영합니다.
지원되는 저장소 점검과 데이터 스크러빙은 대상과 수행 주기를 정해 운영합니다.
별도 백업은 백업 작업의 성공 여부와 보존 기간만 확인하지 않고, 필요한 데이터를 실제로 복원할 수 있는지도 확인합니다. 스토리지 자체의 점검과 독립된 백업 사본의 복원 시험은 서로 다른 확인 절차입니다.
현재 빈 베이 수, 사용 중인 디스크 구성, 추가 가능한 디스크 조건, 현재 RAID에서 지원되는 확장 방식과 용량 증가 추세를 기록합니다.
RAID 유형에 따라 빈 베이에 디스크를 추가할 수 있는 방식과 더 큰 디스크로 교체해야 하는 방식이 다릅니다.
Synology DSM은 드라이브 추가, 대용량 교체와 RAID 유형 변경을 구분하며, 각 방법의 지원 RAID 유형과 조건이 다릅니다.
QNAP QTS도 기존 RAID 그룹에 디스크를 추가할 수 있는 RAID 유형, 최대 디스크 수와 추가 디스크 조건을 별도로 정합니다.
다음 확장 가능 여부는 NAS 모델, 운영체제 버전, RAID 유형, 현재 디스크 구성, 빈 베이와 지원되는 드라이브 조건을 함께 확인합니다. 현재 구성에서 확장이 지원되지 않거나 최대 디스크 수에 도달했다면 대용량 교체, 새 스토리지 풀, 지원되는 확장 장치 또는 새 저장소로의 이전을 검토합니다.
업무량이나 데이터 보존 정책이 달라지면 최초 용량 계산도 다시 검토합니다. 여유 공간을 모두 소모한 뒤 대응하는 대신 디스크 조달, 백업, 변경 작업과 검증에 필요한 기간을 고려해 다음 확장을 계획합니다.
08 / QUESTIONS AND ANSWERS
RAID 구성과 변경에서 자주 묻는 질문입니다. 구체적인 적용 조건은 현재 NAS와 운영체제에 해당하는 본문을 함께 확인합니다.
지원되는 경로에는 기존 저장소의 데이터를 유지하는 변경 기능이 있습니다. 모든 RAID 사이에서 가능한 것은 아니며, 새로 편입하는 디스크의 데이터는 삭제되므로 기존 저장소와 추가 디스크를 구분해야 합니다.
현재 RAID와 목표 사이의 지원 경로, NAS 모델, 저장소 상태와 추가 디스크 조건을 확인해야 합니다. 버튼이 없다는 이유로 기존 풀을 삭제하거나 디스크를 임의로 분리하지 않습니다.
QTS 5.2.x의 해당 온라인 변경에는 추가 디스크가 필요합니다. 추가 편입 수단이 없다면 그 경로는 사용할 수 없습니다. 같은 디스크로 새 RAID 6를 만드는 방법은 별도 재구성이며, 줄어든 용량에 기존 데이터를 복원할 수 있는지도 계산해야 합니다.
항상 늘어나지는 않습니다. 일반 RAID의 대용량 교체 확장은 RAID 방식과 기존 용량 조합에 따른 조건을 충족해야 합니다. QTS의 해당 절차는 전체 디스크 교체와 재구축 후 용량 확장을 진행합니다.
해당 NAS와 RAID의 지원 조건부터 확인해야 합니다. 일반 RAID는 작은 디스크를 기준으로 용량이 제한될 수 있으며, SHR의 혼합 용량 활용과 추가 조건은 별도로 확인합니다. 표기 용량을 단순히 모두 더하지 않습니다.
어느 미러 쌍에서 장애가 발생했는지에 따라 다릅니다. 같은 미러 쌍의 두 디스크가 모두 고장 나는 경우를 포함해 임의의 두 개 장애를 항상 허용하는 것은 아닙니다.
빈 베이만으로 판단할 수 없습니다. Synology는 기존 RAID 10 배열에 디스크를 추가하는 확장을 지원하지 않는다고 안내합니다. 대용량 교체 등 다른 확장 방법과 구분해 확인해야 합니다.
Synology는 RAID 1과 SHR 사이의 직접 전환을 지원하지 않습니다. 새 저장소 구성과 이전 또는 백업 후 재구성을 검토하며, 필요한 용량과 복원 계획을 먼저 확보합니다.
일부 온라인 작업에서는 접근이 가능하지만, 이를 평소와 같은 성능이나 무중단 보장으로 해석하지 않습니다. 현재 상태와 업무 부하를 확인하고 큰 작업을 조정하며, 추가 오류가 생기면 다음 변경의 진행 여부를 다시 판단합니다.
소요시간은 디스크와 저장소 조건, 작업 부하에 따라 달라집니다. 진행률 종료 후에도 목표 RAID와 최종 상태, 실제 용량, 서비스와 합의한 데이터 및 백업 확인을 마쳐야 합니다.
NAS STORAGE CONTACT
신규 구성이라면 필요한 데이터량과 업무 조건을 알려주세요. 기존 NAS를 변경하려면 모델과 운영체제, 현재 RAID, 디스크 수와 용량, 사용 중인 베이와 저장소 상태를 준비해 주세요. 경고나 접근 이상이 있다면 나타난 메시지와 디스크 교체 및 분리 이력을 함께 알려주세요. 현재 조건에서 가능한 방향과 필요한 저장 공간, 백업 및 복원 범위를 구분해 상담합니다.