Since we have completed all the pre-requisites required to back up a vSphere pod using Velero in the previous three blogs, we will look into the procedure of backing up and restoring the pod in this blog.
Step 1: I have created a namespace called “vsphere-pods” and deployed a nginx pod into it.
Step 2: Verify if the backup location is still Available using the following command: velero backup-locations get
Step 3: Initiate a backup of the namespace using the following command: velero backup create nginx-backup –include-namespaces=vsphere-pods
On successful completion you should see the following output.
Step 4: Describe the backup and identify if completed successfully.
In my case, the backup shows partially failed. To identify what went wrong, we run velero backup logs nginx-backup.
Though it complained about a failure, the final excerpt from the logs shows that 30 items were backed up as shown in the velero backup describe command. Then why partially failed? So I dug deeper for error messages in the backup logs and here is what I found.
“rpc error: code = Unknown desc = Resource CRD nsxlbmonitors.vmware.com is blocked, skipping“
Since there are no services (which in turn creates a NSX LB) in the namespace, I am going to safely ignore this error message and proceed with the restoration from the backup.
Just before I initiate a restore I would like to demonstrate the working instance of the nginx pod.
Now I will make an edit to the index.html file of the nginx pod just to differentiate the outputs once the pod is restored. To edit the index.html file, you need to exec into the pod using kubectl exec -it -n <namespace> <podname> — /bin/bash and then edit the file using vi file editor as shown in the screenshot below. Please note not all nginx container images have a file editor installed on them. You may have to install vi using the package, if you are unable to use vi inside the container.
As highlighted above, I have made three changes to the config file inside the container. And then when I tried accessing the page, I see the below output as expected.
Step 5: Let us now restore the backup using the following command.
velero restore create nginx-restore --from-backup nginx-backup --namespace-mappings vsphere-pods:vsphere-pods-restoredIf you notice the command, I have used a namespace-mappings flag. What this essentially does is that, it creates the pod (restored) on a new namespace instead of the original namespace it was backed up from. In my case, the new namespace is named vsphere-pods-restored and this has to be pre-created before you perform the restore. If you don’t create this namespace, then your existing pod will go into a “AgentUnreachable” state and the restored pod will go into a “PodVMCreationFailed” state and it will restore the pod with the same name into the same namespace, there by causing a conflict.
After running the command, you should now see the following output.
and with describe you should see the following
UI and CLI output screenshots below
Conclusion
We have successfully restored a vSphere pod. As part of the validation process, I am going to curl to both the IP addresses to show the difference.
As an additional validation, I redid the backup again after the change was made and restored the pod to another namespace as shown in the screenshot below.
Now when I did the curl compare, here’s what I see 🙂
It still DID NOT capture the change, because the change isn’t something that the etcd database might have been made aware of as this was made inside a running process/container. The change lives only during the lifetime of the pod. Once the pod is deleted and the deployment recreates it, the changes to the conf file will already be gone.
And with that, I conclude this series of blogs on Velero and vSphere. I hope, by now, you would have at the least got to know a thing or two about Velero 🙂
Feel free to reach out to me for questions, if you have any!
Happy learning!
