나스의 스냅샷은 얼마나 자주, 얼마나 오래 보관해야 할까?

요즘 출시되는 대부분의 나스(NAS)는 스냅샷(Snapshot)을 지원하는데요, 나스에 스냅샷을 켜려고 하면 두 가지로 고민을 하게 됩니다. 더 촘촘히, 자주 만들고 보관도 오래 할 수록 좋을 것 같은데, 또 너무 스냅샷을 오래 남기다 보면 용량이 부족해지지 않을지 하는 문제입니다.

일반적인 사무용 공유폴더라면 가장 간단하게 1시간마다 생성하고, 7일간 보관하는 정책부터 검토할 만합니다. 저희가 고객사에 NAS를 구축해드릴 때도 기본적으로는 이 설정을 사용합니다.

이 정책이 모든 환경에 권장하는 정답은 아닙니다. 파일이 바뀌는 빈도와 실수를 발견하는 데 걸리는 시간에 맞춰 여기에서 더 조정을 해야합니다. 여기서는 Snapshot Replication을 지원하는 시놀로지 장비의 Btrfs 볼륨에 있는 일반 공유폴더를 기준으로 설명합니다.

생성 간격은 다시 할 수 있는 작업량으로 결정

스냅샷은 폴더를 매번 통째로 복사하는 기능이 아닙니다. 특정 시점의 상태를 남기고, 이후 변경되거나 삭제되는 데이터의 이전 내용을 유지해 그 시점으로 돌아갈 수 있게 합니다. 시놀로지의 공유폴더 스냅샷은 이를 Btrfs에서 제공합니다.

간격을 정할 때 먼저 검토할 것은 "얼마나 다시 작업할 수 있는가"입니다. 이를 복구 시점 목표(RPO)라고 부릅니다. 예를 들어 스냅샷 생성이 1시간 간격이면 정상적으로 생성된 직전 스냅샷으로 복구할 때 최대 약 1시간의 변경을 잃을 수 있습니다.

하루 한 번 새 자료를 받는 폴더라면 수신이 끝난 뒤 생성하는 편이 자연스럽습니다. 반대로 직원이 퇴근한 뒤에만 생성하면 낮 동안 발생한 실수에 되돌아갈 지점이 부족합니다. 대량 변환이나 일괄 정리 직전에는 예약과 별도로 수동 스냅샷을 남기는 방법도 있습니다.

시놀로지 나스에서 지원되는 스냅샷의 최소 간격은 5분이지만, 당연히 스냅샷 생성에도 어느 정도 리소스가 필요하기 때문에 어느 정도는 성능과 타협하는 게 좋습니다. 실제 장비 부하와 생성 성공 여부도 함께 봐야 합니다. 스냅샷 예약을 5분 간격으로 설정했다고 해서 항상 5분 간격 복구 지점이 존재한다고 보장되지는 않습니다.

보관 기간은 실수를 알아차리는 시간

잘못 저장한 직후에 문제를 알았다면 15분 전에 남아있는 기록만 있어도 문제가 없습니다. 그런데 문제가 생긴 지 한 달 뒤에야 빠진 파일을 발견했다면 간격보다 오래 남아 있는 기록이 중요합니다. 생성 간격은 손실량을, 보관 기간은 발견 지연을 상대합니다.

그래서 특수한 보관 정책이 필요한 환경에서는 오래된 기록까지 같은 간격으로 남기기보다 최근 기록은 촘촘하게, 과거 기록은 듬성듬성 보관하는 편이 합리적입니다. 시놀로지 나스의 스냅샷 기능은 Smart Retention 정책을 지원하여, 이와 같이 정책을 설정할 수 있습니다.

Snapshot Replication의 Smart Retention 정책은 이런 계층을 설정하는 기능입니다. 시간·일·주·월 단위에서 각각 마지막 스냅샷을 남깁니다. 같은 스냅샷이 일별 조건과 주별 조건을 동시에 만족하면 두 벌을 만드는 것이 아니라 하나만 보관합니다. 스마트 보관 정책의 동작

다만 이 값은 2일이 지난 다음 30일, 그다음 8주를 차례로 더한다는 뜻이 아닙니다. 각 보관 구간은 서로 겹칩니다. 예상 개수도 단순 합계와 같지 않습니다.

