After migration, backup takes 4 x more

AI-generated summary

After migrating their site, eextra noticed that their backups are taking 4x more GB with the same settings. codinghorror suggested that this might be due to retina image sizing, which creates multiple copies of images for different resolutions.

eextra questioned why the same files and content would result in larger backups after migration. codinghorror explained that it’s mostly due to caching and rendering images at smaller sizes on the fly, but agreed that backups could probably skip this process.

Stephen suggested a backup option that only covers original assets, even if it means reprocessing in a restore. codinghorror and Stephen agreed that this option would be beneficial, even if it means a short-term CPU hit.

gerhard clarified that this behavior can be configured with the include_thumbnails_in_backups site setting, which is disabled by default, and suggested that eextra create a file-based diff to determine why the backup is larger.

I restored the images by hand - I copied them from the old hosting. And everything works but there is a problem with backup now it takes 4x more GB with the same settings.

Any way to clear all unnecessary files ?

Probably due to retina image sizing because multiple copies of the images are needed depending on the resolution of the users device.

Could we get a backup option that only covers original assets? Understand it would mean a bunch of reprocessing in any restore, but wearing my ops hat for a moment it would really help with local disk space and shipping between systems.

Okay, but why does a copy of the same thing just take 4x more after migration?

after all, it’s still exactly the same files and the same content. I don’t understand where that comes from.

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?

I can’t speak for everyone but I would prefer the option to eat a short term CPU hit regenerating assets over needing to allocate 4x more disk for backups.

How do you do that ??

That’s how backups work. By default, thumbnails aren’t included in backups. We changed that at least a year ago.

You can configure that behavior with the include_thumbnails_in_backups site setting.

Include generated thumbnails in backups. Disabling this will make backups smaller, but requires a rebake of all posts after a restore.

@eextra I’d recommend creating a file based diff of the content of an old and new backup in order to find out why the backup is so much larger.

My bad – thanks for the clarification @gerhard :clinking_beer_mugs: .. I do think that’s the better default.