Which procedure for backing up a relational database on EC2 that is using a set of RAlDed EBS volumes for
storage minimizes the time during which the database cannot be written to and results in a consistent backup?
A.
1. Detach EBS volumes, 2. Start EBS snapshot of volumes, 3. Re-attach EBS volumes
B.
1. Stop the EC2 Instance. 2. Snapshot the EBS volumes
C.
1. Suspend disk I/O, 2. Create an image of the EC2 Instance, 3. Resume disk I/O
D.
1. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Resume disk I/O
E.
1. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Wait for snapshots to complete, 4. Resume disk I/O
Explanation:
http://media.amazonwebservices.com/AWS_Storage_Options.pdf (page 11)
E
D – You should not wait until snapshot is complete (“complete” status means that snapshot is transferred to S3 (and can be used), but making an actual snapshot is an instance operation)
Important – I may be wrong, please verify this information.
http://serverfault.com/questions/548731/can-i-re-attach-my-ebs-while-a-snapshot-is-pending
See comments here – http://www.aiotestking.com/amazon/when-creation-of-an-ebs-snapshot-is-initiated-but-not-completed-the-ebs-volume/
The answer is B b/c this is a RAID.
https://aws.amazon.com/cn/premiumsupport/knowledge-center/snapshot-ebs-raid-array/
Short Description
When you take a snapshot of an attached Amazon EBS volume that is in use, the snapshot excludes data cached by applications or the operating system. For a single EBS volume, this is often not a problem. However, when cached data is excluded from snapshots of multiple EBS volumes in a RAID array, restoring the volumes from the snapshots can degrade the integrity of the array.
When creating snapshots of EBS volumes that are configured in a RAID array, it is critical that there is no data I/O to or from the volumes when the snapshots are created. RAID arrays introduce data interdependencies and a level of complexity not present in a single EBS volume configuration.
Resolution
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.
That leads to B being the answer right?
B
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.
As long as it takes hours in large snapshots, I would recommend “D”
I will go with D
Answer is B.
We want to minimize downtime and also have a consistent backup.
D is clearly incorrect because data I/O will start during snapshot (D only really works if you have non-raid vol)
E sounds plausible, but how do you totally and effective stop disk I/O other than shutting down the EC2 or detaching the volume?
B is quick and simple.
https://aws.amazon.com/premiumsupport/knowledge-center/snapshot-ebs-raid-array/
When creating snapshots of EBS volumes that are configured in a RAID array, it is critical that there is no data I/O to or from the volumes when the snapshots are created.
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.
D is correct Answer.
https://aws.amazon.com/premiumsupport/knowledge-center/snapshot-ebs-raid-array/
A.
minimizes the time during which the database cannot be written to and results in a consistent backup.
I would choose A too. As stated before, it leads to minimal downtime and results in a consistent backup.
I choose A
I go with D
acloud.guru says:
D. 1. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Resume disk I/O
(Fast , and ‘start EBS snapshot’ sounds right)
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
IMHO Answer is D!
B
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.
agree, A is wrong you don’t need to detach the volumes.
If you choose A what will the state of the DB and the EC2 when you detach the volumes (assuming all at once)
I would imagine stopping the EC2 (B) would at least formally take the DB out of service.
Suspending I/O will create inconsistency in the snapshot due to caching that was discussed in earlier responses.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-detaching-volume.html says you need to terminate ec2 or unmount before you can detach.
https://aws.amazon.com/premiumsupport/knowledge-center/snapshot-ebs-raid-array/ says for raid, you should suspend all io and flush the cache …
I pick B.
D is right.
>From https://acloud.guru:
A. 1. Detach EBS volumes, 2. Start EBS snapshot of volumes, 3. Re-attach EBS volumes
Plausible not fast, but not the slowest
B. 1. Stop the EC2 Instance. 2. Snapshot the EBS volumes
The slowest but highest confidence factor
C. 1. Suspend disk I/O, 2. Create an image of the EC2 Instance, 3. Resume disk I/O
Fast , but ‘Create Image’ has special meaning and may not be what you are looking for.
D. 1. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Resume disk I/O
_Fast , and ‘start EBS snapshot’ sounds right _
E. 1. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Wait for snapshots to complete, 4. Resume disk I/O
Starts Fast, but waiting for the Snapshot to finish could be hours, so not correct in my opinion.
After read https://aws.amazon.com/premiumsupport/knowledge-center/snapshot-ebs-raid-array/
I think B is correct.
I agree with you 🙂 🙂
Answer B
Correct answer is B because of the RAID array as per Amazon’s explanation here:
https://aws.amazon.com/cn/premiumsupport/knowledge-center/snapshot-ebs-raid-array/
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.
Problem with answer A is that the application could still be writing to disk when they’re dismounted, so data could be inconsistent. Removing the volumes will force an OS cache flush but that is not enough.
Also as said here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-detaching-volume.html
“You can detach an Amazon EBS volume from an instance explicitly or by terminating the instance. However, if the instance is running, you must first unmount the volume from the instance.”
Option A does say anything about unmounting the volume, hence the risk of inconsistency.
Option B does not say anything about starting the EBS volume .. so seems to be incomplete
The answer is D
Please note that it requires “minimizes the time”.
https://aws.amazon.com/cn/premiumsupport/knowledge-center/snapshot-ebs-raid-array/
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.
Answer is B
Keywords are ‘consistent backup’ and ‘relational database’
Making a consistent backup of a relational database (MSSQL, Oracle, MySQL),
–> with the database engine still running <–
can only be done using a "managed process" such as a backup agent, database tools or (SQL) statements executed by the database engine.
A, C, D and E make a backup of the database file (system) with a running database engine.
Even if you can suspend disk I/O, this does not force the database engine to flush it's (mostly HUGE) caches
Even if you can suspend(/halt) disk I/O, the database engine will complain (probably crash)
Even if you can suspend disk I/O and database engine accepts this, the databases (files) themselves will still be marked "open", which will result in (automatic or not) database repairs when mounted/attached from backup.
Stopping the database instance will flush (respective) caches and properly close database files.
As no database tooling is mentioned, the only answer which stops the database engine, is B, which stops the EC2 instance, thereby the database engine.
B is the only answer which results in a consistent backup of a relational database (or at least for MSSQL, Oracle, MySQL)
Answer is D.
refer for backup application-consistency http://www.n2ws.com/blog/ebs-snapshots-crash-consistent-vs-application-consistent.html
I believe B is the answer…the word fastest is included deliberately so people think of other option than B. For a DB running on RAID these are two critical words. I do not see anywhere in AWS where AWS recommends snapshoting a RAID volume with the machine running. Quiesing disc IO is okay in case of Root volume
Agree with Tony ans Bob: B is the Answer
D is correct answer
Look at this article from AWS
https://aws.amazon.com/premiumsupport/knowledge-center/snapshot-ebs-raid-array/
As per the link B is correct answer
Here is the details :
Short Description
When you take a snapshot of an attached Amazon EBS volume that is in use, the snapshot excludes data cached by applications or the operating system. For a single EBS volume, this is often not a problem. However, when cached data is excluded from snapshots of multiple EBS volumes in a RAID array, restoring the volumes from the snapshots can degrade the integrity of the array.
When creating snapshots of EBS volumes that are configured in a RAID array, it is critical that there is no data I/O to or from the volumes when the snapshots are created. RAID arrays introduce data interdependencies and a level of complexity not present in a single EBS volume configuration.
Resolution
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.
https://aws.amazon.com/premiumsupport/knowledge-center/snapshot-ebs-raid-array/