AWS EBS Snapshot – Certification

EBS Snapshot

  • EBS provides the ability to create snapshots (backups) of any EBS volume and write a copy of the data in the volume to Amazon S3, where it is stored redundantly in multiple Availability Zones
  • Snapshots can be used to create new volumes, increase the size of the volumes or replicate data across Availability Zones
  • Snapshots are incremental backups and store only the data that was changed from the time the last snapshot was taken.
  • Snapshots size can probably be smaller then 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 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
  • 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 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)
  • Snapshots of encrypted volumes are encrypted and volumes created from encrypted snapshots are automatically encrypted

EBS Snapshot Deletion

  • When a snapshot is deleted only the data exclusive to that snapshot is removed.
  • Deleting previous snapshots of a volume do not affect your 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 your 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 permissions of the snapshots
  • Only unencrypted snapshots can be shared. Encrypted snapshots cannot be shared between accounts or made public

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.
  1. 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?
    1. Upload your customer keys to AWS CloudHSM. Associate the Amazon EBS volume with AWS CloudHSM. Remount the Amazon EBS volume.
    2. Create and mount a new, encrypted Amazon EBS volume. Move the data to the new volume. Delete the old Amazon EBS volume.
    3. Unmount the EBS volume. Toggle the encryption attribute to True. Re-mount the Amazon EBS volume.
    4. 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 a EBS volume and mount it)
  2. Is it possible to access your EBS snapshots?
    1. Yes, through the Amazon S3 APIs.
    2. Yes, through the Amazon EC2 APIs
    3. No, EBS snapshots cannot be accessed; they can only be used to create a new EBS volume.
    4. EBS doesn’t provide snapshots.
  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?
    1. Maintain two snapshots: the original snapshot and the latest incremental snapshot
    2. Maintain a volume snapshot; subsequent snapshots will overwrite one another
    3. Maintain a single snapshot the latest snapshot is both Incremental and complete
    4. Maintain the most current snapshot, archive the original and incremental to Amazon Glacier.
  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?
    1. Detach EBS volumes, 2. Start EBS snapshot of volumes, 3. Re-attach EBS volumes
    2. Stop the EC2 Instance. 2. Snapshot the EBS volumes
    3. Suspend disk I/O, 2. Create an image of the EC2 Instance, 3. Resume disk I/O
    4. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Resume disk I/O
    5. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Wait for snapshots to complete, 4. Resume disk I/O
  5. How can an EBS volume that is currently attached to an EC2 instance be migrated from one Availability Zone to another?
    1. Detach the volume and attach it to another EC2 instance in the other AZ.
    2. Simply create a new volume in the other AZ and specify the original volume as the source.
    3. Create a snapshot of the volume, and create a new volume from the snapshot in the other AZ
    4. Detach the volume, then use the ec2-migrate-volume command to move it to another AZ.
  6. How are the EBS snapshots saved on Amazon S3?
    1. Exponentially
    2. Incrementally
    3. EBS snapshots are not stored in the Amazon S3
    4. Decrementally
  7. EBS Snapshots occur _____
    1. Asynchronously
    2. Synchronously
    3. Weekly
  8. What will be the status of the snapshot until the snapshot is complete?
    1. Running
    2. Working
    3. Progressing
    4. Pending
  9. Before I delete an EBS volume, what can I do if I want to recreate the volume later?
    1. Create a copy of the EBS volume (not a snapshot)
    2. Create and Store a snapshot of the volume
    3. Download the content to an EC2 instance
    4. Back up the data in to a physical disk
  10. Which of the following are true regarding encrypted Amazon Elastic Block Store (EBS) volumes? Choose 2 answers
    1. Supported on all Amazon EBS volume types
    2. Snapshots are automatically encrypted
    3. Available to all instance types
    4. Existing volumes can be encrypted
    5. Shared volumes can be encrypted
  11. Amazon EBS snapshots have which of the following two characteristics? (Choose 2.) Choose 2 answers
    1. EBS snapshots only save incremental changes from snapshot to snapshot
    2. 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)
    3. 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)
    4. 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)
  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?
    1. Use encrypted EBS volumes so that the snapshot will be encrypted by AWS
    2. While creating a snapshot select the snapshot with encryption
    3. By default the snapshot is encrypted by AWS
    4. Enable server side encryption for the snapshot using S3
  13. 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?
    1. Snapshot is synchronous
    2. It is recommended to stop the instance before taking a snapshot for consistent data
    3. Snapshot is incremental
    4. Snapshot captures the data that has been written to the hard disk when the snapshot command was executed
  14. When creation of an EBS snapshot is initiated but not completed, the EBS volume
    1. Cannot be detached or attached to an EC2 instance until me snapshot completes
    2. Can be used in read-only mode while me snapshot is in progress
    3. Can be used while the snapshot is in progress
    4. Cannot be used until the snapshot completes
  15. 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?
    1. Take periodic snapshots of the EBS volume
    2. Use a third-party Incremental backup application to back up to Amazon Glacier
    3. Periodically back up all data to a single compressed archive and archive to Amazon S3 using a parallelized multi-part upload
    4. 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

15 thoughts on “AWS EBS Snapshot – Certification

  1. 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

    1. 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.

      1. 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 😉

        1. 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.

  2. 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

    1. 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

  3. Hi. Just wanted to check if for question 1, (a) is a better answer than (d). As per , 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

    1. Creating snapshot, copying it applying encryption and creating volume is the correct way. Refer link
      Also CloudHSM does not seamlessly integrate with EBS Volumes.

        1. Hi Jayendra

          As per 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.

          1. 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.

  4. 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?

    1. 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.

      1. 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!

        1. Actually the exam is not updated to keep pace with the developments AWS is doing. Questions and Answers still date 2015.

Leave a Reply

Your email address will not be published. Required fields are marked *