Skip to main content

Server Snapshots

Taking a server snapshot allows you to save a copy of your server's disk at a particular point in time in Memstore™, our cloud storage solution.

The snapshot can be used to re-image an existing server or to order a new one using the snapshot as a disk image. This allows server image customisation and reduces the risk of production systems' maintenance.

Currently there are three types of snapshots:

  1. ntfsclone snapshots: creates an ntfsclone compressed image of only the used disk space. It's only available for Windows Miniservers. It may fail due to file system inconsistencies (more likely on busy servers with high I/O levels). (This option is deprecated and is not available for all Servers)
  2. tar snapshots: creates a compact package of only the used disk space. It's only available for Linux Miniservers. Extended file attributes are supported in any snapshot after Jan 13th 2014, POSIX ACLs are not supported.
  3. raw snapshots: creates a raw compressed image of the disk. This is the less efficient method but it's not affected by high I/O levels. It's not recommended for big disks.

The snapshots will be uploaded to a miniserver-snapshots container (created automatically), in a folder named after the Miniserver name and the date and time of the snapshot.

Depending on the type of snapshot we can find different files. The most important are the .part directory that includes the different pieces of the snapshot and the manifest file.

The manifest file can be downloaded and Memstore will merge all the parts automatically.

Taking a Snapshot

To take a snapshot, go to the Manage page of your Miniserver and click on Server Snapshots and Re-imaging in the Management Tools section. This will show you the following page:

On this page, on the left column, you can check the historic record of your snapshots (if any), and relevant information such as the status or which Memstore it was stored in.

If there are no pending snapshots, you can schedule a new one by choosing the destination storage and the image type you want to use in your snapshot.

The snapshot process will be started as soon as possible and the time it takes will depend on the size of your disk and the image type. The new snapshot will be added to the record table and it will be updated automatically when the process changes status.

Once your snapshot is DONE, it will be ready to use and you can access it using any of the Memstore interfaces.

Downloading Recent Snapshots

You can download your snapshots using the web based storage browser, or the FTP/SFTP interfaces (recommended, especially for big files).

In that way you can have a local copy of your data, that can be used for testing production environments on your own desktop (resulting RAW or NTFSclone images may be usable with third party virtualisation software - we do not guarantee this, however).

Each snapshot is contained in a separate folder. The files you need to download depending the image type are:

  • tar: the file ending in .tar.
  • raw: the file ending in .raw.gz.
  • ntfsclone: the files ending in .xmbr and .img.gz.

Additionally we recommend downloading the README.txt file if available (it includes information to verify the integrity of your snapshot using MD5). Please note you don't need to download the files stored in the .part folder. If you have any questions please don't hesitate to contact our support team.

You can delete a snapshot from that table clicking on the red cross next to the date of the snapshot.

Broken Snapshots

The snapshot process is complex and can fail, especially when dealing with busy Miniservers with large disks.

A snapshot is composed of one or more large files that are split into parts to overcome the 5GB object size limit of the object storage. Every part is verified using a hash and only when all the parts are stored and verified is a special file called manifest created so it can be used to retrieve all the parts assembled as one single file. Finally, when all the files are uploaded, a README.txt file is created with some control information that can be used to verify the snapshot.

In some exceptional cases when a snapshot fails some files may be left behind for our support team to analyse. These snapshots will be listed as broken in the table of recent snapshots and can be deleted safely. A broken snapshot will never be used to re-image a server.

We can't reliably detect broken snapshots while there's a snapshot in progress, so take that into account and please wait until any ongoing snapshot is finished before looking for old snapshots to delete.

SSH Host Keys

An SSH host key is the cryptographic key that uniquely identifies every server running SSH. This key is associated with the server's IP address by your local SSH client and is checked every time you log into the server. If the key or IP change you are warned by SSH. This check is performed in order to protect you against a man-in-the-middle-attack.

This is an important consideration when using snapshots because a server snapshot is an exact copy of the original including its SSH host key. This is only a concern when several servers are all imaged from the same snapshot and running at the same time. When this happens they will all share the same SSH host key which should be avoided as the SSH host keys ought to be unique.

If you are running several live servers from the same image you should re-generate their SSH keys in order to avoid any problems.

This is done with the following commands:

Debian and Ubuntu

rm  /etc/ssh/ssh_host*key*
ssh-keygen -A

CentOS

rm /etc/ssh/ssh_host*key*
/etc/init.d/sshd restart

When you log out and log back into the server you will be warned by SSH that the host key has changed and may have to delete a line from your known_hosts file.

Please note that all servers installed from Memset stock images have unique SSH host keys.

Miniserver Export

It is possible to take a special type of snapshot to export a Miniserver to be used in third party virtualization software.

The image format for the export snapshot can be:

  • VMDK: This format can be used with different virtualisation products, including VMware, VirtualBox or KVM.
  • VHD: This format is recommended for Microsoft virtualisation solutions, such as Virtual PC.

To see which operating systems are supported by our Miniserver export tool, please refer to our operating systems page.

Please note that export snapshots can't be used to re-image a Miniserver.

Compatibility Notes

The exported virtual machines are autonomous and independent of Memset infrastructure. The configuration of the virtualisation software depends on the operating system version and its configuration.

  • Microsoft Windows:
    • The virtualisation software must use a disk bus/controller supported by the VM (IDE, SATA, SAS, SCSI, etc). We recommend trying IDE first as it is usually available in all Windows versions.
    • In some virtualisation software IO APIC may or may not be required (the VM may BSOD-crash or just hang loading crcdisk.sys). For example Windows 2008 won't work on KVM with IO APIC on, but it is required on VirtualBox.
  • Linux:
    • CentOS 5 requires an IDE disk bus/controller.

Don't hesitate to contact support if you have problems running your exported Miniserver.

Last updated 27 August 2019, 16:50 GMT