Hi,
The size of the volume is not an issue, however the number of files and directories can effect DPM Consistency Check times and will effect backup SLA. To help address that issue, you should think about implementing one of the below workarounds.
Problem Reported: When Data Protection Manager needs to run a consistency check against a very large volume, the consistency check takes an excessive amount of time to complete. While consistency check is ongoing, normal backups cannot
be made which may affect SLA.
The amount of time it takes to perform a consistency check against a data source has many variables.
1) The number of files and directories on the protected volume. Millions of small files will take much longer than a handful of larger files of equal total space used.
2) If you have SIS enabled, that effects Consistency Check times. (especially if you SIS files in recycle bin, so clear the recycle bin frequently on SIS enabled volumes)
3) Disk I/O speed on both DPM and Protected server.
4) How busy each of the disks are. (io/sec, queue length)
5) network speed and bandwidth / utilization.
Check out the section HOW TO CHECK FOR BOTTLENECKS at the bottom if you wish to investigate items 3,4,5 further.
How to mitigate the problem if the issue is related to item 1. or 2. above.
OPTION-1 - - Convert the Physical machine to a Virtual machine and let DPM protect the Virtual machine.
With System Center 2012 Data Protection manager, you can protected Virtual machines on Windows 2008 R2 Standalone Hyper-V servers and DPM will perform block level change synchronizations.
With System center 2012 Sp1 and later, this same block level protected is extended to include Windows Server 2012 based clustered Hyper-v guests on CSV volumes.
This means that DPM 2012 will track block level changes to the .VHD files and perform true incremental backups. These backups are very fast and efficient. You also get the added benefit of being able to perform Item level Restore (ILR) of individual
files and directories inside the .VHDs using the recovery tab in the DPM Console. This means you get the quick backups like you would with normal volume level backups for file servers, and granular restores. Should a consistency check need
to be ran against the VMs .VHD files, they will much quicker since were doing block level compares of the .VHD versus file level compares for file protection.
PRO: What may have taken days to complete for a file system Consistency Check will only take minutes or hours for a Virtual machine.
CON: End user recovery (EUR) will not work for protected hyper-V virtual machines.
As a workaround, you can enable local shadow copies on the volumes inside the virtual machine, and clients can restore previous versions from local shadow copies.
CON: With Windows Server 2008 R2, hyper-v only supports .VHD sizes of up to 2TB if your data set is larger than that, then you would need to segregate your data using option-2 below or use Windows Server 2012 hyper-V server which supports .VHDX files
up to 64TB.
OPTION-2 Use NTFS Volume mount points to segregate your data across several smaller NTFS volume.
This option is only viable if the data can be segregated. If an application is writing to the volume and cannot handle the data being re-organized under mount points, then this option will not work. If the data is written to and read from shares,
then you should be able to re-organize the data to accommodate mount points.
In my example below, Host_Volume (H:) is just a very small ntfs volume that only holds the mount point directories and shares.
UserShare# is a folder that is shared for user access and is the empty mountpoint folder. Mounted_Volume# is the underlying volume that holds the users directories and data. DPM protects H: and the Mounted Volumes.
This configuration allows a chkdsk and / or a DPM Consistency Check to only run against the subset of users files on one volume which wont take as long. DPM protection continues as normal for the other volumes under protection.
Host_Volume (H:)
UserShare1 -->Mounted_Volume1
UserDir1
UserDir2
UserDir3
UserShare2 -->Mounted_Volume2
UserDir4
UserDir5
UserDir6
UserShare3-->Mounted_volume3
UserDir7
UserDir8
UserDir9
You can grow the Mounted_volume at the SAN level if you need more space on that disk for users data, then use diskpart.exe command to grow the NTFS file system into the new free space, that way you can start with smaller LUNs and grow them over time as new
users / data gets added.