none
SCDPM 1807 - Unable to enumerate size to be provisioned RRS feed

  • Question

  • Hi Folks 

    First of all sorry for posting queries every week, I had worked with DPM 2010-2012 and stopped almost 3 years back. Now have started working again and have mix of infrastructure of SCDPM 2012 R2 and SCDPM 1807 (Upgrading al DPM 2012R2 to 1807 and migrating replicas)

    While migrating backups from 2012 R2 to DPM 1807 I am facing below issue as it's stuck on never ending calculation process

    of space to be provisioned (1807)


    Let me give a little history of steps I performed. 

    1. Old DPM server Windows Server 2012 R2 with DPM 2012 R2. (Physical Server)

    2. Built a new separate DPM with Windows Server 2016, DPM 1801 and installed patch of 1807. (Physical Server)

    3. 2 types of protection on old server, 1 SQL DB server, 2 File repository servers.

    4. Uninstalled agent of DPM 2012 on client's, rebooted and Installed agent from DPM 1807 (New Agent version 5.1.378.0)

    5. Removed entry of clients from old DPM 2012 R2 server's database.

    6. Both SQL DB and File Servers are showing fine with agent status on new DPM 1807.

    7. Now SQL DB instances are backing up fine but when I am adding File shares repositories from file servers, it's never complete 'Space to be provisioned' calculation. 

    Is this any bug ! Any workaround or fix for this!



    • Edited by V Jay Rana Monday, March 4, 2019 6:52 PM
    Monday, March 4, 2019 6:48 PM

All replies

  • Hello!

    Could you provide a screenshot of the data that you want to add to the protection group (the check boxes of the drives/folders)?

    If you want to protect a whole drive, you could try by selecting just a few folders at the time and not all.

    Example:


    Best regards,
    Leon


    Blog: https://thesystemcenterblog.com LinkedIn:

    Tuesday, March 5, 2019 12:17 AM
  • Hi Leon 

    Thanks for reply. Yes, yesterday I tried that as I was checking technet forums and found DPM 2016 - Stuck on Calculating Disk Storage Allocation

    So I tried selecting whole drive and then deselecting folders I don't want to backup, this worked me for few servers but still some file servers are reporting same issue. My concern is, we have larger amount of file/folder shares on multiple servers and I wan't to backup those instead backing up individual folder browsed from drive letter, coz I wan't sharing and security permissions to be cured in case of recovery. 

    Then I try creating string in registry which was not available there in registry = EnableCustomAllocationOnReFSStorage, no luck. 

    I am not sure if this is the actual issue, but today I started 'DPM Agent Coordinator' service on DPM server and so far I have added 5 servers successfully. I will let you know with update. 

    Tuesday, March 5, 2019 4:31 PM
  • The DPM Agent Coordinator is only used for managing installation, uninstallation or updating of the DPM agents, so I don't see how it would help, but I'm glad to hear that you have progress!

    Keep us updated!


    Blog: https://thesystemcenterblog.com LinkedIn:

    Tuesday, March 5, 2019 9:09 PM
  • String 'EnableCustomAllocationOnReFSStorage' was not available in the registry, I created it manually so now issue hasn't occurred after this change. 

    Got it from Add Modern Backup Storage to DPM

    Custom Size Allocation

    DPM 2016 consumes storage thinly, as needed. Once DPM is configured for protection, it calculates the size of the data being backed up. If many files and folders are being backed up together, as in the case of a file server, size calculation can take long time. With DPM 2016, you can configure DPM to accept the volume size as default instead of calculating the size of each file. The corresponding registry key is "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Configuration\DiskStorage" with the Key, "EnableCustomAllocationOnReFSStorage" as a String set to 1 to enable custom size allocation, set to 0 for default size allocation with DPM.

    Tuesday, March 5, 2019 9:31 PM
  • That is most likely the thing that helped, yep :-)

    Blog: https://thesystemcenterblog.com LinkedIn:

    Tuesday, March 5, 2019 9:33 PM