볼륨 섀도 복사본(VSS)의 구조와 실무 ── 사용 중 파일의 백업은 왜 가능한가

‘다른 앱이 열어 둔 파일을 복사하려 했더니 「프로세스가 파일에 액세스할 수 없습니다」라는 경고가 떴다’, ‘기간 시스템을 멈추지 않고 데이터 폴더의 백업을 떠 달라는 요청을 받았다’, ‘백업 소프트웨어는 왜 사용 중인 데이터베이스 파일을 태연하게 복사할 수 있는가’ ── 업무 앱 개발에서도, 파일 서버 운용에서도 조만간 부딪히게 되는 질문입니다.

이 답의 중심에 있는 것이 볼륨 섀도 복사본 서비스(VSS: Volume Shadow Copy Service)입니다. Windows에 20년도 더 전부터 내장되어 있는 구조로, Windows Server Backup도, 시스템 복원도, 시판되는 백업 소프트웨어의 거의 전부가 이 토대 위에 서 있습니다.¹

이 글에서는 ‘사용 중인 파일의 복사 기능’을 요구받는 업무 앱 개발자와, 파일 서버·업무용 PC의 백업을 운용하는 정보 시스템 담당자를 대상으로, VSS의 등장인물과 구조, vssadmin을 이용한 운용 실무, 그리고 ‘개발자는 어디까지 VSS에 관여해야 하는가’라는 판단을, 2026년 8월 시점의 1차 정보를 바탕으로 정리합니다. ‘Windows I/O의 심층’ 연재에서 캐시 매니저와 NTFS의 내부를 살펴보았는데, 이 글은 그 후속편으로서 볼륨 바로 위에 끼어드는 ‘스냅샷’ 계층을 다룹니다.

1. 먼저 결론

• VSS는 ‘앱이 계속 쓰기 중인 볼륨의 백업’을 가능하게 하기 위한 COM 인터페이스 군과 조정 서비스입니다. Windows XP 이후 버전에 내장되어 있습니다.²
• 등장인물은 3가지 역할 + 조정 역할입니다. 섀도 복사본을 요청하는 요청자(백업 소프트웨어), 앱 측에서 데이터의 정합성을 보증하는 라이터(SQL Server 등), 실제로 스냅샷을 만드는 공급자를 VSS 서비스가 중개합니다.¹
• Windows 표준 시스템 공급자는 카피 온 라이트 방식입니다. 볼륨 전체를 복제하는 것이 아니라, 스냅샷 이후 덮어쓰이는 블록만을 덮어쓰기 전에 차분 영역(diff area)으로 대피시킵니다. 차분 영역은 NTFS 볼륨 위에 있어야 합니다.¹
• 정지점은 ‘라이터 프리즈(최대 60초) → 스냅샷 생성(10초 이내) → 해동’의 순서로 만들어집니다. 제한 시간을 초과하면 생성은 중단되고 요청자가 다시 시도합니다.¹
• 라이터의 협력 여부에 따라 복사본의 품질이 달라집니다. 협력 없이 만든 스냅샷은 ‘전원이 끊긴 순간의 디스크’와 동등(크래시 정합), 협력이 있으면 로그 롤이나 캐시 플러시를 마치고 앱 스스로 복구 가능하다고 보증하는 일관 상태(애플리케이션 정합)입니다.³¹
• 운용 확인은 vssadmin으로 합니다. list shadows / list writers / list shadowstorage로 현재 상태를 확인하고, resize shadowstorage로 차분 영역의 상한을 조정합니다. 차분 영역이 바닥나면 오래된 섀도 복사본부터 조용히 삭제됩니다.⁴⁵¹
• 직접 만든 앱에 VSS 요청자를 통합하는 것은 큰 작업입니다. COM 기반의 네이티브 API이며, .NET용 공식 래퍼는 없습니다. 대부분의 경우 재시도·공유 모드 조정·짧은 시간의 정지로 충분하며, 정말로 VSS가 필요하다면 DiskShadow의 스크립트화가 현실적인 해법입니다(Windows Server 한정).⁶⁷
• 섀도 복사본은 백업 그 자체가 아닙니다. 카피 온 라이트의 차분은 원본 볼륨의 손상되지 않은 블록에 의존하므로, 디스크 고장이나 도난처럼 원본 볼륨째로 잃는 장애에는 무력합니다. 랜섬웨어에 대해서도 섀도 복사본 자체의 삭제(7.3)나 대량 덮어쓰기로 인한 차분 영역 고갈(7.4)로 인해 믿을 수 없습니다. 별도 매체로의 백업과 조합해야 비로소 의미를 갖습니다.¹