15분마다 스냅샷을 생성하는 작업폴더라면 최근 하루는 전부 남기고, 이후에는 시간별·일별 대표본으로 줄이는 방식도 가능합니다. 변경이 드문 보관폴더는 하루 한 번에 일별 30일·월별 12개월처럼 단순하게 지정해도 됩니다. 월별 기록은 해당 월의 모든 수정 이력을 뜻하지 않으므로, 중간 버전이 필요한 업무에는 일별 보관 기간을 더 길게 잡아야 합니다.

이 정책은 이미 생성한 기록 중 무엇을 남길지 고릅니다. 하루 한 번만 생성하면서 시간별 보관을 설정한다고 시간별 복구 지점이 새로 생기지는 않습니다. 설정 후에는 스냅샷 목록에서 실제 남는 날짜를 확인하는 편이 정확합니다.

용량을 좌우하는 것은 원본 크기보다 바뀌는 방식입니다

10TB 폴더를 30개 시점으로 보관한다고 300TB가 필요한 것은 아닙니다. 스냅샷끼리 바뀌지 않은 데이터를 공유하기 때문입니다. 반대로 "변경분만 보관하니 얼마 들지 않는다"고 예상해서도 안 됩니다.

차이를 만드는 것은 보존 중인 시점 때문에 계속 남아 있어야 하는 이전 데이터 블록입니다. 여기서 블록은 파일을 저장하는 작은 단위입니다. 거의 읽기만 하는 10TB 자료보다, 날마다 수백 GB를 교체하는 1TB 작업폴더의 과거 기록이 더 크게 늘 가능성이 높습니다.

앱의 저장 방식도 영향을 줍니다. 큰 파일의 일부만 고치는 경우와, 저장할 때마다 파일 전체를 새로 쓰는 경우는 같은 "파일 하나 수정"이어도 남겨야 할 이전 데이터가 다릅니다. 매일 통째로 다시 만드는 압축 백업 파일이나 크게 바뀌는 가상 디스크는 스냅샷이 굉장히 큰 용량을 차지할 가능성이 높습니다.

랜섬웨어가 파일을 대량으로 덮어쓰는 경우도 생각해야 합니다. 정상 데이터는 스냅샷에 남고, 암호화된 새 데이터가 현재 폴더에 기록되면서 평소보다 공간 사용이 급격히 커질 수 있습니다. 평상시 증가량만큼의 여유 공간만 남기는 구성은 이 상황을 감당하기 어렵습니다.

그래서 처음에는 기본적으로 권장하는 보관 정책으로 한두 주 운영하며 Snapshot Replication의 크기 계산과 볼륨 사용량을 함께 확인하면 좋습니다. 크기 계산은 최소 7일 범위를 대상으로 하는 추정치이며, 실제 사용량과 정확히 같지는 않습니다. 큰 파일을 정기적으로 교체한다면 그 작업이 포함된 기간을 봐야 합니다.

오래된 스냅샷 하나를 지웠는데 공간이 거의 늘지 않을 수도 있습니다. 같은 블록을 다른 스냅샷이나 현재 파일이 여전히 사용하면 회수할 수 없고, 공간 정리에도 시간이 필요합니다. "하나를 지우면 원본 한 벌만큼 비워진다"는 방식으로 계산하면 맞지 않고, 실제 변경 지점까지 필요한 데이터의 양으로 계산해야 합니다.

불변 보호 기간은 보관 기간과 별개입니다

일반 스냅샷을 오래 남기도록 설정해도, 이를 삭제할 수 있는 관리 권한을 공격자가 확보하면 보호가 약해집니다. 그래서 저희가 항상 관리자 계정의 보안을 중요하게 안내해 드리고 있습니다. 변경할 수 없는 스냅샷(Immutable Snapshot)은 지정한 기간 동안 삭제·변경을 막는 기능입니다. DSM 7.2 이상과 지원 모델이 필요하며, Btrfs를 쓰는 모든 장비에서 다 가능한 건 아닙니다. 지원 모델 목록

만약 변경할 수 없는 스냅샷을 설정한다면, 불변 보호 기간으로 7~14일을 권장합니다. 변경할 수 없는 스냅샷 기간은 스냅샷의 보관 기관과 별도로 관리할 수 있기 때문에, 예를 들어 처음 14일은 삭제할 수 없게 보호하고 보호가 끝난 뒤에도 월별 보관 규칙에 해당하는 기록은 더 오래 남길 수 있습니다.

