MSDP -> MSDP SLP Duplications slow - what to check?
Hi all,
I wonder if someone might be able to help us with this. I can always open a supprt case if required but thought I'd ask here first.
First a little about our configuration: We have a 7.6.1 Windows 2012 R2 Master server which is also a Media server hosting a MSDP. This server processes all overnight backups (accelerator enabled vmware policies) to it's own MSDP. These backups all complete easily within the defined window. SLP duplication job commences the following day at 08:00 that copies all backups to another 7.6.1 Windows 2012 R2 Media server also hosting a MSDP.
The problem we have is that the SLP Duplication window is closing before all images have been been processed causing error 196. During duplication window we observe lower than expected resource usage on both media servers. RAM, CPU and page file usage are minimal. Also the disk subsystem doesn't appear to be at all stressed. How can we check that everything is working to it's full potential?
Any help at all would be great. Apologies if I have forgotten to add something.
Other things to check:
5) Are the MSDP DB and MSDP Data locations on the same drive volume letter?
6) Are they both on the same type of storage?
7) Are the drives local within the server, perhaps on a SAS RAID HBA, or external via SAS, or external via SAN?
8) If SAN, are they iSCSI or FC?
9) If an external array is being used, does the array have any tools to let you monitor the throughput of the array front end controllers, or array parity groups?
10) For the NTFS volumes, is 'disablelastaccess' set? It should be disabled by default in Windows 2012 R2. Use the 'fsutil' tool to confirm.
11) Is 'disable8dot3' names selected? Again, use 'fsutil' to check.
12) And again use 'fsutil' to check what the NTFS disk cluster blocking factor is? usually it's a good idea to use 64KB on the volume hosting the MSDP Data, instead of teh typical 4KB for NTFS.
13) Check that the NTFS volume itself is not a 'NTFS dedupe volume''.
14) Is NTFS Change Journal enabled on the volume? Check for the presence of VxCJ*.dat files at the root of the drive? If these files are seen then you may have, for some reason, enabled 'Use Change Journal' in teh NetBackup Client properties of the 'media server', and so all file changes are also being tracked by NTFS - which is probably not required.
.
The idea of all of the above is to gain a perspective, and understanding of the configuration of the storage layer.