Backup function no longer working
Permalink 3 users found helpful
Hi,
I had C5 version 5.4.0.5 - my client announced that the Backup function didn't seem to work. After clicking "Backup" it seems to hang for a while, then goes to URL:http://www.tamarrowingclub.org.au/index.php/dashboard/system/backup... which just displays a blank screen.
When going back in browser history, there is no backup actually there. I checked on the server and no backup file has been created.
I updated C5 to version 5.4.1.1 but this has made no difference at all.
Can someone point me in the right direction why I have been able to successfully make backups before and now no longer? The blank screen is puzzling me a bit, there is no error message at all.
Thanks,
Wizard247
I had C5 version 5.4.0.5 - my client announced that the Backup function didn't seem to work. After clicking "Backup" it seems to hang for a while, then goes to URL:http://www.tamarrowingclub.org.au/index.php/dashboard/system/backup... which just displays a blank screen.
When going back in browser history, there is no backup actually there. I checked on the server and no backup file has been created.
I updated C5 to version 5.4.1.1 but this has made no difference at all.
Can someone point me in the right direction why I have been able to successfully make backups before and now no longer? The blank screen is puzzling me a bit, there is no error message at all.
Thanks,
Wizard247
I doubt that as my database is only 8 MB - surely that can't be the problem.
Is there anyone out there who can shed some light on why this function is no longer working?
Thanks,
Wizard247
Is there anyone out there who can shed some light on why this function is no longer working?
Thanks,
Wizard247
on my server it had some weird permissions.
Try going in via ftp to siteroot/files/backups/dbu_458u4854 or whatever it is and 777 it.
It "shouldn't" matter but maybe it does :)
-Scott
Try going in via ftp to siteroot/files/backups/dbu_458u4854 or whatever it is and 777 it.
It "shouldn't" matter but maybe it does :)
-Scott
Hi Scott,
Thanks - I set permissions from 757 to 777, but this didn't work either.
I noticed there was an .htaccess file which said:
Order Deny,Allow
Deny from all
I deleted that, tried a backup - didn't work.
Tried an encrypted backup - didn't work.
So, I put the .htaccess file back, but left permissions at 777.
When I run the backup, it establishes contact with the server for a while and it looks like it's going to do it, but then it tries to open up pagehttp://www.tamarrowingclub.org.au/index.php/dashboard/system/backup... after about 10 secs, that page is still blank.
Thanks for your input, though!
Wizard247
Thanks - I set permissions from 757 to 777, but this didn't work either.
I noticed there was an .htaccess file which said:
Order Deny,Allow
Deny from all
I deleted that, tried a backup - didn't work.
Tried an encrypted backup - didn't work.
So, I put the .htaccess file back, but left permissions at 777.
When I run the backup, it establishes contact with the server for a while and it looks like it's going to do it, but then it tries to open up pagehttp://www.tamarrowingclub.org.au/index.php/dashboard/system/backup... after about 10 secs, that page is still blank.
Thanks for your input, though!
Wizard247
About how long is it taking to process? Many shared hosts have a time limit of 30 seconds per requests which may be causing the script to timeout before it actually completes.
You may be able to drop
into your .htaccess file to increase the timeout. I haven't tried it, but in theory it increase the limit, and possibly let the script finish if that actually is the problem.
You may be able to drop
php_value max_execution_time 90
into your .htaccess file to increase the timeout. I haven't tried it, but in theory it increase the limit, and possibly let the script finish if that actually is the problem.
Yes, it thought it may have been a time-out issue, but when adding
php_value max_execution_time 90
to the .htaccess, it still did the same thing - sits there for about 10 secs waiting for contact and then brings up the blank page.
I've contacted the hosting company (SiteGround) to check if there is a problem with the server set-up. Haven't heard back from them yet.
There is supposed to be a cron job set up to handle these backups, but not one of backup has been generated via the cron. I did do some manual backups back in July and August, so it did work at some point...
Thanks,
Wizard247
php_value max_execution_time 90
to the .htaccess, it still did the same thing - sits there for about 10 secs waiting for contact and then brings up the blank page.
I've contacted the hosting company (SiteGround) to check if there is a problem with the server set-up. Haven't heard back from them yet.
There is supposed to be a cron job set up to handle these backups, but not one of backup has been generated via the cron. I did do some manual backups back in July and August, so it did work at some point...
Thanks,
Wizard247
That was going to be the next thing I was going to suggest (contacting your hosting provider) as they can, and most likely do, prevent you from overriding settings like that.
Hopefully they can let you know if there is a limit being enforced which is cutting the script off early.
Hopefully they can let you know if there is a limit being enforced which is cutting the script off early.
Well, the provider is saying this:
"The backup command itself is being executed correctly by our server. This means that the backup script of the application itself is failing to complete the backup creation."
As I said before, I have upgraded to the latest C5 version (5.4.1.1), but this did nothing to rectify the problem.
Where is the script that controls the backup? Should I reupload this particular file?
Wizard247
"The backup command itself is being executed correctly by our server. This means that the backup script of the application itself is failing to complete the backup creation."
As I said before, I have upgraded to the latest C5 version (5.4.1.1), but this did nothing to rectify the problem.
Where is the script that controls the backup? Should I reupload this particular file?
Wizard247
Well, issue solved - but not resolved...
Hosting provider says:
"We do have an Apache timeout limit set up to 10 seconds. If your script tries to access externally loaded content and it is not loaded within this time frame the page would timeout.
Unfortunately the specified limit can not be raised on our shared hosting solutions."
It takes exactly 10 secs for the process to go to the blank page.
Back to backups via CPanel...
Hosting provider says:
"We do have an Apache timeout limit set up to 10 seconds. If your script tries to access externally loaded content and it is not loaded within this time frame the page would timeout.
Unfortunately the specified limit can not be raised on our shared hosting solutions."
It takes exactly 10 secs for the process to go to the blank page.
Back to backups via CPanel...
That is annoying that they've set the timeout limit so low (30 seconds is a general minimum you'll find on shared hosts, usually more than that these days).
One thing that might speed up the process and get it to under 10 seconds is making sure you clear your site cache and logs before doing a backup (Dashboard -> Sitewide Settings, click "Clear Cache" button; then Dashboard -> Reports -> Logs, scroll down to the bottom and click the "Clear Log" button).
But if your site has been running for a while and contains lots of pages and edits and files, etc., this might not do the trick.
One thing that might speed up the process and get it to under 10 seconds is making sure you clear your site cache and logs before doing a backup (Dashboard -> Sitewide Settings, click "Clear Cache" button; then Dashboard -> Reports -> Logs, scroll down to the bottom and click the "Clear Log" button).
But if your site has been running for a while and contains lots of pages and edits and files, etc., this might not do the trick.
Thanks for your input, Jordanlev, cleared the cache and emptied the log, but still times out. :(
Does anyone know of a way to override the timeout limit?
Wizard247
Does anyone know of a way to override the timeout limit?
Wizard247
Unfortunately I think the only thing you can do (short of switching web hosts) is run the backups from PhpMyAdmin.
I am having the same problem as described. I am not on a shared server though. I did make the change for execution time but that didn't seem to make any difference.
Other ideas?
Other ideas?
Are there any error messages in the webserver log files? How about if you enable application exception logging (Dashboard -> Sitewide Settings -> Debug) and then view the c5 logs in Dashboard -> Reports -> Logs?
I looked at the apache Http log - nothing report for when I ran the backup (ran it prior to grabbing the log).
I looked at the mysql log - nothing there either.
I turned the site - in concrete - to development mode - ran the backup - no information displayed there either.
Ideas?
I looked at the mysql log - nothing there either.
I turned the site - in concrete - to development mode - ran the backup - no information displayed there either.
Ideas?
I had the same issue, but solved it. This is what i did, and after 4 seconds I had a fresh database backup!
I tried everything above, no success. My site was originally a 5.3 install, and updated ever since. But the database becomes too large by the table 'PageStatistics', if enabled.
This is what worked for me:
1 Turn off Page statistics in Dashboard > Sitewide settings
2 To be sure, I've also turned it off in my site.php in conf/
3 Logged into my phpmyadmin, tab SQL
4 Re-created the table 'PageStatistics':
5 Delete old page versions you don't need anymore
6 Clear cached files
7 Clear > 'reports > Logs'
8 Done!! Go to system... > backup .. and run for a clean backup
I tried everything above, no success. My site was originally a 5.3 install, and updated ever since. But the database becomes too large by the table 'PageStatistics', if enabled.
This is what worked for me:
1 Turn off Page statistics in Dashboard > Sitewide settings
2 To be sure, I've also turned it off in my site.php in conf/
define('STATISTICS_TRACK_PAGE_VIEWS', false);
3 Logged into my phpmyadmin, tab SQL
4 Re-created the table 'PageStatistics':
DROP TABLE IF EXISTS `PageStatistics`; CREATE TABLE IF NOT EXISTS `PageStatistics` ( `pstID` bigint(20) unsigned NOT NULL auto_increment, `cID` int(10) unsigned NOT NULL default '0', `date` date default NULL, `timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, `uID` int(10) unsigned NOT NULL default '0', PRIMARY KEY (`pstID`), KEY `cID` (`cID`), KEY `date` (`date`), KEY `uID` (`uID`) ) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
5 Delete old page versions you don't need anymore
6 Clear cached files
7 Clear > 'reports > Logs'
8 Done!! Go to system... > backup .. and run for a clean backup
@nickratering
Was there any specific purpose to dropping the PageStatistics table?
If your sole purpose was to erase the records in the table, then you needn't have dropped it and re-created it - A simple 'DELETE FROM `PageStatistics`;' would have sufficed.
Was there any specific purpose to dropping the PageStatistics table?
If your sole purpose was to erase the records in the table, then you needn't have dropped it and re-created it - A simple 'DELETE FROM `PageStatistics`;' would have sufficed.
This worked for me, simply TRUNCATE/DELETE the pagestatistics table and the backup worked.
I was having the same issue and the above solution worked for me. However, I did as twdevnet suggested and just ran the following:
DELETE FROM PageStatistics';
Seems like there is need for a couple of jobs to do occasional cleanup of the DB tables, particularly those that are logs and can/should be purged without causing issues.
DELETE FROM PageStatistics';
Seems like there is need for a couple of jobs to do occasional cleanup of the DB tables, particularly those that are logs and can/should be purged without causing issues.
I agree.
Also note that you can turn off Page Statistics via the dashboard, so that table never fills up in the first place -- of course this doesn't fix a problem after it's already happened, but I always turn this off for every site I install. And I wish the core system didn't even have this "feature" at all -- my opinion is that it's worse than useless because the number it shows is misleading (doesn't filter out bots or repeat visits from the same people).
And also note that the logs can be cleared easily from the dashboard.
Also note that you can turn off Page Statistics via the dashboard, so that table never fills up in the first place -- of course this doesn't fix a problem after it's already happened, but I always turn this off for every site I install. And I wish the core system didn't even have this "feature" at all -- my opinion is that it's worse than useless because the number it shows is misleading (doesn't filter out bots or repeat visits from the same people).
And also note that the logs can be cleared easily from the dashboard.
This is an old thread, but was still highly relevant to me as my client needed to transfer his 5.6.3 Concrete sites from an agency that had ceased trading but only had FTP and Dashboard access.
There were no backups listed in the Dashboard and I couldn't create any because of the database PageStatistics bloat described in this thread.
I modified a copy of this dangerous but highly invaluable free script at:
interconnectit.com/products/search-and-replace-for-wordpress-databases/
and modified it to truncate and optimize the PageStatistics table, allowing me to backup and download the database. I move a lot of Wordpress installations about and this script has saved the day many times.
There were no backups listed in the Dashboard and I couldn't create any because of the database PageStatistics bloat described in this thread.
I modified a copy of this dangerous but highly invaluable free script at:
interconnectit.com/products/search-and-replace-for-wordpress-databases/
and modified it to truncate and optimize the PageStatistics table, allowing me to backup and download the database. I move a lot of Wordpress installations about and this script has saved the day many times.
To clean up page stats and other database bloat on a 5.6.x site, see 'Extreme Clean' http://www.concrete5.org/marketplace/addons/extreme-clean/...
For a complete files and data backup of a site that is too big for the built in 5.6 backup, you could use your host control panel, phpMyAdmin, a ssh login and do it from the command line, or Backup Voodoo https://www.concrete5.org/marketplace/addons/backup-voodoo/...
For a complete files and data backup of a site that is too big for the built in 5.6 backup, you could use your host control panel, phpMyAdmin, a ssh login and do it from the command line, or Backup Voodoo https://www.concrete5.org/marketplace/addons/backup-voodoo/...
I am having the same problem. I think the size of the database might cause this problem. My database size is currently 31mb.