Provides an overview of the Cloud Server Snapshot feature available in some MCP 2.0 locations. To identify if this feature is currently available in a particular MCP 2.0 location, see How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location.
Cloud Server Snapshots provides a hypervisor-enabled backup solution that shares many of the characteristics of traditional VM snapshots. Cloud Server Snapshots provides the user the benefits of a backup solution which can be enabled without loading any software agents into a Cloud Server, and at the same time provides the ability to instantly restore to a known-good previous state of a Cloud Server in circumstances such as the need to recover quickly from a failed change. Cloud Server Snapshots is a feature that can be enabled for a given Cloud Server. Once the feature is enabled, the system takes periodic "snapshots" of the Cloud Server. Each snapshot is a copy of a Cloud Server’s hardware and storage state at a given point in time. Cloud Server Snapshots include the current state of all components of the Cloud Server, including server hardware configuration elements (Number of CPU, CPU Speed, RAM, Network Adapters, Storage Controllers, etc.) as well as the state of all local storage disks.
There are two types of Snapshots:
System Generated Snapshot - The system takes a daily “system-generated” snapshot periodically during a pre-determined window. The pre-determined window is chosen by the user when the Cloud Server Snapshot is enabled. When provisioning the service, users will choose an available window from a pool of windows made available on a first-come / first-served basis. Users cannot delete the system generated snapshots. The retention of System Generated Snapshots is based on the Snapshot Plan. See the Cloud Server Snapshot Plans section below for more details
Manual Snapshots (User Initiated) - Manual snapshots allow users to take a snapshot of a Cloud Server outside the time of their weekly window. For example, a user preparing for a maintenance event on a Cloud Server might take a manual snapshot prior to the maintenance to have a copy of the server state. Users can request a manual snapshot at any time but can only have a single snapshot in progress at any one time for each Cloud Server. Unlike system-generated Snapshots, manual Snapshots can be deleted. Manual Snapshots are automatically deleted by the system after 14 days. See How to Take a Manual Cloud Server Snapshot and How to View and Manage Snapshots for a Cloud Server
Once a Snapshot is created, the snapshot is stored for a given period of time (which varies depending on the snapshot "service plan" and the type of snapshot - see Cloud Server Snapshot Plans section below). So long as the Snapshot is stored, users can create new Cloud Server(s) from those Cloud Server Snapshots. The new server or servers have the same hardware configuration and storage state as the historical snapshot, giving users the ability to "roll back" to a previous state, for example back to a time before a failure or fault occurred.
Cloud Server Snapshots are useful for a variety of use cases such as:
These are simply a subset of potential ways the system can be used. There are too many potential use cases and variables to provide "best practices" around all the options, but it is helpful to provide a sample use case to get a better feel of how the Cloud Snapshot functions tie together.
We currently offer three Cloud Server Snapshot plans: One Month, Three Month, and Twelve Month. All three Snapshot plans offer the same Cloud Server Snapshot features:
In order for the System to determine whether a System snapshot failed:
CloudControl checks once an hour for the list of all snapshots, including System ones
If CloudControl does not identify a System snapshot within 12 hours of the scheduled window, it inserts a failed record with a 31-day expiry time
However, we have seen some cases where the underlying infrastructure takes more than 12 hours to complete the scheduled snapshot, in that case, the system will show both the failed record and the successful one with the same Snapshot start time.
Users can define local OS-level scripts that run before and after the vSphere snapshot used during the snapshot process
The difference between the plans relates to the retention period for these system snapshots. Each plan offers a different retention period:
|Id||Plan Name||System Snapshot Retention Period||Retention Notes|
|ONE_MONTH||One Month: 7d-4w|
Daily - 7 days
Weekly - 31 Days
|THREE_MONTH||Three Month: 14d-12w|
Daily - 14 Days
Weekly - 90 Days
|TWELVE_MONTH||Twelve Month: 31d-12w-12m|
Daily - 31 Days
Weekly - 90 Days
Monthly - 365 days
Prior to October 24, 2019, the system offered Essentials and Advanced Cloud Server Snapshot plans. For details on these plans and the end-of-sale details, see October 2019 Changes to Cloud Server Snapshot Plans.
The Cloud Server Snapshot feature is not available in all locations. To identify if it is available in a given location, and to see system constraints around the service, see How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location.
Where available, users can enable the service as described in How to Enable Cloud Server Snapshots on a Server. A few notes on this:
Some Cloud Server hardware configurations are incompatible with the Cloud Server Snapshot Service. For example, Cloud Servers with ISO files attached to CD-ROM cannot be enabled for Snapshots. Similarly, although Snapshot enablement of servers with "empty" SATA Controllers without ISO or Local Drives is allowed, users should be aware that when creating a "Snapshot Preview" server as described in How to Create a Snapshot Preview Server from a Local Snapshot, the SATA controller will not appear as part of the Snapshot Preview server.
For complete details on all unusual configurations, see preconditions in How to Enable Cloud Server Snapshots on a Server
Users can switch between Snapshot plans. For instructions on switching plans, see How to View and Manage Snapshots for a Cloud Server.
Snapshot Replication allows you to replicate System Snapshots to a secondary site in the same Geographic Region. Only System-Generated Snapshots can be replicated (not Manual Snapshots). Replication is not available in all Snapshot locations. To identify if it is available and to which locations replications can be made, see How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location.
Once Snapshot Replication has been enabled on a Cloud Server, It can take anywhere from 30 minutes to several hours for the Snapshots to be replicated to the secondary location. Replicated system snapshots are retained for the same retention time as Primary (Source) snapshots. In the secondary location, you will incur “Replicated Snapshot Hours” based on your Snapshot plan once replication is enabled.
Snapshots are replicated asynchronously to the replicated location. Once the snapshot is replicated, you will be able to create Snapshot Preview servers in the secondary location using the Replicated Snapshots. However, there are some differences in the process when creating a Snapshot Preview Server from a Replicated Snapshot:
For details, see:
The Pre and Post Snapshots feature can help ensure your snapshots can be used to create a usable server. At a technical level, taking a Cloud Server Snapshot is a two-step process:
Cloud Server Snapshots can be created either while a server is running or in a stopped state. However, the Virtual Machine Snapshot performed in step #1 is taken with the Quiesce and Memory settings set to OFF, so there are no actions taken within the Guest OS to prepare for the Virtual Machine Snapshot if the server is running. To address this limitation, the system supports the ability to configure the system to run a local script on the Cloud Server prior to taking the Virtual Machine Snapshot and to run another local script and immediately after the Virtual Machine Snapshot has been taken. Users can opt to run a Pre-Snapshot Script, a Post-Snapshot script, or both a Pre and Post Snapshot script.
Once this feature is enabled, the system will attempt to run these scripts on all Snapshots (Manual and System) for that Cloud Server. Pre and/or Post Snapshot scripts can be enabled when a Cloud Server is initially enabled for Snapshots or added on to an existing Snapshot-enabled Cloud Server. Users are required to provide Server credentials, file/path name for the script to be run, along with additional parameters when enabling this feature. Note there are limitations on supported OS and VMware Tools must be installed and running in order to use the feature. For details, see:
The Manual Snapshot function allows users to take a snapshot at any time outside the time of their weekly window as described in How to Take a Manual Cloud Server Snapshot.
We are in the process of rolling out the archival of system snapshots as described below. It is expected that most locations with Cloud Server Snapshots will eventually have archiving enabled. Announcements will be made on the status page before archiving is enabled, but users should be aware that even if a location currently does not show archiving is in place, it may be added later.
In data centers where Snapshot Archiving has been enabled after a System Snapshot has been successfully taken it will be moved from local Snapshot storage infrastructure to Archived Storage infrastructure after a certain number of days. Manual Snapshots are not archived. The time between the successful completion of the System Snapshot and when it is moved to Archived Storage can vary by Data Center. You can identify whether snapshot archival is currently being used and the specific archival policy by looking at the Data Center Specifications section of the Data Center Dashboard as described in How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location. Specifically, see the sections "Snapshot Archive Enabled" (True or False) and "Snapshot Retention Before Archive (Days)". If replication is enabled in a location, the replication policy applies to all System Snapshots stored in that location - including if that location is used as a Replication Target location by a server in another data center location.
You can identify if a System Snapshot is currently archived when viewing the list of Snapshots. The Snapshot tab of the Server dashboard will display the Archive Status of each Snapshot, indicating whether it is archived, available locally or is in the process of being downloaded from the archive.
For more details, see Navigating the Server Dashboard
Creating a Snapshot Preview Server from a Snapshot that currently resides on Archived Storage will take significantly longer than creating one from a Snapshot that is not archived as the process requires an extra step where the Snapshot is first copied ("rehydrated") from the Archival Storage infrastructure to local Snapshot storage infrastructure before a Snapshot Preview Server can be created. The timeframe to rehydrate a Snapshot depends on a number of factors, including the size of the snapshot, connectivity to the archival storage, and overall load on the Snapshot infrastructure. Be sure to allow for this extra time if you plan to create a Snapshot Preview Server from an archived Snapshot. Once successfully rehydrated from the archival storage, a Snapshot will reside on the local storage for up to 24 hours. It is important to note that only one archived Snapshot can be brought back to local storage (re-hydrated) at a time for a given Cloud Server.
File or Directory Restore operations do not require the rehydration step but may also take longer if restoring from an archived System Snapshot. See How to Restore a File or Directory from a Cloud Server Snapshot to the Cloud Server.
Many organizations have a need to retain backups for an extended period of time to meet compliance requirements, in some cases for up to 7 years. Snapshot Long-Term Retention is an add-on feature of Cloud Server Snapshot Service that allows users to specify that they want to keep a System Snapshot for a longer period than what is allowed under the Snapshot Service Plans (i.e. longer than 1 year). This feature provides a solution for Cloud Server Snapshots which is not tied to proprietary vendor formats. Long-Term Retention Images are stored using standard vSphere datastores, meaning that if the underlying technology of Cloud Server Snapshots is changed, Long-term Retention Images will not be “stuck” in a legacy vendor format.
For more information on Long-Term Snapshot Replication, see Introduction to Cloud Server Snapshot Long-Term Retention Images
Since there is no guarantee write state of the server at the time of snapshot, some applications such as databases and Active Directory servers will need additional configuration in order to ensure a restorable state based on the snapshot. Here are overview of the approach to address common scenarios:
Once enabled, you can view the Cloud Server Snapshots associated with a server as described in How to View and Manage Snapshots for a Cloud Server. The View Snapshots function allows you to view the detailed configuration of the Cloud Server at the time the snapshot was taken, as well as Snapshots that have been replicated to a secondary location.
Note that the "consistency level" provided by the Cloud Server Snapshot service varies depending on:
When a Cloud Server Snapshot is taken, it is possible that the system, at that moment, is making changes to files on the disk at the time of the snapshot. It's also possible that the application is in the middle of a thread or transaction where it is making changes across multiple files or transactions. To avoid problems when creating a Snapshot Preview server from a snapshot, you want some level of "consistency" in the snapshot - avoiding complications where the file state is "incomplete".
The Cloud Snapshot Service supports multiple levels of consistency depending on the server and application configuration:
When a Snapshot is initiated (whether Manual or System), the Snapshot will be indexed based on the state of the snapshot. In order for a snapshot to be used for a file or directory restore operation, the Index State must be Valid. There are 3 possible index states:
The index state of a Snapshot can be viewed in the Snapshot tab of the Server Dashboard. See Navigating the Server Dashboard
The purpose of having Cloud Server Snapshots is to either get access to the data from a historical snapshot or to create a replica of the server based on a historical snapshot. This section explains how to create a replica of the server. You can also restore a directory onto the protected server as described in the next section Performing a File or Directory Restore from a Cloud Server Snapshot.
Creating a new Cloud Server from a Snapshot involves two phases: Creating a Snapshot Preview Server and Migration of a Snapshot Preview Server to Production Disk Speeds. Details on each phase are described below.
The first step in the process is to create a "Snapshot Preview" server. The process differs slightly depending on whether you are creating a server from a "local" snapshot in the same data center as the original server or whether you are creating it from a "replicated" snapshot in a different data center. When using a local snapshot, the Snapshot Preview server is created on the same NIC VLANs as the original server. When using a replicated Snapshot, you must define the VLANs for each NIC.
For complete details, see:
In either case, this function allows you to bring up a new server that matches the state of the server represented by the start time of a successful snapshot. The goal is to allow you to quickly assess the snapshot to ensure it contains the data and server state you are looking for as well as to gain quick access to data and potentially replace the original server in production using this newly created server. Note that this process will take longer if Archive is enabled for the Location and the Snapshot chosen resides are Archive Storage (see Snapshot Archiving section above)
A "Snapshot Preview" server has the same virtual CPU and RAM performance as the original server and runs on a physical ESXi host in the production infrastructure. However, the "local storage" (i.e. disks) for a Snapshot Preview server is not running on the production storage infrastructure. Instead, it is running on disks presented by the snapshot service itself. Snapshot Preview Servers are indicated by the Snapshot Preview Server icon. You can hover your mouse over the icon to see that the Server is in Snapshot Preview mode:
While in Snapshot Preview mode, the server has some performance limitations and some other restrictions:
Given those limitations (particularly the first two issues), the recommended best practice is to verify that the server represents a snapshot state you are looking for, make any necessary changes to it, and then to migrate the Snapshot Preview server to NORMAL as soon as possible. Users must initiate migration of "Snapshot Preview" Servers to at the Production Disk Speeds as described in the next section within two hours after creation. After two hours, the system will initiate the migration automatically.
There are some minor caveats and potential Guest OS configuration issues with Snapshot Preview Server:
The second step in the process migrates the server's local storage onto the production disk infrastructure. This converts the server to a "normal" Cloud Server free of any performance limitations or restrictions. This is a potentially long-running process depending on the size of the local storage, as the process is the equivalent of initiating a "disk speed" change on all of the local disks attached to the Cloud Server. During this migration, the server will continue to run in the state it was in at the time of the migration. However:
Once migration is complete, the server acts as a Normal Cloud Server and there are no restrictions on usage or changes. However, remember that the new server is not enabled with services such as Cloud Server Snapshots, Monitoring, etc. so you may want to enable those services on the new server if required.
Migration from a Snapshot Preview to a "Normal" server can be done in one of two ways:
If the System initiated migration fails, the System will retry the migration. If the migration fails after 3 retries, the System will stop trying to migrate the Server. The Server will remain in Snapshot Preview status but will be returned to a Normal state. At this point the User can either:
Another feature of Cloud Server Snapshots is the ability for a user to specify a file or file directory from a historical snapshot and have that particular file or directory copied or "restored" back onto the Cloud Server associated with the snapshot. This ability is useful when a single file or directory needs to be restored instead of creating an entirely new Server using Snapshot Preview.
The system will restore the specified file or directory from a source location on the Snapshot to a target location on the parent Cloud Server.
There are several preconditions that must be met in order to successfully perform a File or Directory restore. For a full list of preconditions, as well as instructions on how to use this function, see How to Restore a File or Directory from a Cloud Server Snapshot to the Cloud Server
Note that you cannot perform a File or Directory Restore from a Replicated Snapshot.
Enabling Cloud Server Snapshots on a server will cause the server to incur a new (Snapshot Plan) Snapshot Service Hours where (Snapshot Plan) represents either the Snapshot plan was enabled for the Cloud Server. If Snapshot Replication is enabled for a Server, additional usage will appear under (Snapshot Plan) Replicated Snapshot Hours beginning from the time Replication was enabled on the Server. In all cases, the usage charges are based on the aggregate size of all of the local disks attached to the Cloud Server. The charges apply to the total size of the disks, not the amount of local storage actually used by the Operating System becausethe stored snapshot includes the exact state of all local disks (even if unformatted) and any Disks that are replicated to a secondary location.
All Snapshot Service Hours usage is incurred immediately upon service enablement before any snapshots are taken or stored and usage will stop when the service is disabled. Note that disabling Snapshot Replication can take anywhere from 2 to 4 hours andusage will continue to be incurred until Replication is fully disabled. The “(Snapshot Plan) Snapshot Service Hours” and "(Snapshot Plan) Snapshot Hours usage charges are in addition to the normal Economy/Standard/High-Performance usage charges for local disks that are described in Introduction to Cloud Server Local Storage ("Disks") and Disk Speeds.
When a "Snapshot Preview" Cloud Server that is newly created from a Snapshot (Local or Replicated) as described in How to Create a Snapshot Preview Server from a Local Snapshot, the server incurs all local disks as Standard Disk Speed rates ("Storage Hours") while it is in Snapshot Preview mode. Local disks incur normal disk speed usage only after the server is migrated to a "Normal" server as described in How to Migrate a "Snapshot Preview" Server to a Normal Cloud Server.
For more information on Snapshot usage elements, please refer to the Cloud Server Snapshots section of Introduction to Usage Reporting
From a reporting perspective, details of Snapshot Usage (and Replicated Snapshot usage) are contained in the Snapshot Usage report as described in How to Generate a Snapshot Usage Report
While snapshots are in progress, you cannot modify any existing disks on the Cloud Server. Therefore: