Hi, Previously I used a custom backup system, but now looking at using the ISPConfig backup system in our multi-server environment (3.0.5.4p2) However when I enabled daily backups for one web server, only a small subset of sites were backed up over the past 2 days, and only the same small subset. Running this query on both my master server, and the secondary web server, returns a count of 101. This is how many sites I enabled backups for, with backup_interval = daily, and backup_copies = 14 Code: SELECT count(*) FROM `web_domain` WHERE backup_interval = 'Daily' Result = 101 However on the /var/backup mount directory, only 10 sites were backed up. In the server config for this web server, I had ticked the box "Backup directory is a mount?", and set Backup mode = Backup web files owned by web user as zip. Any ideas?
Sorry but that thread is no help. I already understand how the ISPConfig web backups work, and they are working successfully, but only for a small subset of sites, not all.
I did not had such a case yet. The backups are done by the cron_daily.php file in /usr/local/ispconfig/server/. You can take a look at the file, starting from line 1088. The backup system runs this sql query on the local server: SELECT * FROM web_domain WHERE server_id = 1 AND (type = 'vhost' OR type = 'vhostsubdomain') replace 1 with the ID of the server and then uses this if statement to find out if a backup has to be run: if($rec['backup_interval'] == 'daily' or ($rec['backup_interval'] == 'weekly' && date('w') == 0) or ($rec['backup_interval'] == 'monthly' && date('d') == '01')) {
Thanks Till. When I run that query on the server where the sites are being backed up, I get 101 sites, but now for a third day only 10 sites are being backed up. Its like the daily cron script is only processing 10 backups, and then stopping, but I can't see anything in the logs. I might have to modify the cron_daily.php script and add some debugging, to see where its stopping.
Update, found the issue, cron daily script was running out of memory, although the error was not written to /var/log/ispconfig/cron.log, I only found this error when running the script manually and direct (cron_daily.php): Code: Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 24 bytes) in /usr/local/ispconfig/server/cron_daily.php on line 188 I had to keep increasing memory_limit in /etc/php5/cli/php.ini all the way to 150M, just to get all 101 site backups to run. As I increased from 30M, in increments of 10M, all the way to 150M. Last error was: Code: Fatal error: Allowed memory size of 136314880 bytes exhausted (tried to allocate 40961 bytes) in /usr/local/ispconfig/server/cron_daily.php on line 157 Why does this script need so much memory to run? And why isn't the error output to the log file when run from the crontab?
I dont know, we will have to debig the script and check if space can get freed during run. I've added tghis to the bugtracker.
Maybe you have very big logs? "on line 188" indicates, that the script may can´t handel your mail-log. fopen returns a resource and a resource is an in memory object.
Interestingly all our other ISPConfig servers have memory_limit = -1 for CLI PHP, so don't have this issue. While on the subject of web backups, why isn't there a clean up script that removes old backup ZIP files after the user has finished downloading them? Previously the /backup directory was a symlink into the right location in /var/backup/, which worked well, as backup files were not doubled up. But now when a user requests a backup download, the file is copied from /var/backup/* to the web folder /backup directory (no longer a symlink). We have some users that request multiple backups to download, and their /backup folder gets fill of files, that do not get removed, and wastes valuable disk space on the server. Could the daily cron script perhaps remove these files?
