The feature: Restore Progress Tracker
Over the last few weeks the CodeGuard team has been working hard on a new feature we are excited to release soon: The Restore Progress Tracker. Coming soon to the dashboard, whenever you request a restore you will be able to see live, real-time progress on the status of the restore, along with an estimated time for completion, and what step in the process it is currently in.
We’ve had a very similar feature in our dashboard for a long time now: The Backup Progress Tracker. When a customer adds a website or database to CodeGuard for the first time we show you real-time updates on the status of your first backup. It’s been a long time coming, but we’ve finally been able to extend this functionality to our restore process as well. Right now our real-time updates for restores will only be available for our Automatic “One-Click” Restores, our Individual File Restores, and our Database Restores. This excludes our Download Zip feature for the time being.
If you’re curious to learn about the development challenges our team went through to make the magic happen, keep on reading!
This project wasn’t so much a design challenge, because we had already developed our Backup Progress Tracker feature (most of the UI was recycled), but more so a development challenge because the processes are completely different. The main problem to solve was, “How do we show real-time restore progress in our dashboard? How do we get this information about our restores?” For me, the project got divided into three main parts:
- How do I solve this problem for Automatic “One-Click” Restores?
- How do I solve this problem for Individual File Restores?
- How do I solve this problem for Database Restores?
When it came to the steps these restore types went through there were a few similarities, but there were also a lot of differences. At the start of the project these differences were a “black box” for me though, and so I set out to meet with two of our back-end gurus, Jonathan and Michael, to get a feel for how these processes work. After an hour of lively white-boarding we were able to document exactly what is going on behind the scenes with each restore. The main steps of the restore process are as follows:
- A CodeGuard server is started to begin the restore
- A connection to your server is opened to perform the restore
- A pre-restore backup is taken just before the restore begins (Not for Individual File Restores)
- A comparison is made between your current website and the backup you have chosen to restore to (Automatic “One-Click” Restores only)
- We modify the running website: add files, remove files, override existing files (Not for Database Restores)
- We push the selected backup to your database (Database Restores only)
- We finalize the details with logging and get ready to email you
- The restore is complete!
You can see with the comments I made in parenthesis that it was a somewhat tricky task to organize all those steps! This brings me to the next major challenge I encountered, which was how to develop these views to show the proper steps based on restore type without unnecessarily duplicating tons of code. I didn’t want to have to create a separate view in the application for Database Restores, a separate view for Automatic Restores, and a separate view for Individual File Restores. To me that seemed a little wasteful, and I knew there had to be a smarter way to write the code.
While I worked on a sane way to do this, another challenge arose, which was how do we decide when to show this view (partial) in the dashboard? When a restore is ongoing in the dashboard, it has a Status and a Type. The restore Type correlates to what type of restore it is (naturally), so Automatic Restore, Individual File Restore, or Database Restore. The Status of the restore determines what point in the process it is at (Not Requested, Requested, Backing Up, Comparing, Transferring, Finalizing, Delivered). We obviously didn’t want to show this view in the dashboard if no restore is in progress, but if a restore just completed (and is “Not Requested”), we wanted to be able to keep this view in the dashboard for a period of time to give the customer a chance to view it and see what happened.
To overcome the challenges of what to show and when to show it, I relied heavily on the Type and Status attributes of the restore to drive this view. By utilizing these attributes I was able to code the Restore Progress Tracker in one main view! Granted, it is a very large view, but with one main location for this logic I was probably able to avoid duplicating hundreds of lines of code. Don’t get me wrong, the “genius” of this work was definitely not accomplished by myself alone! I continued to interact heavily with Michael and Jonathan on the team to figure out the best and most efficient way to tackle this project throughout it. In the end, I think we were able to solve these challenges as they came in a great way.
While I worked on the views, Michael was able to figure out a way to intelligently calculate the estimated time of completion for the restore. This involved analyzing how long previous backups and restores took to complete for that website/database and then by using that data to drive our estimates. Jonathan was also able to help me in a big way when it came to the “real-time” component of the feature, and figuring out a way to refresh this content every few seconds for real-time progress. Overall, I had a lot of fun watching us come together during this project to conquer our coding challenges!
With our development challenges out of the way, our next challenge is to deliver to you, our customer, the restore experience you want and deserve. Our main goal with this feature is to make restores a little less scary, a little less of an “unknown”, and as a result a lot less stressful for you and your business.
I don’t want to tease too much, but I would like to note that the Restore Progress Tracker is just one part of a much larger set of enhancements we have coming soon to our restore experience! Hopefully this current enhancement will hold you off until our next major improvement is released (stay tuned!).
To conclude, we certainly don’t want anything bad to happen to your websites or databases, but if disaster does strike and you need to restore your content, rest assured that CodeGuard will let you know what is happening every step of the way. You can expect to see the Restore Progress Tracker in the dashboard within the next week, and if you do encounter it, please let us know what you think!