2

AWS provides backup functionality for RDS databases and snapshots functionality for EBS volumes.

Given a small amount of data, would the backup and restore time change depending on whether it's stored on a large disk or a small one?

In case you are asking yourself why one would put a small amount of data on a large disk: EBS gp2 volumes offer more IOPS (IO operations) with more storage (3 IOPS per 1 GB). So if you need a disk with plenty of IO operations but little persistent data, you might end up with a few megs of data sitting on a 1000 GB disk.

If my assumption that backups might take longer for larger disks is true, then it might be worth deciding for the more expensive io1 disk type instead, which can scale with up to 50 IOPS per GB.

1 Answer 1

2

Firstly I would argue that backup time does not matter, as it usually doesn't correlate with the restore time.

In regards to restore time, snapshots restore on volumes almost instantly, as data is only copied onto the volume from S3 when requested.

So as long as you only request actually used data from the volume, it would only matter how much data is used on the volume to determine the time to restore.

This link explains the process well https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html

4
  • I got a similar answer from one of the AWS engineers. Basically the EBS volumes are synced asynchronously after starting them up. So if you wanted to ensure your application having 100% disk performance from the start, you should read all files after start up. This is similar to cache warmup. Sep 24, 2018 at 2:08
  • @Hubert keep in mind that this activity may use up all your EBS credits or delay your restore time. You may also want to compare warming by accessing files vs accessing disk blocks
    – jdog
    Sep 24, 2018 at 7:22
  • By EBS credits you mean IOPS, right? Sep 24, 2018 at 8:02
  • Yes, there is baseline and burst credits for IOPS, when you are not on provisioned IOPS
    – jdog
    Sep 24, 2018 at 8:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.