2. 문제 설정 ── 사용 중인 파일은 왜 그냥 복사할 수 없는가

출발점은 Windows의 파일 공유 모드입니다. Windows에서는 파일을 열 때(CreateFile) ‘자신이 열어 두는 동안 다른 프로세스에 무엇을 허용할 것인가’를 공유 모드(dwShareMode)로 선언합니다. 읽기 공유를 허용하지 않는 방식으로 열어 둔 프로세스가 있는 동안, 나중에 읽기로 열려는 프로세스는 공유 위반(ERROR_SHARING_VIOLATION, 오류 32)으로 실패합니다.⁸ .NET이라면 IOException(‘다른 프로세스에서 사용 중이므로 프로세스가 파일에 액세스할 수 없습니다’)으로 나타나는, 익숙한 오류입니다.

중요한 것은 이것이 버그가 아니라 데이터를 지키기 위한 올바른 구조라는 점입니다. 쓰는 중인 파일을 도중에 읽히면, 읽은 쪽은 ‘쓰다 만 어중간한 상태’를 손에 넣게 됩니다. 배타 제어의 설계는 ‘파일 연계의 배타 제어 기초 지식‘에서 자세히 다룬 대로, 앱 간 연계의 토대입니다.

하지만 이 올바른 구조는 백업과 근본적으로 충돌합니다.

• 공유 위반의 벽: 데이터베이스나 업무 앱이 계속 열어 둔 파일은 애초에 복사 원본으로 열 수 없는 경우가 있습니다.
• 정합성의 벽: 설령 열 수 있더라도(읽기 공유가 허용되어 있더라도) 복사에는 시간이 걸립니다. 복사하는 동안에도 앱은 계속 쓰기 때문에, 파일의 앞부분과 뒷부분이 서로 다른 시점의 내용이 되거나, 여러 파일(데이터 본체와 로그 등) 사이에 앞뒤가 맞지 않게 되기도 합니다. 게다가 ‘캐시 매니저’ 편에서 살펴본 대로, 쓰기는 먼저 메모리상의 캐시에 올라가므로 디스크상의 파일만 봐서는 최신이라고 단정할 수 없습니다.
• 운용의 벽: ‘그렇다면 앱을 멈추고 복사하면 된다’는 옳은 말이지만, 24시간 가동되는 업무 시스템이나 파일 서버에서는 받아들일 수 없습니다.

즉 요구는 ‘앱을 멈추지 않고, 어느 한순간의 정합성 있는 상태의 복사본을 원한다’는 것입니다. 개별 앱이 스스로 해결하기에는 부담이 크고, OS 수준의 구조로 마련된 것이 VSS입니다. VSS는 앱이 볼륨에 계속 쓰는 중에도 볼륨의 백업을 가능하게 하기 위한, COM 인터페이스에 의한 프레임워크로 제공됩니다.²

3. VSS의 등장인물 ── 요청자·라이터·공급자

VSS의 구성은 3가지 역할과 이를 중개하는 서비스로 정리됩니다.¹

역할 분담의 묘미는 서로를 모르는 제품끼리도 협조할 수 있다는 데 있습니다. 백업 소프트웨어(요청자)는 SQL Server의 내부 구조를 알지 못하지만, SQL Server의 라이터가 ‘백업해야 할 파일 그룹(컴포넌트)’을 메타데이터로 신고하고 정지점 생성 전후로 자신의 데이터를 정리해 두므로, 요청자는 그것에 따르기만 해도 정합성 있는 백업을 얻을 수 있습니다.¹⁹ Windows에서 동작하는 서드파티 백업 소프트웨어의 거의 전부가 VSS 요청자입니다.¹

정보 시스템 실무에서 이 세 가지 역할을 의식하게 되는 장면이 트러블슈팅입니다. 백업 소프트웨어의 실패가 요청자(소프트웨어 측)의 문제인지, 특정 라이터(앱 측)의 문제인지, 공급자·차분 영역(기반 측)의 문제인지에 따라 조사해야 할 곳이 완전히 달라집니다(5장·7장).

4. 스냅샷의 구조 ── 카피 온 라이트와 ‘정지점’

4.1. 카피 온 라이트 ── 볼륨을 복제하지 않고 ‘그 순간’을 저장한다

