none
Initial Replica creation failed for File Server RRS feed

  • Question

  • Hello,

    We are using DPM2010 to replace our current backup solution and I am doing the migration of all our backup jobs to DPM.

    Our main file server is protected by a PG with several folders on different volumes.
    My issue is that one of the folder, which is the only one protected on the volume, is inconsistent.

    The disk allocation detail for this replica/Datasource shows :
    Replica volume: 83.09 GB allocated, 92.32 MB used | Recovery point volume: 34.80 GB allocated, 90.82 MB used

    The replica volume used is surprisely small compared to the amount it should be, around 50GB.

    Multiple consistency checks do not change anything and the datasource is always as “Replica is inconsistent”.

    I tried both replica creation methods, automatic and manual, in an external protection group without any success.

    If anybody knows how to resolve this, it will be greatly appreciated.

     Thanks

     

    Thursday, August 19, 2010 12:17 PM

Answers

  • Problem Resolved.

    After troubleshooting in every way I could, I found some information in the System Volume Information folder of the E:\ of the file server where I had the issue.

    Steps that I followed:

    - stop protection on the volume, but keeping the data

    - stop DPMRA on the file server

    - delete file DpmFilterStatus in the System Volume Information folder of the E:\

    - start DPMRA

    - modification of the pg to add the folder

    - consistency check

    After this I was able to see that Data was transfered the datasource, right now I have more than 20GB transfered.

    From there I think I'm good.

    Thanks for helping me

    Friday, August 20, 2010 12:11 PM

All replies

  • You don't give the DPM error message as to what is causing teh replica to be inconsistent so my advice is geared towards the basic steps.

    Stop protection on that particular volume (right click, stop protection of member). Choose "Delete the replica on disk" from the next menu.

    Connect to the file server itself, ppen a command prompt and run: vssadmin list writers

    Check all the writers are stable, no error. If any errors are showing then reboot the server and run the command again. If no errors are showing, restart the DPMRA service on the file server and try adding in the protected volume again. Initial replica creation is very network intensive so if you are creating it across a WAN link then be sure to use bandwith throttling, if on a LAN maybe wait until outside business hours to kick it off.

     

     

    Friday, August 20, 2010 7:37 AM
  • Thank you very  much for your reply.

    I apologize for the lack of information with regards to DPM error messages, nothing is reallly coming up as an error.
    Seems like for DPM everything is fine until is doing a sync, put the replica as inconsistent.
    Once a consistency check is runned, the replica is back to an OK state but without any recovery point created.
    When I try to create a recovery poing manually, only the "Create a recovery point without synchronizing" is available, and it failed.

    I followed the steps that you gave me. Unfortunatly the issue still remains.

    After the modification of the PG to add the folder in it, I have 2 jobs running, one for the creation of the replica and the other for the creation of the recovery point.
    I have 2 log entries in the DPM Alters event log with the same message in it:
    The replica of E:\ on <server_name> is being created. After the initial copy is made, only incremental changes are synchronized. (ID: 3105)
    There is only 33 seconds between them.
    Nothing really shows on the file server, regular logs with VSS starting up and shutting down.

    DPM error message when replica is inconsistent:
    Affected area: E:\
    Occurred since: 8/20/2010 10:24:02 AM
    Description: The replica of Volume E:\ on <Server_Name> is inconsistent with the protected data source. All protection activities for data source will fail until the replica is synchronized with consistency check. You can recover data from existing recovery points, but new recovery points cannot be created until the replica is consistent.
    For SharePoint farm, recovery points will continue getting created with the databases that are consistent. To backup inconsistent databases, run a consistency check on the farm. (ID 3106)
     The change journal ID may have changed since the last synchronization. DPM is unable to track changes on this computer. (ID 30119 Details: Internal error code: 0x809909D2)
     More information
    Recommended action: 
     Synchronize with consistency check.
     Run a synchronization job with consistency check...
    Resolution: To dismiss the alert, click below
     Inactivate alert

    My DPM 2010 is installed on a W2k8R2 and the file server is also a W2k8R2.


    I tried the solution to disable chimney option on both servers  with the command: netsh int tcp set global chimney=disabled
    It didn't change anything.

    Friday, August 20, 2010 8:35 AM
  • Problem Resolved.

    After troubleshooting in every way I could, I found some information in the System Volume Information folder of the E:\ of the file server where I had the issue.

    Steps that I followed:

    - stop protection on the volume, but keeping the data

    - stop DPMRA on the file server

    - delete file DpmFilterStatus in the System Volume Information folder of the E:\

    - start DPMRA

    - modification of the pg to add the folder

    - consistency check

    After this I was able to see that Data was transfered the datasource, right now I have more than 20GB transfered.

    From there I think I'm good.

    Thanks for helping me

    Friday, August 20, 2010 12:11 PM