# Better auto-backup options

**URL:** <https://meta.discourse.org/t/better-auto-backup-options/33351>\
**Category:** Feature\
**Tags:** backups, s3\
**Created:** [September 16, 2015, 1:20pm UTC](https://meta.discourse.org/t/better-auto-backup-options/33351 "2015-09-16T13:20:43Z")\
**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:** [August 3, 2017, 9:36pm UTC](https://meta.discourse.org/t/better-auto-backup-options/33351/5 "2017-08-03T21:36:59Z")

</div>

> [@ky\_metro](#):
>
> I assume that the backup script copies all the files to be backed up to a temp folder, then begins to zip the copies? Could it not work directly from the original files, and avoid this double space requirement?

We looked at this in exhaustive depth about 6 months ago. This is _only_ true if you back up just the database. Once you have to backup the database _and the uploads too_, it is unavoidable that you need to merge the database backup, which is one giant streamed-to-compression file, with a bunch of `.jpg` and `.gif` and `.png` and `.doc` uploaded files, so at that point you need 2x disk space and that 2x space cost is indeed unavoidable.

So, if disk space is at a premium, select the “database only” backup style, and back up the uploads some other way. Compressing gifs and jpgs doesn’t work very well anyway, so just straight copying them out is a viable strategy, minus “lots of tiny files” processing overhead.

cc @pfaffman

---

_[View the full topic](https://meta.discourse.org/t/better-auto-backup-options/33351)._