Backup script crashes on exceeded quota

I have a user who is so close to going over quota, that the Iworx backup cannot even “barf” (as it calls it) the user’s INI file. After that failure, the entire backup script crashes with an assertion failure and no more user’s are processed.

backup.php [debug]: barfing: ${PATH}/{USER}.ini
backup.php [info]: error opening file: ${PATH}/{USER}.ini
/home/interworx/include/INIConfig.php(140): 
----- ASSERTION FAILED BEGIN -----
ASSERTION FAILED: /home/interworx/include/INIConfig.php (140): 
----- ASSERTION FAILED END   -----


----- DEBUG STACKTRACE BEGIN -----
/home/interworx/include/IWorxDebug.php debug_printstacktrace (275)
/home/interworx/include/IWorxDebug.php debug_die (182)
/home/interworx/include/IWorxDebug.php debug_assert (86)
0 iworx_debug_assert (0)
/home/interworx/include/INIConfig.php assert (140)
/home/interworx/bin/backup.php writeconfig (1152)
/home/interworx/bin/backup.php backup_write_ini (171)
/home/interworx/bin/backup.php backup (98)
----- DEBUG STACKTRACE END   -----

Hi Jimp,

How is this backup being run? As a cronjob set by the user from his SiteWorx account, or as a cronjob you created yourself? Obviously, the simplest solution is to increase the user’s quota. Alternatively, if you have another partition that doesn’t have the usrquota/grpquota options, you can have the backup use that partition instead, so that the user’s quota is affected.

We’re currently working on making the backup system much more robust, and in the new version, we check for this scenario. If the user doesn’t have enough room for the backup, the account is skipped, and the backup script moves on to the next domain.

Socheat

The backup script is run as a root cron. Our goal is to create a system level backup and SSH them down to our large file server. Running the backup as root is intended to avoid permission problems, and to totally avoid the quota problem. However, the Iworx backup script appears to create output files using the group permissions in /home/$USER/backups, which follows the +s bit on the group. The only way around that would be create the backup output in a specified location, but even when I request that, it creates the backup in /home/$USER/backups and then moves it away.

My command is:

# Run the InterWorx backup script.
/home/interworx/bin/backup.pex \
    --domains=all \
    --file-path=${MY_BACKUP_POOL} \
    --email=${ME}

But the --file-path option only appears to take effect after the backup of the domain is complete, sort of like a “completion” action.

Ah, ok. My mistake, this is happening very early in the backup process. Unfortunately then, the work-around for now would be to increase the user’s quota. In the next version, the backup is created as the admin user, then after quota checks have been made, ownership of the backup file is changed so that individual user quotas are not affected during the backup process.

Socheat

That sounds like it will fix the problem. But please let me clarify. I need the backup script to recognize when I have no intention of giving the backup to the user. In that case, when the backup destination is a location outside of their home folder, I need the user’s quota to not interfere. If that’s what you are saying about the next release, then it all sounds good.

This is a slightly different scenario than the one I mentioned above, but we have already made plans to address your scenario as well. :slight_smile:

Socheat

For me the most important is to make a difference beetween a backup made from nodeworx admin and one made from siteworx users.
If it is the server admin, the quota has not be checked first.
Indeed when I backup all the siteworx accounts some of them are not because the quota of this siteworx user is jump over the limit, so every days I have some backup not made.

Pascal

This has been completely redesigned / re-implemented for the major release after this point release Pascal and it will do as you expect as well as have a robust command line interface.

Chris

top cool :slight_smile:

I second that. :smiley: