# After migration, backup takes 4 x more

**URL:** <https://meta.discourse.org/t/after-migration-backup-takes-4-x-more/144305>\
**Category:** Product Support\
**Tags:** backups\
**Created:** [March 14, 2020, 11:26am UTC](https://meta.discourse.org/t/after-migration-backup-takes-4-x-more/144305 "2020-03-14T11:26:24Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\
**Post date:** [March 14, 2020, 10:30pm UTC](https://meta.discourse.org/t/after-migration-backup-takes-4-x-more/144305/5 "2020-03-14T22:30:14Z")

</div>

It’s mostly a caching thing, otherwise you’d have to re-render the images at smaller sizes on the fly which would be extremely computationally intensive.

You’re right that backups can probably skip this part though @stephen and I know @sam has mentioned this in the past? The only downside is restoring a backup becomes very CPU intensive as the backup must then re-render all the resolutions, but that’s not a serious downside in my book – unless you’re in a hurry, or have a CPU underpowered server perhaps?

---

_[View the full topic](https://meta.discourse.org/t/after-migration-backup-takes-4-x-more/144305)._
