# Better auto-backup options **URL:** \ **Category:** Feature\ **Tags:** backups, s3\ **Created:** [9월 16, 2015, 1:20오후 UTC](https://meta.discourse.org/t/better-auto-backup-options/33351 "2015-09-16T13:20:43Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![ky\_metro](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ky_metro/32/42807_2.png) [@ky\_metro](https://meta.discourse.org/u/ky_metro)\ **Post date:** [8월 3, 2017, 8:57오후 UTC](https://meta.discourse.org/t/better-auto-backup-options/33351/4 "2017-08-03T20:57:36Z")
Well, revisiting this. Glad to report this has worked great for awhile, by manipulating S3 settings and using Glacier: > [@ky\_metro](#): > > Option to manage S3 storage separate from Discourse. Again, with limited local disk space, I’d like the option to keep one daily backup on local disk but infinite backups on S3. This one is fixed too, apparently: > [@ky\_metro](#): > > - Notification if auto-backup failed to run. Right now it fails silently, and I have to remember to check on it. It will now notify you if backups fail. Yay! Unfortunately the way I found that out is when my disk filled up again… * * * So, I have a question about the files backup procedure. Currently I need at least double the backup’s size in available free space. For example my currently 8GB install needs 16 GB of free space for a backup to succeed. Otherwise gzip runs out of space, and the backup fails. 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? * * * Related, and this maybe should be a bug report. When the backup does fail, the script does not delete the partial failed backup file, which can be quite large. Because of this, multiple failed attempts will entirely fill up the disk and possibly crash the site. --- _[View the full topic](https://meta.discourse.org/t/better-auto-backup-options/33351)._