• Sales: 1-800-961-2888
  • Support: 1-800-961-4454

Rackspace Cloud Essentials 4 - Cloud Server Snapshot Limitations


You have just learned how to enable Scheduled Imaging, create On-Demand snapshots, and 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:

All

  • 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.
  • Cloud Server snapshots cannot be transferred between accounts, and you cannot build a server using an image from another account - even if you own both accounts. The sole exception to this rule is if you are migrating from a US to a UK Cloud Server account.
  • ISOs and images from non-Rackspace servers cannot be uploaded to Cloud Files and used to build a new Cloud Server. You can, however, download your first-generation Cloud Server snapshots and run them on your own local virtualization solution.  Portability support for next-generation Cloud Server images is in the works.
  • 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.
  • 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.

Linux

  • 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 (open cloud) 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.

Windows

  • 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 (open cloud) 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.

On to Guide 5 - Uploading Your Content

Back to First 48 Guide



© 2011-2013 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

14 Comments

<blockquote>Cloud Server images are not a reliable way to back up a database! We recommend using standard backup tools such as mysqldump or the SQL Server Management Studio for this task</blockquote>

How should I read this? On some backups my database is screwed? Care to elaborate a bit since I'm still deciding which VPS provider I choose, this snapshot thing is important. I plan to use it before major updates etc. so I can restore the working image if something went wrong.

Can't I simply stop the <code>mysqld</code>: thus freezing table files and then take the snapshot?

Sorry about the vagueness in that part of the article, Ciantic. Yes, the reason the article gives a warning about snapshots and databases is that if a snapshot is taken while the database is active then it may not be in a fit state to run after a restore. A mysqldump before taking a snapshot can ensure that you can restore from the dump later. Alternatives do indeed include stopping mysqld, but another approach is to make your tables read-only, then taking the snapshot, then restoring them. Locking the tables can be done by getting into the mysql client and running [mysql -u root -p -e "FLUSH TABLES WITH READ LOCK;"], then when you're done you can make them writeable again with [mysql -u root -p -e "UNLOCK TABLES;"]. You can read a bit more about backing up the database in our MySQL articles. It depends a little on the distribution you're using, but to get you started the article for Ubuntu that discusses backups is: http://www.rackspace.com/knowledge_center/installing_mysql_server_on_linux/configuring_mysql_server_on_ubuntu

Would shutting down Windows Server 2008 before taking the snapshot take care of database problem with MySQL and/or SQL Server 2008?

It would help since you would have shut down the database cleanly (I suspect just stopping the service would do that too). It's still a good idea to make regular backups independently of the server snapshots though. That way if there is a problem with the database you'll have a backup you can restore without needing to rebuild the entire server.

If I recreate a server from a saved image, the process will erase many of my config files, i.e. Apache, but it won't overwrite sshd_config. Since I've got a new IP address the ListenAddress directive renders sshd inoperable and Apache needing to be reconfigured. It would help if you could provide a list of files the restore process overwrites so I can better prepare my server backups.

Good question Jason. I'll try to get a list of what files are not replicated from the image, since that would probably be a shorter list.

The fact that on a windows box once you exceed 160G you cant create new images is bad enough, esspecially when your bussiness model is for me to "dial it up" when I need more -but the fact that deleted data counts towards the 160G is beyond words!

You can pretend to be fanatical all you want - but you arent serving your customers.

I agree. Imaging is weak and fanatically disappointing.

It looks like some updates were lost in this article that we need to get back in place. One change was to note that on our open cloud platform (the "next generation" Cloud Servers), there are no limits on image sizes.

<cite>Cloud Server snapshots cannot be transferred between accounts, and you cannot build a server using an image from another account - even if you own both accounts. The sole exception to this rule is if you are migrating from a US to a UK Cloud Server account.</cite>

Will, in the future, be posible to transfer a snapshot between accounts. This would be very convenient as it will allow to store an image locally and then upload it again when needed.

"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"

Interesting...Then why do you offer nightly and weekly scheduled images? I would think that if this were the intent you would only offer an on-demand and restore. But wait...that might not work also if your 'gold' image changes too much as you build it.

Scheduled snapshots are there for users who want to use them. If you have a server that primary deals in static files, or if you schedule application operation around your snapshot schedule, then it's a quick-and-dirty backup approach.

That said, we have a Cloud Backup service that's more robust that's been rolled out to our Managed Cloud Servers. The plan is to eventually make that available to our other products as well so we can offer a more robust backup solution.

Our cloud server images are roughly 60GB in size. When it copies over to cloud files, it appears to turn this image into n number of 5GB files that we have to download to use internally. I assume we then glue the fragments back together - but to save me the time of doinf that - what format will the image file be once we glue all the pieces back together? VMWare? Oracle VM? .iso? Thanks in advance.

This is in reference to the text on this page - "•ISOs and images from non-Rackspace servers cannot be uploaded to Cloud Files and used to build a new Cloud Server. You can, however, download your Cloud Server snapshots and run them on your own local virtualization solution."

Thanks -

The combined file should be a gzipped tarball that contains a single VHD image.

Add new comment