backup.pex --workpath=

[jimp]

I am attempting to backup an account as root using backup.pex --file-path=. My command is: # /home/interworx/bin/backup.pex --domains=DOMAIN --file-path=PATH --email=EMAILTo be clear, I am running the backup process as root, which does not have a quota, and writing the result to a location with a sufficient amount of disk space. When I try to backup a large account (one using more than 60% of their quota), I get:Creating SiteWorx data archive
Archiving databases
Archiving databases complete

gzip: stdout: Disk quota exceeded
/bin/tar: FILE: Wrote only 4096 of 10240 bytes
/bin/tar: Error is not recoverable: exiting now:confused:

I noticed the top of the output says:backup filename was not provided
/home/USER/backups already exists. Continuing...Why does the script care about the user's backup folder if I have specified where the result needs to go? Also, would providing a "backup filename" fix the problem [immediately]?

[IWorx-Socheat]

I am attempting to backup an account as root using backup.pex --file-path=. My command is: # /home/interworx/bin/backup.pex --domains=DOMAIN --file-path=PATH --email=EMAILTo be clear, I am running the backup process as root, which does not have a quota, and writing the result to a location with a sufficient amount of disk space. When I try to backup a large account (one using more than 60% of their quota), I get:

This appears to be another bug, related to the previous backup bug you reported. :( Since storage quotas are calculated based on group ownership of files, we made sure to make backup files are group owned by the 'iworx' user. However, during the tarring of the data archive, the file is initially group owned to the SiteWorx user, causing the error you see.

I noticed the top of the output says:backup filename was not provided
/home/USER/backups already exists. Continuing...Why does the script care about the user's backup folder if I have specified where the result needs to go? Also, would providing a "backup filename" fix the problem [immediately]?

It only "cares" because when we first created the "new" backup system, the /home/uniqname/backups dir didn't always exist, so we checked for it and created it if it did not exist, and nothing else. That's all that check is doing.

Socheat