‘스냅샷’이라고 하면 볼륨 전체의 복제를 상상하기 쉽지만, Windows 표준 시스템 공급자가 사용하는 것은 카피 온 라이트(copy-on-write) 방식입니다. 스냅샷 생성 시점에는 거의 아무것도 복사하지 않습니다. 그 후 원본 볼륨의 블록이 덮어쓰일 때, 덮어쓰기가 완료되기 전에 덮어쓰기 전의 블록을 차분 영역(diff area, 섀도 복사본 기억 영역)으로 대피시킨 다음 쓰기를 통과시킵니다.¹ 대피가 필요한 것은 각 블록이 처음 덮어쓰일 때뿐이며, 이미 대피된 블록에 덮어쓰는 경우에는 차분 영역이 늘지 않습니다.

‘그 순간의 볼륨’을 읽고 싶을 때는 변경되지 않은 블록은 원본 볼륨에서, 변경된 블록은 차분 영역에서 읽어 합성합니다. 변경된 부분만 복사하므로 생성은 순식간이고, 소비하는 용량도 차분뿐입니다. 뒤집어 말하면 쓰기가 많은 볼륨일수록 차분 영역의 소비가 빠르며(7장의 복선입니다), 차분 영역은 원본 데이터와 같은 머신의 NTFS 볼륨 위에 놓입니다.¹ 이 구조를 뒷받침하는 것이 시스템 공급자의 구성 파일인 swprv.dll과, 볼륨의 I/O에 끼어드는 드라이버 volsnap.sys입니다.¹ I/O 스택에 ‘어떻게 끼어드는가’에 관심이 있다면 ‘필터 드라이버와 미니필터‘도 참고하시기 바랍니다.

덧붙여 방식에는 이 외에도 미러를 분리하는 완전 복사, 변경 사항을 다른 볼륨에 쓰는 리다이렉트 온 라이트가 있으며, 하드웨어 공급자는 스토리지 장치 측에서 최적의 방식을 사용합니다.¹

4.2. 정지점을 만드는 흐름 ── 프리즈 60초·생성 10초의 협조

카피 온 라이트가 ‘어떻게 저장하는가’라면, VSS의 진가는 ‘언제의 상태를 저장하는가’, 즉 정지점을 만드는 방법에 있습니다. 섀도 복사본 생성은 다음과 같은 흐름으로 진행됩니다.¹

flowchart TB
    R["요청자가 생성을 요청<br/>라이터를 열거하여 메타데이터 수집"] --> M["각 라이터가 백업 대상<br/>컴포넌트를 XML로 신고"]
    M --> P["각 라이터가 데이터를 준비<br/>로그 롤·캐시 플러시 등으로<br/>복구 가능한 일관 상태로 정리"]
    P --> F["라이터의 쓰기 I/O를 프리즈<br/>읽기는 가능. 최대 60초까지"]
    F --> FS["VSS가 파일 시스템 버퍼를 플러시하고<br/>파일 시스템을 동결"]
    FS --> C["공급자가 섀도 복사본을 생성<br/>10초 이내. 이 동안 쓰기 I/O는 동결"]
    C --> T["파일 시스템 해제 → 라이터 해동, thaw<br/>앱은 쓰기를 재개"]
    T --> B["요청자는 섀도 복사본으로부터<br/>시간을 들여 백업을 실행"]

그림 1: 섀도 복사본 생성의 흐름. 멈추는 것은 몇 초에서 몇십 초뿐이며, 백업 본체는 스냅샷에 대해 수행한다

포인트는 3가지입니다.

1. 앱이 멈추는 것은 정지점을 만드는 순간뿐입니다. 프리즈는 60초 이내, 공급자에 의한 생성(커밋)은 10초 이내로 정해져 있으며, 초과하면 생성은 중단되고 요청자가 다시 시도합니다.¹ 몇 시간이나 걸리는 백업 본체는 완성된 읽기 전용 섀도 복사본에 대해, 앱을 계속 가동한 채로 실행됩니다.
2. 프리즈 중에도 읽기는 가능합니다. 멈추는 것은 쓰기 I/O뿐입니다.¹
3. 파일 시스템도 동결됩니다. VSS가 파일 시스템 버퍼를 플러시한 후 동결하므로, 캐시에 올라가 있던 쓰기와 파일 시스템의 메타데이터가 일관된 순서로 스냅샷에 반영됩니다.¹

4.3. 크래시 정합과 애플리케이션 정합

여기서 백업의 품질을 가르는 중요한 구분이 등장합니다.

