The ability to schedule the time that a particular backup runs is something that we’ve been happy to help customers with through our support team, but until today we had not exposed this functionality in our dashboard. Why the long beta period?
The short answer is: scale. This is a class of problems that is easy to solve when there are not many operations competing for resources, but becomes much more difficult as the number of operations increase. Imagine a simple case where a single backup has to run one time per day and there is a dedicated server for this task. In this contrived scenario, the backup could be scheduled to run at any time, and since the server it’s running on is idle all day, you can almost guarantee that the backup operation will start at the scheduled time and complete successfully. In a more real-world scenario, imagine a server that has a backup scheduled to run at a particular time, but this server is also hosting an active website and a database. The backup could be scheduled to run at any time, but the certainty that the operation will start as scheduled and complete successfully diminishes.
In our case, we’re running anywhere between 10 and 150 servers to service the more than 200,000 backups we perform on a daily basis. So, how do you solve the challenge of scheduling while maintaining CodeGuard-levels of reliability? We make sure that we have the spare capacity available to run the backups at the times they are scheduled using an infrastructure management service that we’ve developed internally. This service, which we affectionately call Steward, watches after all of our servers, the backup operations running on them and the queue of pending backup and restore operations. When the need arises to add capacity to handle the upcoming load, Steward will start more servers to accommodate. Similarly, as backups finish and the servers become idle, Steward shuts them down. This arrangement allows us to have just-in-time resources available for all of our scheduled, on-demand and unscheduled backup and restore operations. Steward has also helped with server configuration management, versioning, deployment, fault-tolerance and cost reduction, but those are topics for another post!
In addition to the back-end, infrastructure changes, we have also updated our dashboard to reflect the new scheduling ability. Not only do we have an option for it on the website backup settings page, but we’ve updated all of the times and reporting functionality to accurately reflect the backup times in the customer’s local time zone. If you’ve ever tried to schedule a meeting with a colleague or customer in a different time zone, you know that this is not as easy as it sounds! We wanted our interface to be very clear about the scheduling time to ensure that there is no confusion for customers, regardless of what part of the planet they happen to be on relative to our servers.
A quick note about database backups – currently, database backups for a particular website will run at the same time as the website backup. For backup consistency, especially for database-backed applications like WordPress, Joomla! and Drupal it’s important that the backups of the database and file content are taken in close proximity to each other. We have worked very hard to ensure that our website file backup and database backup processes impose minimal load on your server and, therefore, running applications. If you are concerned about load or are using legacy MySQL storage engines, you can always schedule your website and database backups to occur at an off-peak time.
Ready to give backup scheduling a try? Check out the article in our support center for detailed instructions.