That’s why your AWS restored snapshot is not starting

Ever tried to restore a snapshot only to find out that the instance won’t start? This occurrence is not so common, but every time it happens it leaves you wondering what in the world went wrong… and a few steps later someone finds you yelling at the Cloud. Fear not, we are here to clear things out.


Ever tried to restore a snapshot only to find out that the instance won’t start? This occurrence is not so common, but every time it happens it leaves you wondering what in the world went wrong… and a few steps later someone finds you yelling at the Cloud.

That's why your AWS restored snapshot is not starting

Fear not, we are here to clear things out.

In order to understand where the problem is, we first need to make a clear distinction between two different kinds of backups: inconsistent backup and consistent backup.

Let’s go deeper into these two key-concepts.


Inconsistent Backups: VM Snapshots

When talking about Virtual Machines (from now on VMs), a Snapshot is a point-in-time photograph taken at the Hypervisor level and is the composition of the state and the data of VM.

Inconsistent Backups: Crash-consistent Snapshots

So, Cloud Providers run instances on VMs, then snapshots taken should be VM Snapshots, right? Wrong.

Snapshots created by Cloud Providers, like AWS, with API calls or from the web console are taken instead at the block-storage level, so they are basically photographs of the file-system at that moment. This kind of snapshots are much less complex than VMs Snapshots and comes with many features like less space occupied (as the state is not taken into account), the ability to get only the delta of the data that changed, and the ease of management.

The downside is that the state is not saved and, consequently, it’s not possible to recreate the exact state of the machine at the time the snapshot was taken.

The main feature is that all of the data on the VM is saved at the same time, so this should let us sleep peacefully, right? Wrong again.

This kind of Snapshots leverage the current file-systems ability (i.e., Ext4, NTFS) to journal file changes and recover from inconsistent data without leaving them corrupted while Databases use transaction logs to return to the last consistent state even in the Snapshot was taken in the middle of a transaction.

Most of the time everything will work out by itself, but sometimes you find yourself again yelling at the Cloud.

So how do you prevent this kind of errors?

Application-Consistent Backups

The one and the most simple answer is that something needs to be done before a backup to ensure that all data is consistent. The most common way to do this is to stop all I/O operations for the file-system and to prevent writing to the Databases. This comes at a price though; the system needs to run some routines and scripts before the snapshots could be taken therefore the application will be in a read-only state for a brief period. Other than that, now you need a way to start scripts on the VM and maintain them.


In conclusion…

you’re not bound to go through the trouble of setting up consistent snapshots of your infrastructure and, in the end, it’s up to you to decide what kind of backup you need.

At least now you have the tools to understand what could go wrong and stop yelling at Cloud.


If you have concerns on your backup strategy, Noovolari Smart Backup is here to help!

Noovolari Smart Backup

Noovolari is the smartest tool for setting up your Disaster Recovery strategy for your AWS Cloud infrastructure… and it takes off the burden of setting up consistent backups too!
Join our 30-days free trial and discover how smart is keeping your data and your business safe!

See you soon, guys!


Notice: Undefined variable: post in /var/www/noovolari.com/wp/wp-content/themes/noovolari-eddie-website/functions.php on line 24

Notice: Trying to get property of non-object in /var/www/noovolari.com/wp/wp-content/themes/noovolari-eddie-website/functions.php on line 24