Backup fails because of some database error

Hi @herculesjack, I’m sorry to hear about the issue you’re having backing up your site. We’re more than happy to help get this resolved though!

1. What steps can we take to replicate this issue? For example, is this a scheduled backup, or are you clicking “Backup Site Now”?

2. When looking at the list of tables, they all seem to have “wsm” listed in them. Is that the “WSM Downloader” plugin?

Thanks,
– Brad

Hi @bwmarkle , I first found this issue because I scheduled a backup but nothing happened. Then I tried to click “Backup Site Now” on the Total Upkeep page, but still nothing happened, neither did I receive any email. Next I tried to click “Backup Site Now” on the Plugins page, and this time I could see the error message.

I have not installed the “WSM Downloader” plugin so far. I doubt it’s because of some visitor stats plugin I’m using. Is there a way to figure out which plugin produces those database files?

Hi @herculesjack, thanks for getting back to me. I just wanted to mention that I think we’ve found the issue, and we should have a patch to fix this bug tomorrow.

@bwmarkle that’s great, thanks for your help!

Hi @herculesjack,

After writing a draft of this response for you, I realized I’m getting probably more technical that you care to know. I’m really happy to see you’re giving Total Upkeep a try, and I want to make sure you’re aware that we’re trying to get this bug sorted out for you!

I was hoping to get a fix out for this today (as I said I would), but after further troubleshooting, I’m about 90% sure your issue is being caused by a 3rd party library we’re using to dump databases.

Bugs begin to get a little harder to fix when they’re in 3rd party code. I’ve submitted a bug report for them. If you’re interested in the technical details of that bug, you can view it here – https://github.com/ifsnop/mysqldump-php/issues/185

The error that you’re getting is saying that certain tables don’t exist in the database. It’s true, but after further troubleshooting, I found that they’re actually “views”, not “tables”.

If by chance you’re interested in the technical side of this bug, it’s being caused by the Real Time Visitor Statistics plugin that you’re using. It’s not technically being caused by them, but instead, problems are arising because they’re using both “tables” and “views”. It’s common that plugins create tables, but using views is rare (not wrong). In all our testing, we never came across a plugin using views, and so we never ran into this issue.

If I don’t get a response to the bug report in a day or two max, we’ll work around this and get a solution published. It’s better to fix the problem rather than offer a “work around”.

Thanks!
– Brad

@bwmarkle Thanks for the information & I’m looking forward to your next updates! ??

Hi @herculesjack,

Thanks for your patience on this issue. We just released Total Upkeep 1.12.4, which resolves the bug that you brought to our attention. When you have time, please upgrade and test. It should be good to go, but please do let us know if you experience any other issues.

Thanks!
– Brad

Hi @herculesjack, I just wanted to touch base once more and find out if our update had resolved your issues?

Thanks,
– Brad

@bwmarkle Sorry for my delayed reply! I just updated total upkeep to the latest version and tried to start backup with “backup site now”, but it seems to get stuck at the “saving archive to disk” step.

Total Upkeep - Backup in progress

Total Upkeep began archiving your website 7 seconds ago.
Backing up database...
Adding files to archive...
Saving archive to disk...
Archive file size: 85.07 MB
File size before compression: 262.59 MB

So could you help me look into this issue a bit more? Thanks!

Hi @herculesjack,

Thanks for giving the backup another try, and I’m sorry to hear that it’s getting stuck on the “Saving archive to disk” step.

I pinged your domain name, and I can see it’s pointing to a Dreamhost server. We have another user having the same issue on a Dreamhost server, and we’re currently talking with their support team about what may be happening.

I will touch base soon when we have a little more information.

Thanks,
– Brad

I see. Thanks for your work & I’m looking forward to your updates! ??

i was having a similar issue and just had a wait a very long time, but seems to be working. i am also hosting on dreamhost.

• This reply was modified 5 years, 1 month ago by montynasser.

Hi @montynasser,

We have a release coming out this Thursday with some updates that may help on the DreamHost side. I will post here when the new version comes out.

Thanks,
– Brad

Hi @montynasser and @herculesjack,

So, we’ve been working with DreamHost on this issue for some time now.

I’ve published an article on it here, and I’ll give you a rundown of what DreamHost recommends…

Link: https://www.boldgrid.com/support/total-upkeep/dreamhost-without-fastcgi/

DreamHost recommends that you trying using PHP 7.3 (without FastCGI active), and they have a guide on it here: https://help.dreamhost.com/hc/en-us/articles/214895317

It sounds like there’s fewer restrictions with that environment, and in our testing, it looks like it resolves the issue. More info can be found in the first link above.

If you’re able to, please try updating your environment and testing backups again. Let us know if you run into any issues.

Thanks!
– Brad

Hi @bwmarkle , I have not tried your latest instructions regarding PHP, but just updated total upkeep to the latest version and then the backup seems to work well. Thanks for your help on this issue!