라이터의 협력 없이 만든 섀도 복사본은 Microsoft의 용어로 크래시 정합(crash consistent) 상태입니다. 공식 정의로는 ‘시스템을 갑자기 종료시키는 치명적 장애 이후에 발견되는 상태와 동등한 디스크 상태’이며, 그 상태로부터의 복원은 ‘갑작스러운 종료 후 재부팅과 동등’하다고 되어 있습니다.³ 파일 시스템으로서는 손상되지 않았지만, 앱 입장에서 보면 ‘쓰는 도중에 전원을 뽑힌 순간’입니다. 트랜잭션 로그로부터의 복구 메커니즘을 가진 데이터베이스라면 대체로 복구할 수 있지만, 복구 처리가 전제 조건이 됩니다.

라이터의 협력이 있으면, 정지점 직전에 각 라이터가 트랜잭션 로그를 롤하고 캐시를 플러시하여, 앱 스스로 ‘여기서부터 올바르게 복구할 수 있다’고 보증하는 일관된 상태로 정리합니다.¹ 이것이 애플리케이션 정합이며, 라이터라는 구조가 존재하는 이유입니다. 주의할 점은 라이터가 보증하는 것은 ‘앱으로서 일관된 복구 가능한 상태’라는 것이지, 실행 중인 트랜잭션을 마음대로 커밋하여 완료시키는 것은 아니라는 점입니다. 커밋되지 않은 작업은 복원 시 롤백됩니다(데이터베이스의 일반적인 복구와 동일한 동작입니다). 라이터는 이 품질 보증을 앱을 멈추지 않고 수십 초의 프리즈만으로 실현합니다.

백업 소프트웨어의 설정에 ‘VSS를 사용한다’, ‘애플리케이션 정합성을 보증한다’ 같은 항목이 있는 것은 이 구분이 드러난 것입니다. 파일 서버상의 단순한 파일 모음이라면 크래시 정합이어도 거의 문제가 되지 않지만, 데이터베이스나 메일 스토어를 안고 있는 서버에서는 해당 라이터가 정상인지 여부가 백업 품질 그 자체가 됩니다.

5. 운용 명령의 실무 ── vssadmin과 ‘이전 버전’

정보 시스템 실무에서 VSS의 상태를 확인하는 도구가 vssadmin입니다(관리자 권한의 명령 프롬프트에서 실행). 현행 명령 참조에서는 list shadows / list writers / delete shadows / resize shadowstorage가 클라이언트·서버 양쪽에서 사용 가능하다고 정리되어 있습니다.⁴ Windows Server 계열 참조에는 이에 더해 create shadow / list shadowstorage / list providers 등이 기재되어 있습니다.⁵ 참고로 vssadmin이 관리할 수 있는 것은 시스템 공급자가 만든 섀도 복사본뿐입니다.¹

list writers의 결과에서 라이터가 오류 상태라면, 의심해야 할 것은 VSS 본체가 아니라 그 라이터를 제공하는 앱 측입니다. 담당 앱의 서비스 상태와 애플리케이션/시스템 이벤트 로그를 확인합니다(7장).

resize shadowstorage의 /maxsize에는 KB/MB/GB 등의 단위를 붙여 상한을 지정할 수 있으며, 지정하지 않으면 무제한이 됩니다. 주의해야 할 점은 기억 영역의 상한 변경, 특히 축소 자체가 섀도 복사본의 소실을 일으킬 수 있다고 명기되어 있다는 것입니다.¹⁰ 세대를 남기고 싶은 볼륨의 상한을 가볍게 줄여서는 안 됩니다.

5.1. ‘이전 버전’과의 관계

파일 서버에서 ‘공유 폴더의 섀도 복사본(Shadow Copies of Shared Folders)’을 활성화하면, 공유상의 파일이 특정 시점의 복사본으로 정기적으로 보관되어 사용자는 삭제·덮어써 버린 파일을 관리자의 도움 없이 ‘이전 버전’에서 복원할 수 있습니다.¹ 헬프데스크 공수를 확실히 줄일 수 있는, VSS의 가장 친숙한 응용입니다.

다만 상한이 있습니다. 시스템 공급자의 섀도 복사본은 볼륨당 최대 512개까지이며, 그중 공유 폴더의 섀도 복사본 기능이 기본값으로 유지하는 것은 64개까지입니다(레지스트리의 MaxShadowCopies로 변경 가능).¹ 그리고 다음 장 이후에서 서술하듯, 차분 영역이 부족하면 오래된 세대부터 자동으로 삭제됩니다. ‘몇 세대가 남는가’는 설정한 세대 수가 아니라 쓰기 양과 차분 영역의 크기로 결정된다고 이해해 두는 것이 안전합니다.

6. 개발자로서의 관여 방식 ── 직접 만든 앱에 VSS가 필요한가

