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

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

<p>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. </p>

<p>This link explains the process well <a href="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html" rel="nofollow noreferrer">https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html</a></p>

CC BY-SA 4.0
2018-09-24T02:08:37.503Z
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.
Hugo G
CC BY-SA 4.0
2018-09-24T07:22:33.570Z
@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
CC BY-SA 4.0
2018-09-24T08:02:33.783Z
By EBS credits you mean IOPS, right?
Hugo G
CC BY-SA 4.0
2018-09-24T08:03:21.907Z
Yes, there is baseline and burst credits for IOPS, when you are not on provisioned IOPS
jdog
CC BY-SA 4.0
2018-09-20T09:49:21.480Z
2018-09-20T09:49:21.480Z
jdog
<p>AWS provides backup functionality for RDS databases and snapshots functionality for EBS volumes.</p>

<p>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?</p>

<p>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.</p>

<p>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.</p>

<amazon-web-services><amazon-ebs>
Do AWS backups of large empty volumes take longer than small ones?
Hugo G
# Do AWS backups of large empty volumes take longer than small ones?

(Asked by: username_0 on 2018-09-18)

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.

**Tags:** amazon-web-services, amazon-ebs


---

## 1 answers

### Answer by username_1 on 2018-09-20. Score: 2 | Accepted answer

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>

> **Comments:**
> **username_0**: 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.  
> **username_1**: @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  
> **username_0**: By EBS credits you mean IOPS, right?  
> **username_1**: Yes, there is baseline and burst credits for IOPS, when you are not on provisioned IOPS  

---

