Backups that fail for lack of space don't clean-up the /home/domain/.backup or /home/domains/../.backup file and fail on next backups too

Subject says it all:

Backups that fail for lack of space don't clean-up the /home/domain/.backup or /home/domains/../.backup file and fail on next backups too.

As normal, backup doesn't use the users' quota, so entire disk is then full.

This makes the server fail on all subsequent users requests.

Thus I would really appreciate if this bug could be fixed, as it is really annoying when it happens (disk full should never happen, but shit happens).

Ideally, additionally, the backup could make sure that it never fills more than e.g. 95% of the disk or keeps at least e.g. 500 MB free on disk ?

Status: 
Closed (fixed)

Comments

That's odd, as failed backups (for any reason) should cleanup all temporary files.

Can you post the error message you're getting when the backup fails? That will let me track down why it's not cleaning up.

Hi Jamie, Here the mailed failed backup log:

Creating backup for virtual server git.SITE.com ..
    Copying virtual server configuration ..
    .. done

    Backing up Cron jobs ..
    .. none defined.

    Saving mail aliases ..
    .. done

    Saving mail and FTP users ..
    .. done

    Backing up mail and FTP user Cron jobs ..
    .. none to backup

    Creating TAR file of home directory ..
    .. TAR failed! /bin/tar: ./gitlab/tmp/sockets/gitlab-git-http-server.socket: socket ignored
/bin/tar: ./gitlab/tmp/sockets/gitlab.socket: socket ignored
/bin/tar: ./gitlab/tmp/sockets/private/gitaly.socket: socket ignored
cat: write error: No space left on device

gzip: stdout: Broken pipe
/bin/tar: -: Wrote only 4096 of 10240 bytes
/bin/tar: Error is not recoverable: exiting now


   
        Saving Virtualmin configuration ..
        .. done

        Saving templates and plans ..
Failed to open /tmp/.webmin/788139_17109_10_backup.pl/0 for writing : No such file or directory at /usr/share/webmin/web-lib-funcs.pl line 1478.
        Deleting backups from xxxxxx-%Y-%m-%d on SSH server SERVER.com older than 14 days ..
            Deleting file xxxxxxx-2018-11-06 via SSH, which is 14 days old ..
            .. deleted 4 kB.

Ok I see now how this could happen - this will be fixed in the next Virtualmin release.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.