여기서부터는 개발자의 시점입니다. ‘사용 중인 파일도 복사할 수 있는 백업 기능을 넣어 달라’는 요청을 받았을 때, VSS와 어떻게 관계를 맺어야 할까요.

6.1. 요청자를 직접 만드는 것은 큰 작업

VSS의 API는 요청자·라이터 모두 COM 및 C++ 인터페이스로 제공됩니다(요청자의 중심은 IVssBackupComponents입니다).⁶ .NET용 공식 래퍼는 제공되지 않으며, 라이터의 메타데이터 수집부터 스냅샷 세트의 관리, 오류 발생 시의 뒷정리까지를 올바르게 구현해야 하므로, 업무 앱의 기능 하나로 가볍게 넣을 수 있는 것이 아닙니다. 저희도 수탁 개발 견적에서는 ‘VSS 요청자의 자체 구현’을 독립된 개발 항목으로 취급합니다.

현실적인 해법은 2가지입니다. 첫째, 기존의 VSS 대응 백업 소프트웨어에 맡기는 것. 둘째, Windows Server라면 DiskShadow를 스크립트로 사용하는 것입니다. DiskShadow는 OS에 동봉된 VSS 요청자로, 대화형 모드 외에 스크립트 모드(diskshadow /s script.txt)를 가지고 있으며, 섀도 복사본의 생성, 드라이브 문자로의 공개(expose), 복사 처리를 수행하는 배치의 실행(exec), 뒷정리까지를 스크립트 하나로 기술할 수 있습니다.⁷¹ ‘섀도 복사본을 만든다 → 거기서 직접 만든 복사 처리로 파일을 빼낸다 → 삭제한다’는 흐름을, COM을 한 줄도 쓰지 않고 구성할 수 있습니다. 다만 DiskShadow는 Windows Server 전용이며 클라이언트 OS에는 포함되지 않습니다.¹ 클라이언트 PC도 대상으로 하는 요건이라면, 이 시점에서 기존 백업 소프트웨어의 채택 쪽으로 기울게 됩니다.

6.2. 애초에 VSS가 필요한가 ── 판단표

경험상 ‘사용 중인 파일의 복사’에 관한 상담의 대부분은 VSS 없이 해결할 수 있습니다. 요구의 수준을 가늠한 후에 도구를 선택하시기 바랍니다.

6.3. 직접 만든 앱은 라이터 등록을 해야 하는가

반대 방향의 질문, ‘직접 만든 업무 앱은 VSS 라이터를 제공해야 하는가’도 정리해 두겠습니다. 라이터를 작성해 두면 고객이 어떤 백업 소프트웨어를 사용하든 자사 앱의 데이터를 애플리케이션 정합으로 백업받을 수 있습니다. 참고로 일반 라이터보다 간단한 익스프레스 라이터(IVssExpressWriter)라는 구조도 있지만, 이것은 ‘어떤 파일을 대상/제외로 할 것인가’라는 메타데이터의 선언을 등록하는 것뿐입니다.⁶ 프리즈/해동 등의 통지는 받지 않으므로, 스냅샷 생성에 맞추어 앱의 쓰기를 정지시키는 것은 불가능합니다. 익스프레스 라이터를 사용해도 되는 경우는 쓰는 도중에 스냅샷이 찍혀도 손상되지 않는(크래시 정합으로 충분한) 저장 설계와 짝을 이룰 때뿐이며, 정지점에서의 협조가 필요하다면 일반 라이터 구현이 필요합니다.

그렇다고는 해도 판단 기준은 단순합니다.

• 데이터를 SQL Server 등의 DB에 두고 있다면 불필요합니다. DB 측의 라이터가 정합성을 보증합니다.¹
• 단순한 파일 저장이라면 먼저 저장 처리 측의 설계로 해결합니다. 임시 파일에 다 쓴 다음 이름 변경으로 교체하는 원자적 저장으로 해 두면, 크래시 정합의 스냅샷이라도 ‘손상된 저장 파일’은 남지 않습니다.
• 라이터 등록을 검토할 가치가 있는 것은 여러 파일에 걸친 독자적인 데이터 저장소를 가지고 있으며, 정지점에서 상호 정합이 필요한 앱에 한정됩니다. 그 정도 규모의 데이터를 자체 포맷으로 안고 있는 것 자체를 재검토하는 것이 먼저일 수도 있습니다.

7. 함정 ── 운용에서 실제로 영향을 미치는 4가지

7.1. VSS는 백업 그 자체가 아니다

