How long does status of "rebuilding" take for a large backup to remote datac

[adidasnmotion]

We have two datacenters that are remote to each other.  We manually performed a large 11.29 TB backup of our file server VM from one datacenter to the other over a slow connection.  The backup took approximately 15 days but appears to have completed.  It shows that it transferred 10.72 TB of data (I assume its less than the original size because of deduplication).  Once it completed it changed to a status of "rebuilding".

Its been in this rebuilding status since December 16th (so for about 24 days and counting).  I just want to confirm that this is expected behavior for this amount of data for a backup that took so long to complete. and that this will eventually change to status of "protected" if we just wait long enough.

Is there some sort of formula or way to calculate how long rebuilding should take, or a way to see its progress?

[Mahesh202]

Hi adidasnmotion

Thank you for writing to us

“Rebuilding” is usually the phase where the backup goes from a single copy to a HA redundant copy on two nodes within the cluster. This may also be attempting to re-create a backup that was corrupted in transit. I recommend that you engage PM Support to verify what is going on and see if there are any underlying issues to deal with.

Hope this helps.!!

Regards
Mahesh

[steez]

Hello @adidasnmotion 

Sorry for replying to the old thread, but we have the same issue, for whatever reason remote backup for a particular VM stays in rebuilding state. Do you remember what HPE support did to fix this? Currently were working with L3/lab support in order to get this fixed, but im interested what was the cause of this in your case.

[adidasnmotion]

@steez Its been a while so I don't remember all the details.  If I remember correctly this was not normal behavior and the problem was an MTU size issue.  We had set the MTU size to the recommended 1500, but because the remote connection was over a VPN, there was some overhead.  This means that 1500 was too high and what we actually needed to do was reduce the MTU size to something like 1438 to account for the VPN overhead.  A second manual backup after the change was a lot faster (since it was only what had changed since the initial backup) and completed successfully.  Hope this helps.

[steez]

Hello @adidasnmotion, thank you for your reply.

We had similar issue with MTU and Cisco switches but for a different problem (their MTU values were not 9000 but 89xx for jumbo frames).

MTU size was the first thing support took a look at, as they were convinced that replication between remote nodes which not the case in our scenario as both clusters are L2 connected.

We need this remote backup to transfer a large critical VM. When we did second backup after the initial (which was still in rebuilding state), it showed as either degraded or protected. However we didnt want to use it as the initial data were still unprotected (living only on 1 node).