Share via

Scalability Factors for Shadow Copies

Applies To: Windows Server 2003, Windows Server 2003 R2

With the increased adoption of the Volume Shadow Copy Service (VSS), we have had several requests from partners and customers for guidance on provisioning server and storage resources in their deployments. This document is intended to provide general information that a partner or customer needs to make appropriate choices for scalability when deploying Shadow Copies of Shared Folders.

This information refers to VSS deployments on Windows Server® 2003 with Service Pack 1 and Windows Server 2003 R2. There are three significant parameters to consider when planning for scalability: availability of paged pool memory, nonpaged pool memory, and system virtual memory.

Paged pool memory and snapshot limitations

The NTFS file system requires 1 to 2 MB of paged pool memory per million files for snapshots and volumes mounted on the system. The usage is independent of actual number of snapshots on the system. This is an approximation—the actual usage would vary depending on the file access patterns.

Example: Mounting 64 snapshots of a volume with 2 million files is equivalent to mounting 8 snapshots of a volume with 16 million files.

Impact of file access patterns on paged pool memory usage

NTFS maps file records in 64-MB chunks. Each 64-MB mapping of file records consumes 64 KB of paged pool memory. Each 64-MB mapping of file records represents 65,536 files, where each file is represented by a 1-KB file record. NTFS maps a new 64-MB range of its file records whenever one of those file records is accessed. If all the file records are mapped, this translates to 1 MB of paged pool memory used for every 1 million files. Besides the file records, there are many other NTFS disk data structures that need to be mapped—and those mappings also consume paged pool memory. That is why we estimate the paged pool memory usage as being between 1 MB and 2 MB per million files.


  • Split the volumes among more servers.

  • Install the KB 891957 update described in the Microsoft Knowledge Base article 913648 (

    Based on heuristics, this update dismounts all mounted shadow copies if:

    • More than 128 MB of paged pool memory is being used by the mounted shadow copies.


    • The available paged pool memory drops below 50 MB.

VSS attempts to estimate the amount of paged pool memory actually being used by the snapshots by monitoring the change in paged pool memory allocation whenever a snapshot is deleted or dismounted. The dismounts occur during shadow copy creation.


This limitation is significant only on 32-bit systems, which may have a maximum paged pool memory of 650 MB. 64-bit systems support 128 GB of paged pool memory.


A lack of paged pool memory leads to events such as Event 2020.

System virtual memory limitation

For every 16 KB of diff area on a system, VSS consumes about 40 bytes of virtual memory on the system. However, optimizations used by VSS can reduce the usage of virtual memory, so a production system will most likely have better usage.

The total diff area on a system is configured by the shadow copy storage space setting and is often set at 10% of the volume to be shadow copied.

Example: To snapshot a 10 TB volume, we prescribe a 1 TB diff area, which requires about 2 GB of virtual memory after accounting for the optimizations used by VSS.


This limitation is significant only on 32-bit systems which have 2 GB of addressable space. 64-bit systems have 8 TB of virtual address space.


A lack of virtual memory leads to Event 6.

Nonpaged pool memory limitation

The amount of nonpaged pool memory in the system is proportional to the amount of physical memory, but the amount of nonpaged pool memory on a 32-bit system is never greater than 256 MB—regardless of the amount of physical memory available. VSS consumes 1 bit (16 KB) of the volume to be shadow copied.

Example: A 1-TB volume that is shadow copied consumes 8 MB of nonpaged pool memory.

Snapshot creation:

VSS consumes 5 bits per volume to be shadow copied only during snapshot creation. This usage is pruned once the snapshot is created.

Example: A 5-TB volume consumes 200 MB of nonpaged pool memory during the snapshot creation phase and then drops to using 40 MB after that.


While this limitation applies to both 32-bit and 64-bit systems, it is less significant on 64-bit systems. On 64-bit systems, nonpaged pool memory is capped at 7/8th of physical memory and can never exceed 128 GB. 32-bit systems are limited to 256 MB of nonpaged pool memory, and 128 MB of nonpaged pool memory if the system is booted with the /3GB switch.


A lack of nonpaged pool memory usually results in Event 5.

Additional resources

For memory limits for specific Windows releases, see