가장 중요한 함정입니다. 시스템 공급자의 섀도 복사본은 원본 데이터와 같은 머신의 디스크 위에 있는 차분입니다. 차분 영역을 잃으면 합성할 수 없게 되므로, 디스크 고장·머신의 도난 분실·볼륨 전체의 암호화에 대해서는 아무런 보호가 되지 않습니다. Microsoft의 문서도 ‘섀도 복사본에서 테이프 등의 매체로 복사된 내용이 백업이며, 복사 후에는 섀도 복사본을 삭제해도 된다’고 하여 섀도 복사본과 백업을 명확히 구분하고 있습니다.¹ 섀도 복사본은 정지점이며 실수로부터의 신속한 복원 수단이지, 별도 매체·별도 거점으로의 백업을 대체하는 것이 아닙니다.

7.2. 라이터의 오류는 앱 측의 문제

백업 소프트웨어가 ‘VSS 오류’로 실패하는 경우, 먼저 vssadmin list writers로 어떤 라이터가 실패하고 있는지를 특정합니다. 라이터의 실체는 애플리케이션(또는 Windows 구성 요소) 측의 부품이므로¹, 원인 조사의 주된 전장은 담당 앱의 서비스 상태와 이벤트 로그입니다. ‘백업 소프트웨어의 오류’라는 겉모습에 이끌려 백업 소프트웨어 쪽만 계속 조사하면 우회하게 됩니다. 구분의 일반적인 진행 방식은 ‘소스 코드도 사양서도 없는 시스템의 유지보수‘에서도 다룬, ‘관찰 가능한 사실로부터 용의자를 좁혀 나가는’ 방식과 같습니다.

7.3. 랜섬웨어는 섀도 복사본을 지우러 온다

방어 측의 주의 사항으로 알아 두어야 할 사실입니다. ‘이전 버전’으로 되돌릴 수 있다면, 랜섬웨어에 암호화되더라도 되돌릴 수 있지 않을까 ── 라고 기대하고 싶어지지만, 많은 랜섬웨어가 암호화 전후에 섀도 복사본을 삭제하여 이 복원 경로를 없애러 온다는 것이 널리 알려져 있습니다. 섀도 복사본의 삭제는 관리자 권한만 있으면 정규 명령으로 실행할 수 있기 때문에, 침입 이후의 공격자를 막는 최후의 보루가 되지 못합니다. 따라서 대책의 축은 (1) 섀도 복사본을 ‘복구 계획의 일부’가 아니라 ‘있으면 빠르다’ 정도로 자리매김하는 것, (2) 공격자가 도달할 수 없는 오프라인·별도 거점의 백업을 별도로 갖추는 것, (3) 일상 운용 계정에 관리자 권한을 부여하지 않는 것입니다. 백업과 암호화·폐기까지 포함한 PC 라이프사이클의 방어는 ‘BitLocker 실무 가이드’, ‘PC 폐기 체크리스트‘도 함께 참고하시기 바랍니다.

7.4. 차분 영역이 바닥나면 오래된 세대부터 조용히 사라진다

4장에서 살펴본 대로, 카피 온 라이트가 차분 영역을 소비하는 것은 스냅샷 취득 후 각 블록이 처음으로 덮어쓰일 때입니다. 이미 대피된 블록을 몇 번이나 덮어써도 소비는 늘지 않으므로, 소비량은 ‘쓰기 횟수’가 아니라 ‘보관 중인 스냅샷 이후에 덮어쓰인 블록 범위의 넓이‘로 결정됩니다. 그리고 차분 영역이 상한에 도달하면 해당 볼륨의 섀도 복사본은 오래된 것부터 순서대로 삭제됩니다.¹ 대화형 사용자에게는 아무런 통지도 없기 때문에, ‘지난주 판으로 되돌릴 수 있을 것’이라 생각했다가 되돌릴 수 없게 되고 나서야 비로소 발각되는 경우가 많습니다. 다만 완전히 무음은 아니며, System 로그에는 volsnap 소스의 이벤트가 기록됩니다(차분 영역을 확보하지 못해 삭제되었을 때의 25, 확장 실패나 상한 도달로 중단되었을 때의 35/36 등). 정기 확인에 더해 이 volsnap 이벤트를 모니터링·알림 대상에 포함해 두면 소실을 곧바로 알아챌 수 있습니다. 대량의 파일 업데이트·일괄 변환·디스크 조각 모음 같은 ‘볼륨을 넓게 훑는’ 처리가 차분 영역을 단숨에 잡아먹는 것은 이 ‘덮어쓴 범위로 결정된다’는 성질 때문입니다. 보관 세대가 업무 요건(‘오삭제를 알아채는 것이 최장 며칠 후인가’)을 충족하는지, vssadmin list shadowstorage의 사용량을 정기적으로 확인하고 필요하면 상한을 넓히시기 바랍니다.⁵¹⁰

