Step 1

Log in to your Cisco Nexus Dashboard and open the Cisco Nexus Dashboard Orchestrator service.

Step 2

From the left navigation pane, select Admin > Backup and Restore > Remote Locations tab.

Step 3

In the top right of the main window, click Create Remote Location.

Step 4

Provide the name for the remote location and an optional description.

Step 5

Specify the host name or IP address of the remote server.

Step 6

Provide the full path to a directory on the remote server where you save the backups.

Step 7

Specify the port used to connect to the remote server.

Step 8

Specify the authentication type used when connecting to the remote server.

Step 9

Click Save to add the remote server.

Step 1

Log in to your Cisco Nexus Dashboard Orchestrator.

Step 2

Backup existing deployment configuration.

1. From the left navigation pane, select Admin > Backups & Restore.

2. In the main window, click Create New Backup.

   A New Backup window opens.

3. Provide the backup information.

   • In the Name field, provide the name for the backup file.

     The name can contain up to 10 alphanumeric characters, but no spaces or underscores (_).

   • From the Remote Location drop-down, select a remote location that you have configured for storing backups.

   • (Optional) In the Remote Path, provide the specific directory on the remote server where to save the backup.

     The directory that you specify must exist.

4. Click Save to create the backup.

Step 1

Log in to your Cisco Nexus Dashboard Orchestrator GUI.

Step 2

If necessary, undeploy existing policies.

Step 3

From the left navigation menu, select Admin > Backups & Restore.

Step 4

In the main window, click the actions (...) icon next to the backup you want to restore and select Rollback to this backup.

Step 5

Click Yes to confirm that you want to restore the backup you selected.

Step 6

Using REST API calls, validate if NDO-managed policy IDs match across fabrics.

1. Log into your NDO through the REST API:

   POST https://{{ndo-ip}}/login

   Request Body:

   {"userName":"<username>","userPasswd":"<password>","domain":"<domain>"}

   For example:

   POST https://192.168.0.1/login

   Request Body:

   {"userName":"admin","userPasswd":"MyNDOPassword","domain":"DefaultAuth"}

2. Post a GET policy-report API with validate=true for all tenants managed by this NDO.

   Request:

   GET https://{{ndo-ip}}/mso/api/v1/policy-report?tenants=<comma separated list of tenants...>&validate=true

   For example:

   GET https://192.168.0.1/api/v1/policy-report?tenants=T-policyreport,T-migration&validate=true

   The following is an example response:

   {
       "sites": [
           {
               "id": "66903a7f5c1ced5eebed97ec",
               "apicId": "1",
               "name": "fabric-1"
           },
           {
               "id": "668eeb235c1ced5eebed97eb",
               "apicId": "2",
               "name": "fabric-2"
           },
           {
               "id": "60309f0b11000059b8d16c9d",
               "apicId": "3",
               "name": "fabric-3"
           }    
       ],
       "policies": {
           "uni/tn-T-migration/BD-BD-singlesite": [
               {
                   "apicId": "1",
                   "vnid": "16056263",
                   "peerContexts": [],
                   "remoteMappings": {},
                   "importRemoteIds": [],
                   "exportFlag": false
               }
           ],
           "uni/tn-T-migration/ctx-VRF-singlesite": [
               {
                   "apicId": "1",
                   "vnid": "2490368",
                   "ctxPcTag": "16386",
                   "peerContexts": [],
                   "remoteMappings": {},
                   "importRemoteIds": [],
                   "exportFlag": false
               }
           ],
           "uni/tn-T-policyreport/ctx-VRF-validation": [
               {
                   "apicId": "1",
                   "vnid": "2719745",
                   "ctxPcTag": "16386",
                   "peerContexts": [],
                   "remoteMappings": {
                       "11": "3112961, 49153"
                   },
                   "importRemoteIds": [],
                   "exportFlag": false
               }
           ],
           "uni/tn-tenant1/BD-BD1": [
               {
                   "apicId": "2",
                   "vnid": "15925212",
                   "peerContexts": [],
                   "remoteMappings": {
                       "1": "15728629",
                       "3": "15761391"
                   },
                   "importRemoteIds": [],
                   "exportFlag": false
               },
               {
                   "apicId": "1",
                   "vnid": "15859694",
                   "peerContexts": [],
                   "remoteMappings": {
                       "2": "15925212",
                       "3": "15761391"
                   },
                   "importRemoteIds": [],
                   "exportFlag": false
               },
               {
                   "apicId": "3",
                   "vnid": "16711549",
                   "peerContexts": [],
                   "remoteMappings": {
                       "1": "15728629",
                       "2": "15925212"
                   },
                   "importRemoteIds": [],
                   "exportFlag": false
               }
           ]    
       },
       "validation": {
           "uni/tn-T-policyreport/ctx-VRF-validation": [
               "Fabric id 1 and 2 do not have the same site list for this DN. (1: [1 11], 11: [])",
               "Fabric id 1 does not have the correct number of remote mappings for this DN."
           ],
           "uni/tn-tenant1/BD-BD1": [
               "Site id 2 and 1 have pcTag mismatch for this DN. (2: {2 15925212  [] map[1:15728629 3:15761391 4:15794150] [] false}, 1: 15728629)",
               "Site id 2 and 3 have pcTag mismatch for this DN. (2: {2 15925212  [] map[1:15728629 3:15761391 4:15794150] [] false}, 3: 15761391)",
               "Site id 1 and 3 have pcTag mismatch for this DN. (1: {1 15859694  [] map[2:15925212 3:15761391 4:15794150] [] false}, 3: 15761391)",
               "Site id 3 and 1 have pcTag mismatch for this DN. (3: {3 16711549  [] map[1:15728629 2:15925212 4:15794150] [] false}, 1: 15728629)"
           ]
        }
   }

