Rackspace Cloud Essentials - Cloud Server Snapshot Limitations
You have just learned how to restore servers from an image. These images are ideal for use as templates or "gold images", so that you can easily restore to a known configuration or rapidly deploy additional Cloud Servers. This system was designed primarily to speed deployment of new servers and not as a robust backup solution. As such, there are a number of practical limitations in place:
- Cloud Server images are good for storing configuration and static data but are not a reliable way to back up a dynamic database! We recommend using standard backup tools such as mysqldump or the SQL Server Management Studio for this task. Backing up your database is recommended before creating an image of your Cloud Server. If you do want to create an image of a server that contains a database, you must take the database down, initiate the image creation, and restart the database when the server reaches the appropriate task state. For details on the task monitoring process, see Using Task States With Server Imaging.
- While you can import images into the Rackspace open cloud using Cloud Images, you'll only be able to boot a server from such an image if it's been properly prepared for use in the Rackspace open cloud. See the Knowledge Center article Preparing an image for import into the Rackspace open cloud, for details.
Note: Image import is not available for the first-generation cloud.
- While you can download first-generation cloud images and images exported from the Rackspace open cloud, whether such images will work in another cloud or in your local virtualization solution depends upon the target cloud or local solution. Consult your vendor for details.
Note: Not all images may be exported from the Rackspace open cloud. For more information, see the Cloud Images FAQ.
- Snapshots go through several stages, from preparing the server data for the imaging and the actual copy of the image to Cloud Files. The snapshot process can take several hours, and can fail if you're very close to the maximum disk size for images or if you have an extremely large number of files.
You can monitor the tasks involved in this process. For information on the task monitoring process, see Using Task States With Server Imaging.
- Snapshot processes can have their start delayed if there are a large number of snapshot requests at one time for a group of servers. The number of concurrent snapshots are limited in order to keep the disk activity of multiple snapshots from affecting performance on a host. If the snapshot takes longer than 24 hours to complete contact Rackspace Cloud support.
- If your snapshot fails more than once and you're sure you shouldn't be past the image limits, contact Rackspace Cloud support. Our admins may be able to succeed where our automated processes do not.
- Performance Cloud Servers images only include the system disk, not any attached data disks.
- On a first-generation Linux Cloud Server current volume size cannot be more than 250GB and current inode usage should not be more than 3 million. Exceeding those limits will cause a snapshot request to fail (though in most cases we can help you work around the inode limit). You can check how much disk space you are currently using by running the command "df -h", and your inode usage can be viewed with "df -i". There are no limits on snapshot disk size or inode usage for next generation Linux servers at this time.
- If you reduce your disk usage below the limits a snapshot still may not succeed. The total size of your instance's virtual disk includes space allocated behind the scenes to track changes between snapshots as well as space that used to be allocated to deleted files. As a result, having several snapshots or having grown the disk in the past can cause the virtual disk size to exceed the limit even if the current filesystem inside of an instance is below the limit.
- When a snapshot is attempted the system runs a process that tries to reclaim space that has been freed by deleting files and images. That process continues even if the snapshot is aborted because of disk limits at the time the snapshot begins. That means that in some cases, trying a snapshot again about a half hour after it fails could result in a successful snapshot thanks to that cleanup operation.
- On a first-generation Windows Cloud Server, current or previous disk usage cannot exceed 250GB. Due to limitations with the Windows filesystem, the underlying virtual hard disk cannot shrink once it has expanded. Therefore, if you have resized your server larger than 250GB, our Imaging system will not be able to take an image of the server. We recommend taking an On-Demand image of your configuration before you reach 250GB of data on a first-generation Windows machine for this reason. There are no limits on snapshot disk size for next generation Windows servers at this time.
- If you take a snapshot of a Windows Cloud Server that is configured to be a Domain Controller (DC), you will be unable to restore from that image. Our build system relies on the local Administrator account to perform configuration tasks, and that account becomes disabled once a server is promoted to be a DC. If you wish to create a snapshot of a server that is also a Domain Controller, you must first demote it from being a DC before performing the snapshot.
As we continue developing our services some of these potential issues will go away. Right now, however, this represents the practical experience of our Fanatical Support staff, and we feel it is important to share it with you and set correct expectations. Now that you know how to create and connect to a server, configure security, and save your work - the next step is to upload your content to the server for use with your web applications.
© 2014 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
See license specifics and DISCLAIMER