Save to My DOJO
As mentioned in my Backing up vCSA 6.5 natively using FTPS and How to natively backup vCSA using IIS and HTTPS posts, vCSA 6.5 can be natively backed up using a file-based approach where the resulting backup files are transferred to a remote share or repository using protocols such as HTTPS and FTPS.
This post is about restoring the appliance from backup using the vCenter Server installer inbuilt option as shown in Figure 1 below. The restore process is in fact almost identical to the 2-stage process used when installing vCSA. When performing a restore, a shell vCSA is created during Stage 1 followed by the application of the vCSA’s original configuration extracted from backup during Stage 2.
Today, I’ll be covering how to restore vCSA from a backup using the FTPS method. Let’s dig in.
Stage 1 – Creating the vCSA
1] Mount the vCSA installer ISO and run installer.exe from \vcsa-ui-installer\win32 assuming you’re running this on Windows.
2] Select the Restore bottom-most option as shown in Figure 1.
3] Press Next on the Introduction screen (omitted).
4] Accept the EULA by ticking on the option at the bottom and pressing Next (omitted).
5] On this next screen (Fig.2), the details for the FTPS backup location are specified. In this case, I’m using FTPS on IIS. During this step, I ran into an issue related to how the installer tries to access the FTP root folder. Using the same setup, I had no issues backing up to 192.168.11.167/. This however was not the case when restoring using the same path as I kept getting the error message shown in Fig. 2. To work around this annoyance, I simply created a folder called root under the ftp root directory and moved the backup files to it. I then specified the full path in the Location field. This could be a bug or just an IIS quirk although it must be said that I did not come across the same behavior when testing with other FTP clients. Regardless, pressing Next takes you the the next screen, a review of the backup information. Press Next once more.
6] Type in the details for the ESXi host or vCenter Server where you want the vCSA created. Press Next when done.
7] Press Yes to accept the Certificate Warning and continue.
8] Specify the VM folder – if applicable – under which the vCSA is created and press Next.
9] Specify the ESXi host on which you want the vCSA created. This really only applies if you’ve specified a vCenter Server as the deployment target. Press Next.
10] Pick a name for the vCSA (the one you’ll see listed in the inventory). Make sure that the name does not exceed 80 characters and excludes any of the following: %, \, /.
11] Here you’re given the option to change the original vCenter Server deployment size. If you do, remember to change the hardware resources accordingly. Press Next to continue.
12] Select the datastore where the vCSA will reside and press Next.
13] The details on this screen are populated automatically from the info retrieved from the backup-metadata.json file created when the backup was taken.
14] Press Finish on the last screen (omitted) to start the restore process.
Stage 2 – Restoring the original configuration
15] After Stage 1 completes, press Continue to move on to Stage 2 at which point, the configuration from the backed up vCSA is restored to the new one.
16] Stage 2 simply involves pressing Next, Next and Finish respectively. Prior to the restore, you are warned that pausing or cancelling the restore process is not possible.
What can go wrong?
Apart from the FTP root path issue mentioned earlier, I also came across a couple more issues, which is a good thing really since in my opinion, there is no better way to learn than experiencing problems firsthand and solving them.
The first hiccup was my doing to be honest. I specified the wrong portgroup on the network configuration screen during Stage 1 (Fig. 10 above). This particular portgroup happens to have no external network connectivity so when Stage 1 finished, Stage 2 was unable to talk to the new vCSA after it was powered on. It would have been great if VMware added a Back button of sorts since Stage 2 simply quits on you if it can’t continue.
After changing the portgroup to the correct one from the vCSA VM’s network connection setting, I was able to resume Stage 2 via VAMI i.e. https://<VCSA IP address>:5480 logging in as root. Once there, you just need to select the Restore From Backup option to continue the restore process.
The only difference here is that the FTPS details need to be typed in as opposed to being populated automatically.
The restore process quietly resumes and in my case, it completed successfully.
Another issue I came across during Stage 1 is that one cannot use the same IP address if the vCSA being restored is still active and part of the vSphere inventory. In a sense this should be obvious but the documentation is rather hazy about this. The work around of course is to pick a different address, install and then change the IP back to the original one after the restore operation has completed. To change the IP, just launch the vCSA Web Console (VAMI) and navigate to Networking -> Manage -> Networking Interfaces (Fig. 23a and 23b). Also note that the original vCSA is not powered off automatically when a different IP is set so you may end with two instances of the same vCSA albeit with different IPs.
Once there, click on the Edit button to change the IP address back to the original setting.
The caveat to this is that after committing the change, the browser keeps targeting the original IP address where you essentially end up with an unresponsive VAMI instance. I’m assuming that the connection will eventually time out but time being precious, I just pressed cancel and verified that the vCSA responded to the amended IP address which was indeed the case. I also verified that all the vCSA’s original settings and configuration were successfully restored via the vSphere Web Client.
This post brings to an end a series of three posts covering the native bckup capabilities of vCSA 6.5. I’ve covered how to set up HTTPS and FTPS using an IIS Web Server and how using VAMI once can backup the vCSA and transfer the resulting files to a remote share using any of the aforementioned protocols.
To summarize, I’ve covered how to restore a vCSA from an FTPS enabled location using the vCSA installer. I should also mention that while native backup is a very useful tool to have, one should not entirely rely on it. Instead you should use it in conjunction with scheduled full image backups using products such as Altaro VMBackup. Apart from the added peace of mind, dedicated backup software makes it intrinsically easier to automate and schedule backups. Having said that, native backup is without doubt a terrific feature as it gives you the ability to offload backup files to a remote location over HTTPS and other protocols. Just remember to tick the encrypt option when selecting unsecured protocols.
[the_ad id=”4738″][the_ad id=”4796″]
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!