- EBS provides the ability to create snapshots (backups) of any EBS volume and write a copy of the data in the volume to S3, where it is stored redundantly in multiple Availability Zones
- Snapshots are incremental backups and store only the data that was changed from the time the last snapshot was taken.
- Snapshots can be used to create new volumes, increase the size of the volumes or replicate data across Availability Zones.
- Snapshot size can probably be smaller than the volume size as the data is compressed before being saved to S3.
- Even though snapshots are saved incrementally, the snapshot deletion process is designed so that you need to retain only the most recent snapshot in order to restore the volume.
- EBS Snapshots can be used to migrate or create EBS volumes in different AZs or regions.
- Snapshots can be used to create a backup of critical workloads, such as a large database or a file system that spans across multiple EBS volumes.
- Multi-volume snapshots help take exact point-in-time, data-coordinated, and crash-consistent snapshots across multiple EBS volumes attached to an EC2 instance.
- It is no longer required to stop the instance or to coordinate between volumes to ensure crash consistency because snapshots are automatically taken across multiple EBS volumes.
EBS Snapshot creation
- Snapshots can be created from EBS volumes periodically and are point-in-time snapshots.
- Snapshots are incremental and only store the blocks on the device that changed since the last snapshot was taken
- Snapshots occur asynchronously; the point-in-time snapshot is created immediately while it takes time to upload the modified blocks to S3. While it is completing, an in-progress snapshot is not affected by ongoing reads and writes to the volume.
- Snapshots can be taken from in-use volumes. However, snapshots will only capture the data that was written to the EBS volumes at the time the snapshot command is issued excluding the data which is cached by any applications of OS.
- Recommended ways to create a Snapshot from an EBS volume are
- Pause all file writes to the volume
- Unmount the Volume -> Take Snapshot -> Remount the Volume
- Stop the instance – Take Snapshot (for root EBS volumes)
- EBS volume created based on a snapshot
- begins as an exact replica of the original volume that was used to create the snapshot.
- replicated volume loads data in the background so that it can be used immediately.
- If data that hasn’t been loaded yet is accessed, the volume immediately downloads the requested data from S3 and then continues loading the rest of the volume’s data in the background.
EBS Snapshot Deletion
- When a snapshot is deleted only the data exclusive to that snapshot is removed.
- Deleting previous snapshots of a volume does not affect the ability to restore volumes from later snapshots of that volume.
- Active snapshots contain all of the information needed to restore your data (from the time the snapshot was taken) to a new EBS volume.
- Even though snapshots are saved incrementally, the snapshot deletion process is designed so that you need to retain only the most recent snapshot in order to restore the volume.
- Snapshot of the root device of an EBS volume used by a registered AMI can’t be deleted. AMI needs to be deregistered to be able to delete the snapshot.
EBS Snapshot Copy
- Snapshots are constrained to the region in which they are created and can be used to launch EBS volumes within the same region only
- Snapshots can be copied across regions to make it easier to leverage multiple regions for geographical expansion, data center migration, and disaster recovery
- Snapshots are copied with S3 server-side encryption (256-bit Advanced Encryption Standard) to encrypt the data and the snapshot copy receives a snapshot ID that’s different from the original snapshot’s ID.
- User-defined tags are not copied from the source to the new snapshot.
- First Snapshot copy to another region is always a full copy, while the rest are always incremental.
- When a snapshot is copied,
- it can be encrypted if currently unencrypted or
- can be encrypted using a different encryption key. Changing the encryption status of a snapshot or using a non-default EBS CMK during a copy operation always results in a full copy (not incremental)
EBS Snapshot Sharing
- Snapshots can be shared by making them public or with specific AWS accounts by modifying the access permissions of the snapshots
- Encrypted snapshots cannot be made available publicly.
Only unencrypted snapshots can be shared. Encrypted snapshots cannot be shared between accounts or made public
- Encrypted snapshot can be shared with specific AWS accounts by sharing the custom CMK key used must also be shared to encrypt it
- Cross-account permissions may be applied to a custom key either when it is created or at a later time.
- Users, with access to snapshots, can copy the snapshot and create their own EBS volumes based on the snapshot while the original snapshot remains unaffected
- AWS prevents you from sharing snapshots that were encrypted with the default CMK
EBS Snapshot Encryption
- EBS snapshots fully support EBS encryption.
- Snapshots of encrypted volumes are automatically encrypted
- Volumes created from encrypted snapshots are automatically encrypted
- All data in flight between the instance and the volume is encrypted
- Volumes created from an unencrypted snapshot owned or have access to can be encrypted on the fly.
- Unencrypted snapshots can be encrypted during the copy process.
- Encrypted snapshots that you own or have access to, can be encrypted with a different key during the copy process.
- First snapshot of an encrypted volume that has been created from an unencrypted snapshot is always a full snapshot.
- First snapshot of a re-encrypted volume, which has a different CMK compared to the source snapshot, is always a full snapshot.
EBS Snapshot Lifecycle Automation
- Amazon Data Lifecycle Manager can be used to automate the creation, retention, and deletion of snapshots taken to back up the EBS volumes.
- Automating snapshot management helps you to:
- Protect valuable data by enforcing a regular backup schedule.
- Retain backups as required by auditors or internal compliance.
- Reduce storage costs by deleting outdated backups.
AWS Certification Exam Practice Questions
- Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
- AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
- AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
- Open to further feedback, discussion and correction.
- An existing application stores sensitive information on a non-boot Amazon EBS data volume attached to an Amazon Elastic Compute Cloud instance. Which of the following approaches would protect the sensitive data on an Amazon EBS volume?
- Upload your customer keys to AWS CloudHSM. Associate the Amazon EBS volume with AWS CloudHSM. Remount the Amazon EBS volume.
- Create and mount a new, encrypted Amazon EBS volume. Move the data to the new volume. Delete the old Amazon EBS volume.
- Unmount the EBS volume. Toggle the encryption attribute to True. Re-mount the Amazon EBS volume.
- Snapshot the current Amazon EBS volume. Restore the snapshot to a new, encrypted Amazon EBS volume. Mount the Amazon EBS volume (Need to create a snapshot, create an encrypted copy of snapshot and then create an EBS volume and mount it)
- Is it possible to access your EBS snapshots?
- Yes, through the Amazon S3 APIs.
- Yes, through the Amazon EC2 APIs
- No, EBS snapshots cannot be accessed; they can only be used to create a new EBS volume.
- EBS doesn’t provide snapshots.
- Which of the following approaches provides the lowest cost for Amazon Elastic Block Store snapshots while giving you the ability to fully restore data?
- Maintain two snapshots: the original snapshot and the latest incremental snapshot
- Maintain a volume snapshot; subsequent snapshots will overwrite one another
- Maintain a single snapshot the latest snapshot is both Incremental and complete
- Maintain the most current snapshot, archive the original and incremental to Amazon Glacier.
- Which procedure for backing up a relational database on EC2 that is using a set of RAIDed EBS volumes for storage minimizes the time during which the database cannot be written to and results in a consistent backup?
- Detach EBS volumes, 2. Start EBS snapshot of volumes, 3. Re-attach EBS volumes
- Stop the EC2 Instance. 2. Snapshot the EBS volumes
- Suspend disk I/O, 2. Create an image of the EC2 Instance, 3. Resume disk I/O
- Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Resume disk I/O
- Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Wait for snapshots to complete, 4. Resume disk I/O
- How can an EBS volume that is currently attached to an EC2 instance be migrated from one Availability Zone to another?
- Detach the volume and attach it to another EC2 instance in the other AZ.
- Simply create a new volume in the other AZ and specify the original volume as the source.
- Create a snapshot of the volume, and create a new volume from the snapshot in the other AZ
- Detach the volume, then use the ec2-migrate-volume command to move it to another AZ.
- How are the EBS snapshots saved on Amazon S3?
- EBS snapshots are not stored in the Amazon S3
- EBS Snapshots occur _____
- What will be the status of the snapshot until the snapshot is complete?
- Before I delete an EBS volume, what can I do if I want to recreate the volume later?
- Create a copy of the EBS volume (not a snapshot)
- Create and Store a snapshot of the volume
- Download the content to an EC2 instance
- Back up the data in to a physical disk
- Which of the following are true regarding encrypted Amazon Elastic Block Store (EBS) volumes? Choose 2 answers
- Supported on all Amazon EBS volume types
- Snapshots are automatically encrypted
- Available to all instance types
- Existing volumes can be encrypted
- Shared volumes can be encrypted
- Amazon EBS snapshots have which of the following two characteristics? (Choose 2.) Choose 2 answers
- EBS snapshots only save incremental changes from snapshot to snapshot
- EBS snapshots can be created in real-time without stopping an EC2 instance (the snapshot can be taken real time however it will not be consistent and the recommended way is to stop or freeze the IO)
- EBS snapshots can only be restored to an EBS volume of the same size or smaller (EBS volume restored from snapshots need to be of the same size of larger size)
- EBS snapshots can only be restored and mounted to an instance in the same Availability Zone as the original EBS volume (Snapshots are specific to Region and can be used to create a volume in any AZ and does not depend on the original EBS volume AZ)
- A user is planning to schedule a backup for an EBS volume. The user wants security of the snapshot data. How can the user achieve data encryption with a snapshot?
- Use encrypted EBS volumes so that the snapshot will be encrypted by AWS (Refer link)
- While creating a snapshot select the snapshot with encryption
- By default the snapshot is encrypted by AWS
- Enable server side encryption for the snapshot using S3
- A sys admin is trying to understand EBS snapshots. Which of the below mentioned statements will not be useful to the admin to understand the concepts about a snapshot?
- Snapshot is synchronous
- It is recommended to stop the instance before taking a snapshot for consistent data
- Snapshot is incremental
- Snapshot captures the data that has been written to the hard disk when the snapshot command was executed
- When creation of an EBS snapshot is initiated but not completed, the EBS volume
- Cannot be detached or attached to an EC2 instance until me snapshot completes
- Can be used in read-only mode while me snapshot is in progress
- Can be used while the snapshot is in progress
- Cannot be used until the snapshot completes
- You have a server with a 5O0GB Amazon EBS data volume. The volume is 80% full. You need to back up the volume at regular intervals and be able to re-create the volume in a new Availability Zone in the shortest time possible. All applications using the volume can be paused for a period of a few minutes with no discernible user impact. Which of the following backup methods will best fulfill your requirements?
- Take periodic snapshots of the EBS volume
- Use a third-party Incremental backup application to back up to Amazon Glacier
- Periodically back up all data to a single compressed archive and archive to Amazon S3 using a parallelized multi-part upload
- Create another EBS volume in the second Availability Zone attach it to the Amazon EC2 instance, and use a disk manager to mirror me two disks
- A user is creating a snapshot of an EBS volume. Which of the below statements is incorrect in relation to the creation of an EBS snapshot?
- Its incremental
- It can be used to launch a new instance
- It is stored in the same AZ as the volume (stored in the same region)
- It is a point in time backup of the EBS volume
- A user has created a snapshot of an EBS volume. Which of the below mentioned usage cases is not possible with respect to a snapshot?
- Mirroring the volume from one AZ to another AZ
- Launch an instance
- Decrease the volume size
- Increase the size of the volume
- What is true of the way that encryption works with EBS?
- Snapshotting an encrypted volume makes an encrypted snapshot; restoring an encrypted snapshot creates an encrypted volume when specified / requested.
- Snapshotting an encrypted volume makes an encrypted snapshot when specified / requested; restoring an encrypted snapshot creates an encrypted volume when specified / requested.
- Snapshotting an encrypted volume makes an encrypted snapshot; restoring an encrypted snapshot always creates an encrypted volume.
- Snapshotting an encrypted volume makes an encrypted snapshot when specified / requested; restoring an encrypted snapshot always creates an encrypted volume.
- Why are more frequent snapshots of EBS Volumes faster?
- Blocks in EBS Volumes are allocated lazily, since while logically separated from other EBS Volumes, Volumes often share the same physical hardware. Snapshotting the first time forces full block range allocation, so the second snapshot doesn’t need to perform the allocation phase and is faster.
- The snapshots are incremental so that only the blocks on the device that have changed after your last snapshot are saved in the new snapshot.
- AWS provisions more disk throughput for burst capacity during snapshots if the drive has been pre-warmed by snapshotting and reading all blocks.
- The drive is pre-warmed, so block access is more rapid for volumes when every block on the device has already been read at least one time.
- Which is not a restriction on AWS EBS Snapshots?
- Snapshots which are shared cannot be used as a basis for other snapshots (Snapshots shared with other users are usable in full by the recipient, including but limited to the ability to base modified volumes and snapshots)
- You cannot share a snapshot containing an AWS Access Key ID or AWS Secret Access Key
- You cannot share encrypted snapshots (NOTE: this has be updated partially where you can share a encrypted snapshot with other accounts)
- Snapshot restorations are restricted to the region in which the snapshots are created
- There is a very serious outage at AWS. EC2 is not affected, but your EC2 instance deployment scripts stopped working in the region with the outage. What might be the issue?
- The AWS Console is down, so your CLI commands do not work.
- S3 is unavailable, so you can’t create EBS volumes from a snapshot you use to deploy new volumes. (EBS volume snapshots are stored in S3. If S3 is unavailable, snapshots are unavailable)
- AWS turns off the <code>DeployCode</code> API call when there are major outages, to protect from system floods.
- None of the other answers make sense. If EC2 is not affected, it must be some other issue.
38 thoughts on “AWS EBS Snapshot”
4) Which procedure for backing up a relational database on EC2 that is using a set of RAIDed EBS volumes for storage minimizes the time during which the database cannot be written to and results in a consistent backup?
– Detach EBS volumes, 2. Start EBS snapshot of volumes, 3. Re-attach EBS volumes
– Stop the EC2 Instance. 2. Snapshot the EBS volumes
– Suspend disk I/O, 2. Create an image of the EC2 Instance, 3. Resume disk I/O
– Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Resume disk I/O
– Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Wait for snapshots to complete, 4. Resume disk I/O
I think your answer to ‘Stop the EC2 instance and snapshot the EBS volumes’ is not correct due to the requirement of “minimizes the time during which the database cannot be written to”. My opinion is – Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Resume disk I/O
The only point missing is flushing of the cache which is not mentioned in the Suspend disk I/O, which would create a inconsistent snapshot. Also with a RAIDed configuration you need to suspend I/O on all.
Stopping an EC2 instance makes sure all the caches are flush before the instance is shutdown and also there would not be any more writes happening. Once the snapshot is taken it can be brought up, which is probably missing in the step though.
To create an "application-consistent" snapshot of your RAID array, stop applications from writing to the RAID array, and flush all caches to disk. Then ensure that the associated EC2 instance is no longer writing to the RAID array by taking steps such as freezing the file system, unmounting the RAID array, or shutting down the associated EC2 instance. After completing the steps to halt all I/O, take a snapshot of each EBS volume.
If you restore the EBS volumes from snapshots, be sure to stop all I/O activity, and then reverse the process you used to create the snapshots. For example, start the EC2 instance if it was shut down, mount the RAID array if it was unmounted, and start the application that was stopped.
if we avoid the part in the question “minimizes the time during which the database cannot be written to ” , then definitely I choose option 2 to stop the EC2 instance which will assure results in a consistent backup.
On the other hand, Rusty’s analysis provided here
I am not disagree with you, however, if we can be sure to stop all I/O activity, then can avoid the Stop and start of the instance which will take more time.
Thanks for your reply.
ps. This question was in my exam 😉
Cool :). The only issue I have in this question is its a raided configuration which would have multiple disks and even if you freeze the I/O you need to flush the cache before you take the snapshots. But yup, if the flush is taken in account, suspending I/O would surely be a better option.
For question 4, How about answer A. per below notes, it looks like it will also ensure consistent and complete snapshot apart from being fast.
If you can pause any file writes to the volume long enough to take a snapshot, your snapshot should be complete. However, if you can’t pause all file writes to the volume, you should unmount the volume from within the instance, issue the snapshot command, and then remount the volume to ensure a consistent and complete snapshot. You can remount and use your volume while the snapshot status is pending.
A is wrong as as you need to freeze the I/O to have a consistent snapshot, which is missing.
I have updated the answer as it was long pending to E. As B does not have the complete steps.
I think D is quicker option than E. as we can resume I/O while the snapshot is in progress.
So E is the final answer as I still convinced with B
its actually incomplete, not the fastest as well. Although it is the safest option.
I still don’t understand how come snapshot is incremental and still only the last snapshot can be used alone as a full and incremental ? can you help with this
AWS EBS snapshots are incremental and they stored only blocks that are changed. AWS maintains the block that have changed internally to be able to recreate the Volume again even if the snapshot is deleted. This is one of the reason you do not see the snapshot size, i think. You can refer the link for more details which might make it more clear
Put another way… When you delete a snapshot, AWS doesn’t actually delete that snapshot. It only deletes the blocks related to that snapshot that have the same block or a newer version of that block stored safely elsewhere.
Hi. Just wanted to check if for question 1, (a) is a better answer than (d). As per http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html , the only way to change the encryption status of a volume is to create a snapshot and then copy the snapshot, and while copying, apply the encryption parameters. (d) unfortunately doesn’t state how the encryption of the disk is obtained, it just says to restore to a new encrypted volume, which doesn’t seem possible as per the document pasted above.
Is (a) a better answer since, we can create an encrypted volume and then just copy the contents across, which is possible as per the above document
Creating snapshot, copying it applying encryption and creating volume is the correct way. Refer link
Also CloudHSM does not seamlessly integrate with EBS Volumes.
Sorry, my mistake. I should have said (b) looks more appropriate for Question 1?
As per http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html it is possible to copy the data from an unencrypted volume to an encrypted one.
Below is the section I am referring to. Please let me know your thoughts
Migrate Data between Encrypted and Unencrypted Volumes
When you have access to both an encrypted and unencrypted volume, you can freely transfer data between them. EC2 carries out the encryption or decryption operations transparently.
Thanks Nivlesh, you are right. the Option D is missing the encryption of the snapshot. So the ideal steps were correct
1. Create Snapshot 2. Encrypt the Snapshot 3. Create volume from the encrypted snapshot 4. mount it.
#B is correct as it does allow copy between unencrypted and encrypted volumes.
Question number 2
A user has created an EBS volume of 10 GB and attached it to a running instance. The user is trying to
access EBS for first time. Which of the below mentioned options is the correct statement with respect to a
first time EBS access?
There is not mention that the volume was created from snapshot so it will be blank.
There is no performance issue on a newly created EBS volumes.
Do you agree?
For new volumes it is not needed anymore as the implementation was update AWS.
This is an old question, for first time access to block of storage, it must be either wiped clean (for new volumes) or instantiated from its snapshot (for restored volumes) before the block was accessed.
Thanks for you clarifications.
I’m taking the SysOps exam at the end of this week. I’ve observed that may question available on you site as well as on the internet are not up to date with latest exam. Do you have any information regarding latest exam set? I would be very grateful!
Actually the exam is not updated to keep pace with the developments AWS is doing. Questions and Answers still date 2015.
Q20.Which is not a restriction on AWS EBS Snapshots?
a)Snapshots which are shared cannot be used as a basis for other snapshots (Snapshots shared with other users are usable in full by the recipient, including but limited to the ability to base modified volumes and snapshots)
b)You cannot share a snapshot containing an AWS Access Key ID or AWS Secret Access Key.
c)You cannot share unencrypted snapshots.
d)Snapshot restorations are restricted to the region in which the snapshots are created.
Option C should be given as either You can share unencrypted snapshots or You cannot share encrypted snapshots.
Please let me know your views on it.
Thanks Bhuvana, have corrected the #C answer option.
Can you please explain the answer to question 12:
12.A user is planning to schedule a backup for an EBS volume. The user wants security of the snapshot data. How can the user achieve data encryption with a snapshot?
Shouldn’t the answer be option B : While creating a snapshot select the snapshot with encryption?
Create a snapshot of your unencrypted EBS volume. This snapshot is also unencrypted.
If you want the backups to be encrypted, you need to take backups from encrypted volumes which are then by default encrypted.
This is regarding Q#16 & 17 where the user creates a snapshot of a EBS Volume. For both Qs there is an option which states “Launch a new instance”.
My doubt: What does this option mean?
Method1: To launch a new instance from a snapshot:
We need to first launch an instance, create a new volume from the snapshot, detach the existing volume from the newly launched instance, attach the volume (created from the snapshot) with the newly launched instance.
Method 2: Create an AMI from the snapshot and use that AMI to launch a new instance.
Are these the only methods available to launch a new instance from a snapshot?
Or am I missing something basic? Please help me understand.
The option is to create a snapshot/backup of the EBS volume. It is like creating a backup so that you can restore is a different volume and attach it to an instance. Snapshoting helps to recreate the volume in different AZ or Region, which is not possible with Volumes as they are AZ scoped.
You cannot launch and instance from snapshot, it has to be restored as a volume and then attached to an instance.
One Question – When a snapshot is in progress, can you detach the EBS volume and attach it to a different instance?
It should be possible, cause snapshot is taken of the volume. Also, the point-in-time snapshot is created immediately, but its creation time in S3 takes time. So it is very much possible.
Refer AWS documentation – Creating EBS Snapshot
Snapshots occur asynchronously; the point-in-time snapshot is created immediately, but the status of the snapshot is pending until the snapshot is complete (when all of the modified blocks have been transferred to Amazon S3), which can take several hours for large initial snapshots or subsequent snapshots where many blocks have changed. While it is completing, an in-progress snapshot is not affected by ongoing reads and writes to the volume.
Question 3 -Which of the following approaches provides the lowest cost for Amazon elastic block store snapshots while giving you the ability to fully restore data?
I should the answer should be A.
After writing data to an EBS volume, you can periodically create a snapshot of the volume to use as a baseline for new volumes or for data backup. If you make periodic snapshots of a volume, the snapshots are incremental which means only the blocks on the device that have changed after your last snapshot are saved in the new snapshot. Even though snapshots are saved incrementally, the snapshot deletion process is designed such that you need to retain only the most recent snapshot in order to restore the volume.
Single latest snapshot is fine as AWS maintains the link to original full snapshot as well, which you do not have to do.
Q2. Is it possible to access your EBS snapshots?
I thinks C is the the correct answer we canntot access them
Refer AWS documentation – EBS FAQs
Q: Will I be able to access my snapshots using the regular Amazon S3 API?
No, snapshots are only available through the Amazon EC2 API.
Needs change -> “Encrypted snapshots cannot be shared between accounts or made public”
You can share an encrypted snapshot with specific AWS accounts, though you cannot make it public. For others to use the snapshot, you must also share the custom CMK key used to encrypt it. Cross-account permissions may be applied to a custom key either when it is created or at a later time. Users with access can copy your snapshot and create their own EBS volumes based on your snapshot while your original snapshot remains unaffected.
“AWS prevents you from sharing snapshots that were encrypted with your default CMK”
Thanks Shankar, updated the same.
Answer should be B
B is not a complete answer though.
Comments are closed.