CloudShell Version: 9.0 GA

Help Version: 2.1

Api Guide
View / Download All Help Versions
Online Help

This help article applies to CloudShell 9.0. To see the latest, click here.

You are here: Sandboxes > Saved Sandboxes Dashboard > Restore a Saved Sandbox

Restore a Saved Sandbox

Restoring a sandbox is part of the Save and Restore paid add-on. Contact your account manager to obtain a license. For additional information about this add-on, see the Sandbox Save and Restore Overview

In CloudShell, you can restore a saved sandbox to the exact state of the sandbox when it was saved. The saved sandbox is an independent copy of the original sandbox, and can be restored to multiple sandboxes.

The restore script is available out-of-the-box. It is a part of the setup process and when restoring a sandbox, it actually replaces the setup script. To customize the restore script, see the CloudShell Dev Guide.

In this article:

Restoring a saved sandbox

To restore a saved sandbox:

  1. In the Saved Sandboxes dashboard, click the Actions button at the end of the row and select Restore.

    The Restore dialog box is displayed.

  2. In the Schedule field, you can set the required restored sandbox duration in weeks, days, hours and minutes.

    Note: You cannot set the saved sandbox to be restored at a future time.

  3. You can view and edit the Name of the restored sandbox. By default, the restored sandbox name is the name of the saved sandbox.

  4. You can view the name of the Saved Sandbox. This field is not editable.
  5. To specify additional options, click the Advanced Form button.

    The advanced form enables you to configure the email notifications, permitted users, and other options.

    1. Optionally enter a Description. Otherwise, the description of the restored saved sandbox will use the saved sandbox description.
    2. To define a sandbox owner, click Owner and select the required user. By default, the user who initiated the restore action is set as the sandbox owner.
    3. Instead of changing the owner of the restored sandbox, you can permit additional users to use the sandbox. Click the Permitted Users section and select the users you wish to add.
    4. You can configure CloudShell to send email notifications to the owner of the restored sandbox and permitted users.

      Note: This capability requires the administrator to activate the email notifications feature using the ReservationEmail configuration keys.

      1. Click the Email Notifications field.

        The Email Notifications area expands.

      2. Configure the email notification settings.
        1. On start - Sends notification as the restore saved sandbox starts.
        2. Before end - Sends notification before the Teardown process begins. The exact time is decided by the user.
        3. On end - Sends notification when the sandbox ends.
    5. If the original blueprint had inputs, they are displayed here. Values are taken from the saved sandbox and are not-editable.
  6. Click Restore.

    The saved sandbox is restored to the state when the sandbox was saved. Once the sandbox is restored, the sandbox state changes to Active.

    CloudShell restores the saved sandbox, its elements and configurations, as well as the states of the sandbox and its elements.

Sandbox restore logic

Currently, CloudShell Save and Restore applies only to vCenter-based virtual sandboxes and sandboxes with CloudShell services. Apps of other cloud providers, inventory resources or static vCenter VMs are not supported and therefore, you cannot save and restore a sandbox which contains any of these elements.

The elements of the saved sandbox that are restored directly reflect the elements that were saved when you saved the sandbox. For information on the save logic, see Sandbox save logic.

There are, however, a number of important points that you should consider when restoring a saved sandbox:

  • Apps that were not deployed in the original sandbox will be deployed, using their defined deployment path. Since clones are not created for undeployed Apps when saving the sandbox, CloudShell will need to deploy the Apps' using their deployment path, in the same way a regular App is deployed during sandbox setup.

  • All L2 connections are established in the restored sandbox, regardless of their state (connected/disconnected) in the original sandbox.

  • Since new VMs are created in the restored sandbox, the IP and MAC addresses of the VMs may differ from the original sandbox. You may need to adjust the Restore script as a result of this change.

  • If the original sandbox contained any virtual traffic generator VMs loaded with a test configuration, the test configuration will need to be reloaded either automatically by the Restore script or manually after the sandbox is restored.

  • If the original sandbox contained any VLAN Auto services, the VLAN IDs allocated in the restored sandbox may differ.