Traditionally, the process to upgrade a vSphere Data Protection (VDP) virtual appliance to the latest version has been to use an upgrade ISO and perform an in-place upgrade. The upgrade to VDP 6.1 is an exception – it is more of a migration. For starters, you can only migrate from VDP 5.8.x or VDP 6.0.x to 6.1. VDP 5.8.x and VDP 6.0.x are built on SUSE Linux Enterprise Server (SLES) 11 SP1 and VDP 6.1 is built on SLES 11 SP3 and there is no direct upgrade path from SP1 to SP3. Basically, one would have to upgrade from SP1 to SP2 and then to SP3. This article describes the issue in more detail: https://www.novell.com/support/kb/doc.php?id=7012368. As you can probably imagine, it would be very difficult to automate this process so the decision was made to not offer an upgrade, but rather a migration path. Keep reading to see what this migration process looks like.
First, I’ll start with showing a few screen shots from the VDP 6.0.2 appliance – backup jobs, a replication job, and restore points. The jobs will be migrated during the deployment of the VDP 6.1 appliance.
Before starting the migration, I verified there were no backup jobs, replication jobs, maintenance jobs, etc. running. Next, I deployed a VDP 6.1 virtual appliance using the OVA downloaded from vmware.com. During the “Create Storage” step of the initial VDP configuration, there is a new option labeled “VDP Migration”. I selected this option, entered the IP address and password for the VDP 6.0.2 virtual appliance, and clicked the “Verify Authentication” button. The connection and authentication succeeded so I continued.
It is important to note that after the migration process is complete, the source VDP virtual appliance will be shut down.
I clicked Yes and the migration did not take long – about eight or nine minutes total and most of that was the time it took for the source VDP virtual appliance to shut down.
With the migration complete, I proceeded to the next step of moving the VMDKs that contain backup data from the old appliance to the new appliance. The UI makes it easy to browser datastores and select the VMDKs. The VMDK without an underscore contains the guest OS and Avamar application. The VMDKs with underscores in the name contain the backup data.
Validation of the disks is completed and the rest of the initial configuration wizard is completed as in previous versions of VDP. The VDP virtual appliance reboots as part of the initial configuration process. During this time, I checked the VMDKs of the 6.1 appliance and, as expected, a new guest OS/Avamar VMDK and the existing 6.0.2 VMDKs were attached to the new VDP 6.1 virtual appliance.
The migration process does not detach the existing VMDKs from the old appliance – the 6.0.2 appliance, in my case. I had to do this manually. Just be sure you do NOT check the “delete files from datastore” checkbox for obvious reasons.
Once the new VDP 6.1 virtual appliance had completed its initial configuration and integrity check, I verified the backups jobs, backup verification job, replication job, and restore points were all there. Sure enough, they were. Mission accomplished. Of particular interest were the restore points as a new domain was created in the VDP 6.1 appliance called VDP_IMPORTS and naturally the imported restore points were found there.
I then performed some additional verification. I started by running an image backup and an application backup. I expected the image backup to success and the application backup to fail. Why the expected failure? Because I had not yet upgraded the application agent on the VM with SQL Server installed. I downloaded the new (6.1) agent for SQL Server, installed it, and tried the application backup job again. It still failed – the error was 30914. The agent was still trying to connect with the old 6.0.2 VDP appliance. In other words, you cannot perform an in-place upgrade of the agent. I uninstalled the agent and performed a fresh installation, which allowed me to specify the new VDP 6.1 appliance. I tried the application backup job again and it worked.
Here are some other items you will need to take a look at:
External proxies: These will need to be replaced – you cannot upgrade them in place.
Replication jobs: If other VDP appliances used the (old) VDP appliance as a replication target, you will need to reconfigure these replication jobs to send data to the new 6.1 appliance if a new hostname and/or IP address is used by the new appliance.
Restore to original location: You will not be able to perform a restore to original location using the restore points in the VDP_IMPORTED domain.
File level restore (FLR): FLR is possible using the imported restore points, but only after the new VDP appliance has backed up the client at least once. The advanced login option for FLR must also be used in this case.
Data Domain: If you are using a Data Domain system as a target for VDP backup data, this complicates things a bit. You will need to perform a checkpoint restore. This process is documented in the VDP admin guide. It is important to understand the following prerequisites: For the old VDP appliance, make sure there is a valid checkpoint on the Data Domain system. If checkpoint copy is not already enabled, you can enable it from Edit Data Domain wizard of the VDP Configure UI. After it is enabled, run an integrity check. Then, shut down the old VDP appliance and deploy VDP 6.1 – do not create and run any jobs (backup, replication etc.) before performing the checkpoint restore. The new VDP 6.1 appliance should be the same size as the old VDP appliance. The new VDP 6.1 appliance must have the same hostname and IP address as the old VDP appliance. After the checkpoint restore, you will likely need to disable and re-enable the internal VDP proxy. If external proxies are used, delete the old/orphaned proxies, change the password of the VDP 6.1 appliance, then deploy new external proxies.
If you are unsure about any of the items above, it might be a good idea to open a low-priority support request (SR) with VMware Support for some assistance.
@jhuntervmware
