PrepAway - Latest Free Exam Questions & Answers

which the database cannot be written to and results in a consistent backup?

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?

PrepAway - Latest Free Exam Questions & Answers

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)

38 Comments on “which the database cannot be written to and results in a consistent backup?

  1. T says:

    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.




    1



    0
  2. TONY says:

    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.




    0



    0
  3. Muhammad Soliman says:

    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”




    0



    0
  4. Kelvin Wong says:

    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.




    1



    0
  5. kamleshj says:

    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.




    0



    0
  6. Arun says:

    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.




    0



    0
  7. Da says:

    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.




    0



    0
  8. vladam says:

    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.




    1



    0
    1. vladam says:

      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.




      0



      0
  9. Dong Liang says:

    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.




    0



    0
  10. Bob says:

    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)




    1



    0
  11. Amit says:

    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




    0



    0
    1. sp says:

      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.




      0



      0

Leave a Reply

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