# When backup fails, delete the useless backup
**URL:** https://meta.discourse.org/t/when-backup-fails-delete-the-useless-backup/66953
**Category:** Feature
**Created:** [July 27, 2017, 7:33pm UTC](https://meta.discourse.org/t/when-backup-fails-delete-the-useless-backup/66953 "2017-07-27T19:33:37Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [July 27, 2017, 7:33pm UTC](https://meta.discourse.org/t/when-backup-fails-delete-the-useless-backup/66953/1 "2017-07-27T19:33:37Z")
If a site backup fails due to disk space when it’s gzipping the backup, the .tar file is left. Discourse can’t see it or use the tar file. On one hand, a decent sysadmin would be alarmed enough at a failed backup and immediately go solve the disk space problem and then gzip the backup by hand in a shell. On the other hand, someone who doesn’t like getting their hands dirty in a shell is sort of out of luck.
As an aside, it would seem like 50GB would be a reasonable partition size for a site with a 13GB backup, but since there are two copies of the current backup while it’s gzipping, and `maximum backups` doesn’t delete a backup until there are more than maximum backups, 50GB is enough for `maximum backups` to hold only one backup. It took me quite a while to understand that math.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 27, 2017, 11:58pm UTC](https://meta.discourse.org/t/when-backup-fails-delete-the-useless-backup/66953/2 "2017-07-27T23:58:02Z")
Try a database-only backup, which skips the “combine all the uploaded files into the database archive” step and thus doesn’t need 2x the disk space in the process.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [July 28, 2017, 12:18am UTC](https://meta.discourse.org/t/when-backup-fails-delete-the-useless-backup/66953/3 "2017-07-28T00:18:44Z")
> [@pfaffman](#):
>
> If a site backup fails due to disk space when it’s gzipping the backup, the .tar file is left.
It this isn’t happening this is a bug. I’m pretty sure we have code to handle cleanup on failure. Which folder is the backup left in? Is it the tmp folder?
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [July 28, 2017, 12:22am UTC](https://meta.discourse.org/t/when-backup-fails-delete-the-useless-backup/66953/4 "2017-07-28T00:22:40Z")
It’s on the same folder where finished backups resides, `/shared/standalone/backups/default/`.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [July 28, 2017, 12:24am UTC](https://meta.discourse.org/t/when-backup-fails-delete-the-useless-backup/66953/5 "2017-07-28T00:24:31Z")
Hmm that is strange.. the entire backup process should take place in a tmp folder before being moved to the backups folder. So if anything blows up, it’ll clean up the tmp folder after. Maybe we’ll not catching the error when gzip blows up some how. I’ll have a 👀
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [July 28, 2017, 12:24am UTC](https://meta.discourse.org/t/when-backup-fails-delete-the-useless-backup/66953/6 "2017-07-28T00:24:31Z")
Well, the site is up to date.
> [@tgxworld](#):
>
> Which folder is the backup left in? Is it the tmp folder?
No. And I thought for a while that perhaps the problem was that it was writing to /tmp and I’ve got a whole separate partition just for backups, so now the site doesn’t crash when the backup fills the disk, but . . . what @falco just said. It could be complicated by having backups somewhere else like this:
```plaintext
- volume:
host: /mnt/backups
guest: /shared/backups
```
If you’ll point me to the file where the script is (about 30% of the time it’s _exactly_ where I think it’ll be) I’ll check & if I can figure it out (and unless it’s something bizarre, finding the script should be 90% of the problem for me) I’ll submit a PR.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [October 2, 2017, 6:34am UTC](https://meta.discourse.org/t/when-backup-fails-delete-the-useless-backup/66953/8 "2017-10-02T06:34:05Z")
Sure, we want to fix this, but we need a proper repro of the issue with very careful and consistent steps.
I believe this somehow relates to running out of disk space, and maybe followed by a server crash, forcing us to add cleanup code either at boot or when you run next backup.
---
### Author:  [@JagWaugh](https://meta.discourse.org/u/JagWaugh)
#### Post date: [December 15, 2017, 1:22pm UTC](https://meta.discourse.org/t/when-backup-fails-delete-the-useless-backup/66953/9 "2017-12-15T13:22:21Z")
Bump.
The .tar and the final tar.gz both appear in `/var/discourse/shared..../backup` while it is running.
The tar.gz is visible in the web interface at `/admin/backups` while the uploads are being added to it (and it’s size increments up).
When it runs out of space the tar.gz disappears from `/admin/backups`, but the .tar file is still, and the space is not returned (this 4 hours after the backup failed).