0
votes

But based on my experiment I would found the following, there are two instances Instance-1 and instance-2

First scenario - Failed I’ve created snapshot for data volume of Instance-1 and using that snapshot I’ve created a new volume and attached/mounted the new volume to Instance-2. After mounting the new volume into instance-2 I can’t see the data in it.

Second scenario - Success I’ve unmounted the data volume from Instance-1 and then I’ve created snapshot for data volume of Instance-1 and using that snapshot I’ve created a new volume and attached/mounted the new volume to Instance-2. After mounting the new volume into instance-2 I can see the data in it.

Is this the behavior snapshot or am I missing something

2

2 Answers

0
votes

AWS recommends unmounting the filesystem for an EBS volume prior to taking a snapshot exactly for this reason. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html

In most (all?) modern OSes, even if my application writes to a file and is told the operation was a success, the kernel may not have actually written to the backing store, keeping the changes cached in memory. This is particularly dangerous when taking a snapshot on virtual storage, because the OS may be in the process of writing to the filesystem when the snapshot is made, corrupting files, directories/folders, or worse.

0
votes

You can quiescent an application right before you take the snapshot and release it right after the snapshots begin. For instance, if it’s an XFS file system, you can freeze the filesystem right before you create the snapshot, and right after you unfreeze it. Freeze will not be able to account for application data that was not written into a file, but it will flush the filesystem caches to disk. A better solution yet would be to do it on an application level, for instance: do a flush&Write lock on an MySQL databsse right before the snapshot/s are taken and release the lock right after.