8. 정리

• 사용 중인 파일을 그냥 복사할 수 없는 것은 공유 위반과 정합성의 문제이며, 그것은 데이터를 지키는 올바른 구조입니다. ‘멈추지 않고 정합성 있는 복사본을 원한다’에 대한 OS 수준의 답이 VSS입니다.
• VSS는 요청자(요구)·라이터(정합성 보증)·공급자(생성)의 3가지 역할을 VSS 서비스가 중개하는 틀로, 서로를 모르는 백업 소프트웨어와 업무 앱이 협조할 수 있습니다.
• 시스템 공급자는 카피 온 라이트 방식이며, 정지점은 ‘라이터 프리즈(최대 60초) → 생성(10초 이내) → 해동’으로 만들어집니다. 라이터 협력이 없으면 크래시 정합, 있으면 애플리케이션 정합입니다.
• 운용 확인은 vssadmin(list shadows / list writers / list shadowstorage)으로 합니다. 라이터의 오류는 앱 측을 의심하고, 차분 영역의 사용량은 정기적으로 확인합니다.
• 개발자는 먼저 재시도·공유 모드·정지 시간·연계 설계로 해결할 수 없는지를 판단표로 확인하고, 정말로 필요할 때만 VSS로 갑니다. 자체 구현보다 DiskShadow 스크립트(Server 한정)나 기존 소프트웨어가 현실적인 해법입니다.
• 섀도 복사본은 백업이 아닙니다. 원본 볼륨의 손상되지 않은 블록에 의존하는 차분에 불과하며, 디스크 고장 같은 원본 볼륨의 상실에는 무력하고, 랜섬웨어에 대해서도 섀도 복사본의 삭제나 차분 영역의 고갈로 인해 믿을 수 없습니다. 오프라인·별도 거점의 백업과 조합하시기 바랍니다.

관련 글

• 파일 연계의 배타 제어 기초 지식 - 파일 락과 원자적 claim의 베스트 프랙티스
• Windows I/O의 심층(제4회) ── 캐시 관리자: 당신의 WriteFile은 언제 디스크에 도달하는가
• Windows I/O의 심층(제5회) ── NTFS의 내부 구조: MFT로 이해하는 파일 시스템
• 소스 코드도 사양서도 없는 시스템을 인계받았다면 ── 멈추지 않고 운용·보수하기 위한 실무 절차
• BitLocker 실무 가이드 ── 복구 키 관리로 시작하는 드라이브 암호화
• Windows PC를 폐기하기 전에 해둘 것 ── 데이터 삭제·계정 해제·백업 실무 체크리스트

관련 상담 영역

합동회사 코무라소프트에서는 ‘사용 중인 파일의 복사·백업 기능’을 포함한 업무 앱의 설계·개발, 파일 연계와 관련된 공유 위반이나 백업 실패(VSS 라이터 오류)의 원인 조사, 파일 서버의 백업·세대 관리 운용 정리를 다루고 있습니다. ‘애초에 VSS가 필요한 요건인가’를 가려내는 것부터도 괜찮습니다.

• Windows 앱 개발
• 결함 조사·원인 분석
• 기술 상담·설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

섀도 복사본이 있으면 백업은 필요 없나요?

필요 없어지지는 않습니다. Windows 표준 시스템 공급자가 만드는 섀도 복사본은 카피 온 라이트 방식의 차분으로, '그 시점의 완전한 복제본'을 별도로 가지고 있는 것이 아니라 원본 볼륨의 아직 덮어쓰이지 않은 블록에 의존합니다. 차분 영역(diff area)을 다른 볼륨에 두는 구성으로 만들더라도 원본 볼륨을 잃으면 복원할 수 없다는 사실은 변하지 않으며, 디스크 고장이나 PC의 도난·분실처럼 원본 볼륨째로 잃는 사태에는 무력합니다. 랜섬웨어에 대해서도, 암호화 쓰기 자체는 덮어쓰기 전의 블록을 차분 영역으로 대피시키지만, 실제 공격에서는 섀도 복사본 삭제나 대량 덮어쓰기로 인한 차분 영역 고갈로 잃게 되므로 믿을 수 없습니다. Microsoft의 문서도 섀도 복사본에서 테이프 등의 매체로 데이터를 복사한 것이 백업이며, 복사 후에는 섀도 복사본 자체를 삭제해도 된다고 하여 양자를 구분하고 있습니다. 섀도 복사본은 '백업을 뜨기 위한 정지점'과 '경미한 실수로부터의 신속한 복원 수단'이지, 별도 매체·별도 거점으로의 백업을 대신하는 것이 아닙니다.