불변 보호 기간 중인 스냅샷은 스마트 보관 정책으로도 미리 지울 수 없습니다. 생성 간격과 곱해 보면 예상하지 못한 제한이 드러납니다.

• 1시간 간격으로 14일 보호하면 약 336개입니다.
• 15분 간격으로 14일 보호하면 약 1,344개입니다.

현재 시놀로지 나스의 스냅샷 개수 제한은 공유폴더당 1,024개이고, 모델에 따라 더 낮을 수 있습니다. 따라서 두 번째 조합은 이 상한부터 넘습니다. 여기에 보호 기간 밖의 장기 보관 기록이나 수동 기록도 더해집니다. 짧은 생성 간격과 긴 불변 보호를 따로 결정하지 말고, 모델의 개수 제한과 실제 여유 공간까지 한 번에 맞춰야 합니다. 위 숫자는 시간 기반 단순 계산이며 실제 목록에는 경계 시점 등에 따른 차이가 있습니다.

불변 보호는 공간이 부족해져도 필요에 따라 바로 해제할 수 없습니다. 보호 중인 스냅샷을 포함한 저장공간의 삭제도 제한됩니다. 예를 들어 공유폴더 A에 변경할 수 없는 스냅샷이 남아있다면 해당 공유 폴더를 삭제하는 것 자체가 불가능합니다. 만약 꼭 변경할 수 없는 스냅샷을 지정하려면 처음부터 긴 기간을 지정하기보다 변경량과 개수를 계산한 뒤 적용하는 게 좋습니다. 일반 스냅샷의 잠금은 보관 정책에 의한 자동 삭제를 막는 옵션으로, 변경할 수 없는 스냅샷과는 다르며, 관리자 권한이 있다면 누구든 삭제 가능합니다.

스냅샷으로 되돌릴 수 있는 범위

같은 볼륨의 스냅샷은 빠른 파일 복구에는 유용하지만, 그 볼륨 자체가 손실되면 함께 사용할 수 없게 됩니다. 그리고 스냅샷이 나스 자체의 도난이나 화재를 해결하지도 못합니다.

다른 나스로 복제하면 장비 장애에 대한 보호를 추가할 수 있습니다. 원격 복제도 백업 전략의 일부로 활용할 수 있지만, 같은 장소에 두거나 같은 관리 권한으로 둘 다 지울 수 있다면 재해·침해에 대한 방어가 불가능하다는 점은 동일합니다. 오프사이트 복사본과 대상의 보관·접근 정책까지 함께 설계하는 이유입니다.

데이터베이스나 가상 머신을 저장하는 폴더는 또 다른 확인이 필요합니다. 파일시스템의 한 시점을 남겼다는 사실이 실행 중인 앱의 정상 복구까지 보장하지는 않습니다. 메모리에만 있던 변경이나 여러 파일에 걸친 쓰기를 앱과 조정하지 않으면, 갑자기 전원이 꺼진 상태와 비슷한 복구가 필요할 수 있습니다. 데이터베이스나 가상 머신 등의 경우 해당 앱에서 제공하는 자체 백업 기능을 사용하는 것이 가장 좋습니다. 지원되는 애플리케이션 일관성(Application Consistency) 절차로 데이터를 정리하는 것도 좋습니다. 시놀로지의 LUN용 일관성 옵션도 지원 환경의 시놀로지 저장소 콘솔 연동이 전제입니다.

사무용 폴더라면 우선 1시간 간격과 7일 보존으로 시작하고, 되돌려야 할 작업량이 크면 간격을 줄이면 됩니다. 누락을 늦게 발견하는 자료는 보관 기간을 늘리는 쪽이 맞습니다. 이후에는 스냅샷 개수만 보는 대신 원하는 날짜의 파일을 실제로 열어 복원할 수 있는지, 그리고 그 기록을 유지할 공간이 남는지 확인합니다.

스냅샷 주기와 보관 기간, 별도 백업까지 함께 정하기 어렵다면 현재 사용하는 나스와 자료의 종류를 알려 주시면 됩니다. 나스 구축이나 기존 장비의 유지보수 상담은 아래에서 요청하실 수 있습니다.