- Part 1 – Windows SFTP Backup Targets
- Part 2a – Using NSX-T to Test NSX-T and Virtual Machine Recovery with Automation – Conceptual
- Part 2b –Using NSX-T to Test NSX-T and Virtual Machine Recovery with Automation – Practical
Now that the Healthcare organization has completed their journey of migrating from NSX Data Center for vSphere over to NSX-T Data Center, it’s time to do a bit of day 2 configuration, specifically configuring the backups of the NSX-T Manager.
The infrastructure admins that are currently in charge of running the NSX-T environment for the organization are expanding their scripting knowledge a bit and working on automating many of the configurations and operations that NSX-T Data Center requires. The first area where some simple scripting can help is around configuration and management of NSX-T Backups.
Typically, the admin could go into the NSX-T Manager UI and perform these configurations via the UI.
Since the admins are wanting to expand their knowledge in scripting and using REST APIs, and the plan is to bring this knowledge forward into performing and checking NSX-T restores later, they’ve opted to use a different approach.
- Setup Backup configuration for the NSX-T Manager with an eye on automation
- At least 3 backups per day and automatic backups after configuration changes
- Maintaining at least 30 days of backups for the NSX-T Manager
Requirement 1 – Setup Backup configuration for the NSX-T Manager with an eye on automation
Requirement 2 – At least 3 backups per day and automatic backups after configuration changes
The first two requirements can be handled with one straightforward approach. The organization currently has a Cerberus SFTP server that backs up configuration from other devices on their network. It’s a FIPS 140-2 compliant software package that will work well with NSX-T. This software package runs on a Windows Server 2016 machine for the organization to store the backups. Consulting the official NSX-T documentation for Backup and Restore, the admin finds the required items to be able to perform the configuration. The information is put into a chart for documentation purposes so that they can be tracked and the infrastructure and security team know the settings being used.
Now that the settings have been documented accordingly, the admin can take a further look at how to configure the settings in NSX-T. The admin has decided that they will take the following approach around automating the installation of the configuration. They will use the NSX-T REST API to perform the configuration using the documented settings. To be able to do this a few things will need to happen.
- Installation of a REST API client – Postman
- Code example from the NSX-T Data Center API Guide for configuration and testing backups
This post will not go into the installation of Postman, it’s a simple installation. The following configuration is however needed to properly ensure Postman will call the NSX-T Manager REST API.
After consulting the NSX-T Data Center API Guide, the following code was pulled that should provide the necessary single API call to configure the NSX-T Manager backup schedule.
Example code for backup configuration:
Taking the information collected during the documentation process, the admin can now substitute in the organization-specific configuration that will be used for the body of the REST API call.
Organization-specific code for backup configuration:
When the admin pastes the above configuration into the body of the REST API PUT command and sends the command, they receive a Status 200 OK meaning the command was realized and accepted.
There are several ways that the admin can check the work, but the Status 200 OK will display the result from the command in the Body section from the response. It is also possible to change the same command from PUT to GET and resend it to get the same result.
With the configuration in place, the admin can issue another command via the REST API that will initiate a backup from the NSX-T Manager to the SFTP server.
Running this command will take some time to send the request and get a response as the actual process of performing the backup needs to take place and send back a Status 200 OK which is only sent when the backup actually completes successfully. As you can see from the Postman output below, the request took 1 minute and 1.08 seconds to actually perform the command.
The admin can now go into the NSX-T Manager UI and check the configuration and backup status visually as well and it appears that all is configured properly and backing up to the SFTP server as they’d expect it to.
The admin also takes a quick look at the SFTP server and the backup directory to check that files have been created.
Requirement 3 – Maintaining at least 30 days of backups for the NSX-T Manager
To meet the last requirement, while still maintaining Requirement 1 around an eye for automation, the admin needs to find a way to only keep 30 days of backups for the NSX-T Manager. The official NSX-T documentation has several scripts that can be run on Linux-based systems and coupled with a cron job, can be used to clean up the backup directory on an automatic and scheduled basis. However, there are no scripts supplied for Windows-based SFTP systems and the Healthcare organization is using a Windows machine for their SFTP server. The admin decides to create their own script using PowerShell and using a Windows Scheduled task to provide the same benefit.
Taking a look at the SFTP server, the admin can see that there are several folders created for the backup files.
- ccp-backups – Contains .tar files of the Control Plane backup for NSX-T
- cluster-node-backups – Contains .tar files in date specific folders for the NSX-T Manager/Policy/Controller Cluster and each individual NSX-T Manager backup
- inventory-summary – Contains .json files for every inventory object in the NSX-T Manager backup
Each of these folders contains multiple files after a backup occurs for NSX-T. Below is an example:
The admin determines that the easiest way to handle this is to use PowerShell to create a script that will automatically look for files older than 30 days and remove the folders and files within the folders appropriately. The code looks like this and can be found on GitHub as well.
The admin tests this script by changing the $Daysback variable in the script to -0 as that will delete all of the backups that have been taken thus far. Running the script, the admin can see that all of the backups have been removed and the folder structure for the backups is still intact.
After running the backup again, the admin can see that the new backup files are present in the folder.
With the script working as intended, the admin can now create a Windows scheduled task to call the PowerShell script on a nightly basis to clean up the SFTP backup directory
With the task created, the admin runs the task manually and verifies that the current backup is removed as intended. The admin can now run a current backup of the configuration and change the $Daysback variable to -30 again.
The requirements have been fulfilled and the admin can now move onto the next task which is testing the backup and restore process in Part 2.