직접 만든 업무 앱에서 사용 중인 파일을 복사하고 싶은데, VSS를 사용해야 하나요?

먼저 사용하지 않고 끝낼 방법을 찾는 것이 현실적입니다. VSS의 요청자는 COM 기반 네이티브 API(IVssBackupComponents 등)로 작성해야 하고 .NET용 공식 래퍼는 제공되지 않으므로, 직접 만든 앱에 통합하는 것은 상당히 큰 작업이 됩니다. 요구가 '다른 프로세스가 쓰는 중인 파일을 언젠가 읽을 수만 있으면 된다'는 것이라면 재시도로, '읽기 공유가 허용되어 있다'면 공유 모드를 맞춰 여는 것으로 충분합니다. 앱을 짧은 시간 멈출 수 있다면 업무의 틈에 복사하는 것이 가장 확실합니다. '멈출 수 없는 앱의 데이터 일체를 정합성 있는 상태로 복제한다'는 요구만이 VSS가 나설 자리이며, 그 경우에도 자체 구현보다 VSS 대응 백업 소프트웨어나 DiskShadow의 스크립트화를 먼저 검토하시기 바랍니다.

vssadmin list writers에서 라이터가 오류 상태로 나타납니다. 어떻게 해야 하나요?

그 라이터를 담당하는 애플리케이션 측의 문제로 조사하는 것이 기본입니다. vssadmin list writers는 등록된 라이터 목록을 상태와 함께 표시하므로, 먼저 어떤 라이터가 실패하고 있는지를 특정합니다. 라이터는 SQL Server 등의 애플리케이션이나 Windows의 구성 요소(레지스트리 등)가 제공하므로, 오류의 원인은 VSS 본체보다 담당 앱의 서비스 상태나 애플리케이션/시스템 이벤트 로그에 기록된 오류에 있는 경우가 대부분입니다. 해당 서비스의 재시작이나 재현 조건의 구분을 실시하고, 해결되지 않으면 해당 앱의 지원 정보를 확인합니다. 백업 소프트웨어가 VSS 오류로 실패하는 경우의 1차 구분에서도 이 절차는 동일합니다.

섀도 복사본이 모르는 사이에 사라져 있었습니다. 왜 그런가요?

차분 영역(섀도 복사본 기억 영역)의 용량 부족이 대표적인 원인입니다. 카피 온 라이트 방식에서는 스냅샷 취득 후 각 블록이 처음으로 덮어쓰일 때 덮어쓰기 전의 내용이 차분 영역으로 대피되므로, 덮어쓰인 범위가 넓을수록 차분 영역을 소비합니다. 할당된 상한에 도달하면 Windows는 오래된 섀도 복사본부터 순서대로 삭제하여 영역을 확보합니다. 대화형 사용자에게는 통지되지 않고 조용히 사라지기 때문에, '이전 버전에서 지난주 판으로 되돌릴 수 있을 줄 알았는데 없었다'는 형태로 발각되기 쉽습니다(System 로그에는 volsnap 소스의 이벤트 25 등이 기록되므로, 모니터링 대상으로 삼아 두면 알아챌 수 있습니다). vssadmin list shadowstorage로 사용량과 상한을 확인하고, 필요하면 vssadmin resize shadowstorage로 상한을 넓힙니다. 다만 상한 변경(축소) 자체가 섀도 복사본의 소실을 초래할 수 있다는 점에도 주의하시기 바랍니다.

탐색기의 '이전 버전'과 VSS는 어떤 관계인가요?

'이전 버전'은 VSS가 만든 섀도 복사본 안의 과거 파일을 꺼내기 위한 입구 중 하나입니다. 파일 서버에서는 '공유 폴더의 섀도 복사본'(Shadow Copies of Shared Folders)을 활성화하면 정기적으로 섀도 복사본이 만들어지고, 사용자는 공유 폴더의 파일을 마우스 오른쪽 버튼으로 클릭하여 이전 버전에서 직접 복원할 수 있습니다. 관리자의 도움 없이 삭제·덮어쓰기 실수를 바로잡을 수 있는 것이 장점입니다. 다만 실체는 섀도 복사본이므로 보관할 수 있는 세대 수에는 상한이 있고, 차분 영역이 부족하면 오래된 세대부터 사라집니다. '이전 버전이 있으니 백업은 필요 없다'가 성립하지 않는다는 점은 본문에서 서술한 대로입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.