3. Determine if any NDO-managed policy IDs have a mismatch across fabrics.

   • If you do not see validation responses similar to the ones highlighted in the example responses above, then all NDO-managed policies exist across the fabrics as expected and their IDs match (the "validation" json holds information about policies that have mismatches).

     You do not have to take any further action in this case; the recovery process is complete.

   • If you do see a validation response similar to either of the ones highlighted in the example responses above, then there are NDO-managed policy IDs that have a mismatch across the fabrics.

Step 7

If there are NDO-managed policy IDs that have a mismatch across the fabrics, check if any templates contain configuration drifts.

Step 8

Determine your next course of action based on the result of the check on the configuration drifts.

Step 9

If any template contains a configuration drift, resolve the conflicts.

1. Close the template deployment dialog to return to the Schema view.

   Deploying any templates at this point would push the values in the Orchestrator database and overwrite any existing settings in the fabrics.

2. From the template's Actions menu, select Reconcile Configuration Drifts.

   

   The Drift Reconciliation wizard opens.

3. In the Drift Reconciliation screen, compare the template-level configurations for each site and choose the one you want.

   

   Template-level properties are common across all sites that are associated to the template. You can compare the template level properties that are defined on Cisco Nexus Dashboard Orchestrator with the configuration that is rendered in each site and decide what should become the new configuration in the Cisco Nexus Dashboard Orchestrator template. Selecting the site configuration modifies those properties in the existing Cisco Nexus Dashboard Orchestrator template, whereas selecting the Cisco Nexus Dashboard Orchestrator configuration keeps the existing Cisco Nexus Dashboard Orchestrator template settings as is.

4. Click Go to Site Specific Properties to switch to site-level configuration.

   

   You can choose a site to compare that specific site's configuration. Unlike template-level configurations, you can choose either the Cisco Nexus Dashboard Orchestrator-defined or actual existing configurations for each site individually to be retained as the template's site-local properties for that site.

   Although in most scenarios you make the same choice for both template-level and site-level configuration, the drift reconciliation wizard allows you to choose the configuration defined in the site's controller at the "Template Properties" level and the configuration that is defined in Cisco Nexus Dashboard Orchestrator at the "Site Local Properties" level or conversely.

5. Click Preview Changes to verify your choices.

   The preview displays full template configuration adjusted based on the choices that are picked in the Drift Reconciliation wizard. You can then click Deploy to sites to deploy the configuration and reconcile the drift for that template.

Step 10

Perform a full redeployment of the template.

You will perform a full deployment of a template in either of these situations:

• You found one or more templates that contain a configuration drift, and you resolved the conflicts using the instructions in Step 9. After all configuration drifts are resolved and there are no changes that are shown in the Deploy to sites dialog for the template, perform full redeployment of the template.

  or

• No template contained a configuration drift but you found NDO-managed policy IDs that have a mismatch across the fabrics in Step 6. The policy names with their tenant names are listed in the validation report in that step. In this case, you must find the templates that hold these policies and redeploy those templates. Redeploying each of those templates pushes the IDs across the fabrics again and resolves the mismatches.

  Once you have redeployed all of the necessary templates and the GET policy report API does not find any mismatches, then the recovery procedure is complete.

  Note	We recommend that you do not redeploy templates if you are running on NDO release 4.2.3j or lower versions because of a known defect (CSCwj99109). This defect is resolved in NDO release 4.2.3k and later.

Note	Due to database transformations, you must perform a full redeployment of each template.

Ensure that the Deploy to sites dialog contains no changes as shown in the following figure, then click Deploy to redeploy complete configuration:

Step 11

Repeat the above steps for every schema and template in your Cisco Nexus Dashboard Orchestrator.

Step 12

Check audit logs to verify that all templates have been redeployed.

Step 1

Log in to your Cisco Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Admin > Backups & Restore.

Step 3

In the main window, click the actions (...) icon next to the backup you want to download and select Download.

Step 1

Log in to your Cisco Nexus Dashboard Orchestrator.

Step 2

From the left navigation pane, select Admin > Backups & Restore.

Step 3

In the main pane, click Upload.

Step 4

In the Upload from file window that opens, click Select File and choose the backup file that you want to import.

Step 5

From the Remote Location drop-down list, select the remote location.

Step 6

(Optional) Update the remote location path.

Step 7

Click Upload to import the file.

Step 1

Log in to your Cisco Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Admin > Backups & Restore.

Step 3

In the top right of the main pane, click No Schedule.

Step 4

Set up backup scheduler.

1. Check the Enable Scheduler check box.

2. In the Select Starting Date field, provide the day when you want the scheduler to start.

3. In the Select Time fields, provide the time of day when you want the scheduler to start.

4. From the Select Frequency drop-down, choose how often the backup should be performed.

5. From the Remote Location drop-down, select the location where the backups will be saved.

6. (Optional) In the Remote Path field, update the path on the remote location where the backups will be saved.

   The target directory on the remote server, which you configured when creating the remote backup location, will be displayed in the Remote Path field.

   You can choose to append extra subdirectories to the path. However, the directories must be under the default-configured path and must have been already created on the remote server.

7. Click Save to finish.

Step 5

If you want to disable the backup scheduler, simply uncheck the Enable Scheduler check box in the preceding step.