VDP 6 Replication Target Hangs Booting Up After NAS Moved OFFSITE

[techguyau]

Hi All,

My environment is vSphere 6 with 2x VDP Appliances (one for local backup and one as a replication target for a offsite NAS)

Disk Structure:

VDP (local): VDP.vmdk -> On local SAN

                    6x backup storage -> NFS-Onsite NAS

VDP-RT (offsite): VDP-RT -> On local SAN

                              6x backup storage -> NFS-Offiste NAS (roughly 25-30ms latency)

I configured both appliances onsite and replicate (roughly 1.3TB). I then shutdown and remove the replication target from inventory. Dismount the NFS datastore. Move the NAS offsite. Re-mount the datastore, add VDP-RT to inventory .. reconfigured the disks for the VDP-RT and try to boot and it the appliance hangs and this pointin the startup sequence.

I have left it for approx 12 hours with no change.

If i try to re-create the appliance and attach the existing VDP storage to the new appliance the new appliance will get through most of the configuration except hang at VDP: Configuring Import Storage task (stuck at 52%) for still over 12 hours.

I have gone through this process 2-3 times now and am still running into the same issue.

Am i missing something? Surely it cannot be thus hard to move my replication target storage offsite.

Kind Regards

Arun

[RyanJMN]

I suggest trying to power on the replicate VDP appliance and re-ip.  It isn't well documented by VMware but you can find other posts in this community on which configuration files need to be updated.  I avoid importing storage whenever possible.  VDP replication jobs are efficient on bandwidth requirements.  If at all possible its a lot easier to just use VDP replication over the WAN from the beginning instead of trying to seeding through physically moving hardware.

[techguyau]

Hey Ryan,

Thanks for replying.

The replicate VDP did manage to boot up but Core services will not start (spinner is constantly checking if they are up on the appliance).. Considering it took almost 24 hours to boot I dont necessarily want to reboot it either.. Can these be restarted manually by the command line?

Ill look into re-iping the appliance and search the forums. Thanks alot for your advice.

If all else fails I may just need to deploy over the WAN and wait the week while it replicates out!

Regards,

Arun

[BradI100]

I suggest trying to power on the replicate VDP appliance and re-ip.  It isn't well documented by VMware but you can find other posts in this community on which configuration files need to be updated.  I avoid importing storage whenever possible.  VDP replication jobs are efficient on bandwidth requirements.  If at all possible its a lot easier to just use VDP replication over the WAN from the beginning instead of trying to seeding through physically moving hardware.

Before stumbling on this thread, I did an "offsite seed".  And while I was able to get it to start working, I am trying to tune it because of bandwidth limitations.  Can you tell me more about what you mean by VDP replication jobs are efficient on bandwidth requirements?  I may need to recreate the whole thing and start an offsite sync.

Thanks

[RyanJMN]

VDP replication is bandwidth efficient because of variable length deduplication and synthetic aware replication.  A few other products can do variable length deduplication but VDP\Avamar\Data Domain are the only ones I'm aware of that can do synthetic aware replication.  For the most part there are no full\incremental cycles.  In general after first replication job completes all other replication jobs will only require an incremental amount of data transferred although a restore is a full.  Existing files are hashed before deduplication.  If data doesn't change VDP doesn't have to re-save the data or replicate it.  Only unique data is compressed and transferred.

If you already have the replication job configured and they are not completing regularly I would look at the cli commands listed bellow.  There are to many variables to make it an exact science but you should be able to estimate approximately how much bandwidth is required.

mccli activity show

This command will show you all jobs that ran in the last 72 hours.  It will show you new bytes percentage per job.  This tells you how much unique data was added to disk.  There will be some overhead when transferring the data over the network but most of the time its minimal.

capacity.sh

This command tells you per day how much data was added and subtracted.  If everything is being replicated with the same retention this will be approximately how much data gets transferred over the network.  Also there will be some overhead but most of the time its minimal.

If your using a data domain there are a few other things to keep in mind.  The primary one is make sure you use DDOS 5.5 or newer.