볼륨 섀도 복사본(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부터 들어 있습니다.²
• 역할은 셋에 조정 역할이 더해집니다. 섀도 복사본을 요청하는 requester(백업 소프트웨어), 앱 쪽에서 데이터 일관성을 보장하는 writer(SQL Server 등), 실제로 스냅샷을 만드는 provider를 VSS 서비스가 중개합니다.¹
• Windows 표준 시스템 provider는 copy-on-write 방식입니다. 볼륨 전체를 복제하지 않고, 스냅샷 이후 덮어쓰는 블록만 덮어쓰기 전에 diff area로 옮겨 둡니다. diff area는 NTFS 볼륨 위에 있어야 합니다.¹
• 일관된 시점은 ‘writer freeze(최대 60초) → 스냅샷 생성(10초 이내) → thaw’로 만듭니다. 제한 시간을 넘기면 생성이 중단되고 requester가 다시 시도합니다.¹
• writer가 협조하는지에 따라 복사 품질이 달라집니다. 협조 없는 스냅샷은 ‘전원이 끊긴 순간의 디스크’와 같습니다(crash-consistent). 협조가 있으면 로그 롤과 캐시 플러시를 마친 뒤, 앱 스스로 복구 가능하다고 보장하는 일관 상태(application-consistent)입니다.³¹
• 운영 확인은 vssadmin입니다. list shadows / list writers / list shadowstorage로 현황을 보고, resize shadowstorage로 diff area 상한을 맞춥니다. diff area가 바닥나면 오래된 섀도 복사본부터 조용히 삭제됩니다.⁴⁵¹
• 자체 앱에 VSS requester를 넣는 일은 큰 작업입니다. COM 기반 native API이고 .NET용 공식 래퍼는 없습니다. 대부분은 재시도·공유 모드 조정·짧은 정지로 충분하고, 정말로 VSS가 필요하면 DiskShadow 스크립트화가 현실적인 해법입니다(Windows Server 한정).⁶⁷
• 섀도 복사본은 백업 자체가 아닙니다. copy-on-write diff는 원본 볼륨의 손상되지 않은 블록에 의존하므로, 디스크 고장이나 도난처럼 원본 볼륨 자체를 잃는 장애에는 도움이 되지 않습니다. 랜섬웨어에도 섀도 복사본 자체의 삭제(7.3)나 대량 덮어쓰기로 인한 diff area 고갈(7.4) 때문에 믿을 수 없습니다. 다른 매체 백업과 함께 쓸 때 비로소 의미가 있습니다.¹

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 26건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 문제 설정 ── 사용 중인 파일은 왜 그대로 복사하지 못하는가

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

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

다만 이 올바른 동작은 백업과 근본적으로 충돌합니다.

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

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

3. VSS의 역할 ── requester·writer·provider

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

역할 분담의 요점은 서로를 모르는 제품끼리 맞출 수 있다는 데 있습니다. 백업 소프트웨어(requester)는 SQL Server 내부 구조를 모르지만, SQL Server writer가 ‘백업해야 할 파일 집합(컴포넌트)’을 메타데이터로 알리고 일관된 시점을 만들기 전후에 자기 데이터를 정리하므로, requester는 그것을 따르기만 하면 일관된 백업을 뜰 수 있습니다.¹⁹ Windows에서 돌아가는 서드파티 백업 소프트웨어의 거의 전부가 VSS requester입니다.¹

정보시스템 실무에서 이 세 역할을 의식하게 되는 장면은 문제 조사입니다. 백업 소프트웨어 실패가 requester(소프트웨어 쪽) 문제인지, 특정 writer(앱 쪽) 문제인지, provider·diff area(기반 쪽) 문제인지에 따라 볼 곳이 전혀 달라집니다(5장·7장).

4. 스냅샷의 동작 ── copy-on-write와 ‘일관된 시점’

4.1. copy-on-write ── 볼륨을 복제하지 않고 ‘그 순간’을 남긴다

‘스냅샷’이라고 하면 볼륨 전체 복제를 떠올리기 쉽지만, Windows 표준 시스템 provider가 쓰는 것은 copy-on-write 방식입니다. 스냅샷을 만드는 시점에는 거의 아무것도 복사하지 않습니다. 그 뒤 원본 볼륨의 블록이 덮어쓰일 때, 덮어쓰기가 끝나기 전에 덮어쓰기 전 블록을 diff area(섀도 복사본 저장소)로 옮겨 둔 다음 쓰기를 통과시킵니다.¹ 옮겨야 하는 것은 각 블록의 첫 덮어쓰기뿐이고, 이미 옮겨 둔 블록을 다시 덮어써도 diff area는 늘지 않습니다.

‘그 순간의 볼륨’을 읽으려면, 바뀌지 않은 블록은 원본 볼륨에서, 바뀐 블록은 diff area에서 읽어 합칩니다. 바뀐 부분만 복사하므로 생성은 순식간이고, 쓰는 용량도 diff뿐입니다. 뒤집으면 쓰기가 많은 볼륨일수록 diff area 소모가 빠르고(7장에서 이어집니다), diff area는 원본 데이터와 같은 머신의 NTFS 볼륨 위에 둡니다.¹ 이 동작을 받치는 것이 시스템 provider의 구성 파일 swprv.dll과, 볼륨 I/O에 끼어드는 드라이버 volsnap.sys입니다.¹ I/O 스택에 ‘어떻게 끼어드는지’가 궁금하면 ‘필터 드라이버와 미니필터‘도 참고하시기 바랍니다.

방식에는 이 밖에 미러를 떼어 내는 완전 복사, 변경을 다른 볼륨에 쓰는 redirect-on-write가 있고, 하드웨어 provider는 스토리지 장치 쪽에서 맞는 방식을 씁니다.¹

4.2. 일관된 시점을 만드는 흐름 ── freeze 60초·생성 10초의 협조

copy-on-write가 ‘어떻게 저장하는가’라면, VSS의 핵심은 ‘어느 시점의 상태를 저장하는가’, 곧 일관된 시점을 만드는 방법입니다. 섀도 복사본 생성은 다음 흐름으로 진행됩니다.¹

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

그림 1: 섀도 복사본 생성 흐름. 멈추는 것은 수 초에서 수십 초뿐이고, 백업 작업 자체는 스냅샷을 대상으로 수행한다

요점은 셋입니다.

1. 앱이 멈추는 것은 일관된 시점을 만드는 그 순간뿐입니다. freeze는 60초 이내, provider의 생성(커밋)은 10초 이내로 정해져 있고, 넘기면 생성이 중단되어 requester가 다시 시도합니다.¹ 몇 시간이 걸리는 백업 작업 자체는, 만들어진 읽기 전용 섀도 복사본을 대상으로 앱을 돌린 채로 실행합니다.
2. freeze 중에도 읽기는 가능합니다. 멈추는 것은 쓰기 I/O뿐입니다.¹
3. 파일 시스템도 동결됩니다. VSS가 파일 시스템 버퍼를 플러시한 뒤 동결하므로, 캐시에 있던 쓰기와 파일 시스템 메타데이터가 일관된 순서로 스냅샷에 반영됩니다.¹

4.3. crash-consistent와 application-consistent

여기서 백업 품질을 가르는 중요한 구분이 나옵니다.

writer 협조 없이 만든 섀도 복사본은 Microsoft 용어로 crash-consistent 상태입니다. 공식 정의는 ‘시스템을 갑자기 종료시키는 치명적인 장애 뒤에 발견되는 상태와 같은 디스크 상태’이고, 그로부터의 복원은 ‘갑작스러운 종료 후 재시작과 같다’고 합니다.³ 파일 시스템으로서는 깨지지 않았지만, 앱에서 보면 ‘쓰는 중에 전원을 뽑힌 순간’입니다. 트랜잭션 로그로 복구하는 데이터베이스라면 복구되는 경우가 많지만, 복구 처리가 전제입니다.

writer 협조가 있으면, 일관된 시점 직전에 각 writer가 트랜잭션 로그를 롤하고 캐시를 플러시하여, 앱 스스로 ‘여기서부터 올바르게 복구할 수 있다’고 보장하는 일관 상태로 맞춥니다.¹ 이것이 application-consistent이며, writer라는 구조가 있는 이유입니다. 주의할 점은 writer가 보장하는 것이 ‘앱으로서 일관되고 복구 가능한 상태’이지, 실행 중인 트랜잭션을 제멋대로 커밋해 끝내 주는 것은 아니라는 점입니다. 커밋되지 않은 작업은 복원 시 롤백됩니다(데이터베이스의 평범한 복구와 같습니다). writer는 이 품질 보장을 앱을 멈추지 않고, 수십 초 freeze만으로 해냅니다.

백업 소프트웨어 설정에 ‘VSS 사용’, ‘애플리케이션 일관성 보장’ 같은 항목이 있는 것은 이 구분의 반영입니다. 파일 서버의 평범한 파일 집합이라면 crash-consistent여도 거의 문제가 되지 않지만, 데이터베이스나 메일 스토어를 가진 서버에서는 해당 writer가 정상인지가 백업 품질 그 자체가 됩니다.

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

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

list writers 결과에서 writer가 오류 상태라면, 의심할 곳은 VSS 자체가 아니라 그 writer를 제공하는 앱 쪽입니다. 담당 앱의 서비스 상태와 Application/System 이벤트 로그를 확인합니다(7장).

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

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

파일 서버에서 ‘공유 폴더의 섀도 복사본(Shadow Copies of Shared Folders)’을 켜면, 공유상의 파일의 어느 시점 복사본이 주기적으로 유지되고, 사용자는 삭제·덮어쓴 파일을 관리자 손 없이 ‘이전 버전’에서 복원할 수 있습니다.¹ 헬프데스크 부담을 분명히 줄이는, VSS의 가장 가까운 응용입니다.

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

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

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

6.1. requester를 직접 만드는 일은 큰 작업

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

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

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

경험상 ‘사용 중인 파일 복사’ 상담의 대부분은 VSS 없이 해결됩니다. 요구 수준을 가늠한 뒤에 도구를 고르시기 바랍니다.

6.3. 자체 앱은 writer를 등록해야 하는가

반대 방향의 질문, ‘직접 만든 업무 앱이 VSS writer를 제공해야 하는가’도 정리합니다. writer를 작성하면 고객이 어떤 백업 소프트웨어를 쓰든, 자기 앱 데이터를 application-consistent로 떠 줄 수 있습니다. 참고로 일반 writer보다 단순한 익스프레스 writer(IVssExpressWriter)라는 구조도 있지만, 이것은 ‘어느 파일을 대상/제외할지’라는 메타데이터 선언을 등록할 뿐입니다.⁶ freeze/thaw 같은 알림은 받지 않으므로, 스냅샷 생성에 맞춰 앱 쓰기를 멈추게 하는 것은 불가능합니다. 익스프레스 writer를 써도 되는 것은 쓰는 도중에 떠도 깨지지 않는(crash-consistent로 충분한) 저장 설계와 짝을 이룰 때뿐이고, 일관된 시점에서의 협조가 필요하면 일반 writer 구현이 필요합니다.

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

• 데이터를 SQL Server 등 DB에 두고 있으면 불필요합니다. DB 쪽 writer가 일관성을 보장합니다.¹
• 단순한 파일 저장이라면 먼저 저장 처리 쪽 설계로 풉니다. 임시 파일에 다 쓴 뒤 이름 변경으로 바꾸는 원자적 저장으로 두면, crash-consistent 스냅샷에서도 ‘깨진 저장 파일’은 남지 않습니다.
• writer 등록을 검토할 가치가 있는 것은 여러 파일에 걸친 독자 데이터 저장소를 갖고, 일관된 시점에서 서로 맞아야 하는 앱에 한정됩니다. 그 규모 데이터를 자체 형식으로 안고 있는 것 자체를 먼저 돌아보는 편이 나을 수도 있습니다.

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

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

가장 중요한 함정입니다. 시스템 provider의 섀도 복사본은 원본 데이터와 같은 머신 디스크 위의 diff입니다. diff area를 잃으면 합성하지 못하므로, 디스크 고장·머신 도난 분실·볼륨 전체 암호화에는 아무 보호가 되지 않습니다. Microsoft 문서도 ‘섀도 복사본에서 테이프 등 매체로 복사한 내용이 백업이며, 복사 후에는 섀도 복사본을 삭제해도 된다’고 섀도 복사본과 백업을 분명히 구분합니다.¹ 섀도 복사본은 일관된 시점이며 실수에서 빠르게 되돌리는 수단이지, 다른 매체·다른 거점 백업을 대신하지 않습니다.

7.2. writer 오류는 앱 쪽 문제

백업 소프트웨어가 ‘VSS 오류’로 실패하면, 먼저 vssadmin list writers로 어느 writer가 실패했는지 특정합니다. writer의 실체는 애플리케이션(또는 Windows 구성 요소) 쪽 부품이므로¹, 원인 조사의 중심은 담당 앱의 서비스 상태와 이벤트 로그입니다. ‘백업 소프트웨어 오류’라는 겉모습에 끌려 백업 소프트웨어 쪽만 파고들면 멀리 돌아갑니다. 원인 분리의 일반 진행은 ‘소스도 자료도 없는 시스템의 유지보수‘에서도 다룬, ‘관측할 수 있는 사실에서 용의자를 좁히는’ 형과 같습니다.

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

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

7.4. diff area가 바닥나면 오래된 세대부터 조용히 사라진다

4장에서 본 대로, copy-on-write가 diff area를 쓰는 것은 스냅샷을 뜬 뒤 각 블록이 처음 덮어쓰일 때입니다. 이미 옮겨 둔 블록을 몇 번 덮어써도 소모는 늘지 않으므로, 소모량은 ‘쓰기 횟수’가 아니라 ‘유지 중인 스냅샷 이후에 덮어쓴 블록 범위의 넓이‘로 정해집니다. 그리고 diff area가 상한에 닿으면 그 볼륨의 섀도 복사본은 오래된 것부터 순서대로 삭제됩니다.¹ 대화형 사용자에게는 아무 알림도 없으므로, ‘지난주 판으로 되돌릴 수 있을 것’이라 생각했다가 되돌리지 못하게 되고 나서야 알게 되기 쉽습니다. 다만 완전히 무음은 아니고, System 로그에는 volsnap 소스 이벤트가 남습니다(diff area를 확보하지 못해 삭제됐을 때의 25, 확장 실패나 상한 도달로 중단됐을 때의 35/36 등). 정기 확인에 더해 이 volsnap 이벤트를 감시·알림 대상에 넣어 두면 소실을 바로 알아챌 수 있습니다. 대량 파일 갱신·일괄 변환·조각 모음처럼 ‘볼륨을 넓게 훑는’ 처리가 diff area를 한 번에 잡아먹는 것은, 이 ‘덮어쓴 범위로 정해진다’는 성질 때문입니다. 유지 세대가 업무 요건(‘잘못 삭제한 것을 알아채는 데 최장 며칠이 걸리는가’)을 충족하는지, vssadmin list shadowstorage 사용량을 주기적으로 확인하고, 필요하면 상한을 넓히시기 바랍니다.⁵¹⁰

8. 정리

• 사용 중인 파일을 그대로 복사하지 못하는 것은 공유 위반과 일관성 문제이며, 그것은 데이터를 지키는 올바른 동작입니다. ‘멈추지 않고 일관된 복사본이 필요하다’에 대한 OS 수준의 답이 VSS입니다.
• VSS는 requester(요청)·writer(일관성 보장)·provider(생성)의 세 역할을 VSS 서비스가 중개하는 틀이며, 서로를 모르는 백업 소프트웨어와 업무 앱이 맞출 수 있습니다.
• 시스템 provider는 copy-on-write 방식이고, 일관된 시점은 ‘writer freeze(최대 60초) → 생성(10초 이내) → thaw’로 만듭니다. writer 협조가 없으면 crash-consistent, 있으면 application-consistent입니다.
• 운영 확인은 vssadmin(list shadows / list writers / list shadowstorage)입니다. writer 오류는 앱 쪽을 의심하고, diff area 사용량은 주기적으로 봅니다.
• 개발자는 먼저 재시도·공유 모드·정지 시간·연계 설계로 풀리지 않는지를 판단표로 확인하고, 정말로 필요할 때만 VSS로 갑니다. 자체 구현보다 DiskShadow 스크립트(Server 한정)나 기존 소프트웨어가 현실적인 해법입니다.
• 섀도 복사본은 백업이 아닙니다. 원본 볼륨의 손상되지 않은 블록에 의존하는 diff일 뿐이고, 디스크 고장처럼 원본 볼륨 상실에는 도움이 되지 않으며, 랜섬웨어에도 섀도 복사본 삭제나 diff area 고갈로 믿을 수 없습니다. 오프라인·다른 거점 백업과 함께 쓰시기 바랍니다.

관련 글

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

관련 상담 영역

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

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

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

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

필요 없어지지 않습니다. Windows 표준 시스템 provider가 만드는 섀도 복사본은 copy-on-write 방식의 diff일 뿐, '그 시점의 완전한 복제본'을 따로 들고 있는 것이 아니라 원본 볼륨에서 아직 덮어쓰지 않은 블록에 의존합니다. diff area를 다른 볼륨에 두는 구성이어도 원본 볼륨을 잃으면 복원하지 못한다는 점은 같고, 디스크 고장이나 PC 도난·분실처럼 원본 볼륨 자체를 잃는 상황에는 도움이 되지 않습니다. 랜섬웨어에서도 암호화 쓰기 자체는 덮어쓰기 전 블록을 diff area로 옮겨 두지만, 실제 공격에서는 섀도 복사본 삭제나 대량 덮어쓰기로 diff area가 바닥나 사라지므로 믿을 수 없습니다. Microsoft 문서도 섀도 복사본에서 테이프 등 매체로 복사한 데이터가 백업이며, 복사 후에는 섀도 복사본 자체를 삭제해도 된다고 둘을 구분합니다. 섀도 복사본은 '백업을 뜨기 위한 일관된 시점'이자 '가벼운 실수에서 빠르게 되돌리는 수단'이지, 다른 매체·다른 거점 백업을 대신하지 않습니다.

직접 만든 업무 앱에서 사용 중인 파일을 복사하려면 VSS를 써야 하나요?

먼저 쓰지 않고 끝낼 방법을 찾는 편이 현실적입니다. VSS requester는 COM 기반 native API(IVssBackupComponents 등)로 작성해야 하고 .NET용 공식 래퍼는 없으므로, 자체 앱에 넣는 일은 꽤 큰 작업입니다. 요구가 '다른 프로세스가 쓰는 중인 파일을 언젠가는 읽으면 된다'면 재시도로, '읽기 공유가 허용되어 있다'면 공유 모드를 맞춰 열면 됩니다. 앱을 잠시 멈출 수 있으면 업무가 끊기는 타이밍에 복사하는 것이 가장 확실합니다. '멈출 수 없는 앱의 데이터 일체를 일관된 상태로 복제한다'는 요구만 VSS가 나설 자리이고, 그때도 직접 구현하기보다 VSS를 지원하는 백업 소프트웨어나 DiskShadow 스크립트화를 먼저 검토하시기 바랍니다.

vssadmin list writers에서 writer가 오류 상태입니다. 어떻게 하면 되나요?

그 writer를 담당하는 애플리케이션 쪽 문제로 조사하는 것이 기본입니다. vssadmin list writers는 등록된 writer 목록을 상태와 함께 보여 주므로, 먼저 어느 writer가 실패했는지 특정합니다. writer는 SQL Server 같은 애플리케이션이나 Windows 구성 요소(레지스트리 등)가 제공하므로, 원인은 VSS 자체보다 담당 앱의 서비스 상태나 Application/System 이벤트 로그에 남은 오류인 경우가 대부분입니다. 해당 서비스를 다시 시작하고 재현 조건을 가려 보며, 그래도 안 되면 그 앱의 지원 정보를 확인합니다. 백업 소프트웨어가 VSS 오류로 실패할 때의 1차 원인 분리도 같은 절차입니다.

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

diff area(섀도 복사본 저장소) 용량 부족이 대표적인 원인입니다. copy-on-write에서는 스냅샷을 뜬 뒤 각 블록이 처음 덮어쓰일 때 덮어쓰기 전 내용이 diff area로 옮겨지므로, 덮어쓴 범위가 넓을수록 diff area를 씁니다. 할당한 상한에 닿으면 Windows는 오래된 섀도 복사본부터 지워 공간을 확보합니다. 대화형 사용자에게는 알리지 않고 조용히 사라지므로, '이전 버전에서 지난주 판으로 되돌릴 수 있을 줄 알았는데 없었다'는 식으로 뒤늦게 알게 되기 쉽습니다(System 로그에는 volsnap 소스의 이벤트 25 등이 남으므로, 감시 대상으로 두면 알아챌 수 있습니다). vssadmin list shadowstorage로 사용량과 상한을 확인하고, 필요하면 vssadmin resize shadowstorage로 상한을 넓힙니다. 다만 상한 변경(축소) 자체가 섀도 복사본 소실을 부를 수 있다는 점에도 주의하시기 바랍니다.

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

'이전 버전'은 VSS가 만든 섀도 복사본 안의 과거 파일을 꺼내는 입구 중 하나입니다. 파일 서버에서 '공유 폴더의 섀도 복사본'(Shadow Copies of Shared Folders)을 켜면 섀도 복사본이 주기적으로 만들어지고, 사용자는 공유 폴더의 파일을 마우스 오른쪽 단추로 눌러 이전 버전에서 직접 복원할 수 있습니다. 관리자 손 없이 삭제·덮어쓰기 실수를 고칠 수 있는 것이 장점입니다. 다만 실체는 섀도 복사본이므로 남길 수 있는 세대 수에는 상한이 있고, diff area가 부족하면 오래된 세대부터 사라집니다. '이전 버전이 있으니 백업은 필요 없다'가 되지 않는다는 점은 본문에서 말한 그대로입니다.

저자 프로필

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

Go Komura

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

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