delaneybill

Not sure if this helps, but the end of the backup log gives this output:

[21-Mar-2013 08:15:19] Starting upload to MS Azure …
[21-Mar-2013 08:17:27] WARNING: fwrite(): SSL: An existing connection was forcibly closed by the remote host.

[21-Mar-2013 09:17:27 America/Chicago] PHP Warning: mysql_ping(): MySQL server has gone away in C:\DWASFiles\Sites\venturewp\VirtualDirectory0\site\wwwroot\wp-content\plugins\backwpup\inc\class-job.php on line 1093
[21-Mar-2013 08:17:27] ERROR: Microsoft Azure API: Error writing request
[21-Mar-2013 08:17:27] One old log deleted
[21-Mar-2013 08:17:27] Job done in 370 seconds.

I found an ‘answer’ to my second problem with Azure blob storage. In another thread here.
Azure Blob Storage

It’s not the dependency issue, which Daniel said he fixed, but the second issue of the backup taking too long. This results in an SSL connection error. The backup running log displays it’s progress bars(using Run now) and indicates no problem, but the error is in the log.

Like the OP of this issue, I had tested with a smaller backup (db only) and found that the same parameters for the job, same Azure container etc, does WORK. So, I guess all I have to figure out why the connection gets lost. Daniel seems to indicate in his response that he will have to get a proper callback on the upload, but why? How significant of a change has been made in the source code of WPbackup to make this happen? Azure storage has not changed at all. My backups using 2.17 were working fine just 2 days ago.

Same exact problem for me using 3.06. I also tested with smaller job and it works fine. 2.17 was working fine just 2 days ago. I may just revert to that.

Daniel, for the record, my backup job is working to create the archive file locally. I watch that happen in realtime via FTP. But then when WPbackup reaches the point of contacting Azure, it seems to hang for quite a while making the upload (not that big, just over 10mb. The entire process takes about 8 minutes. The archive file is completed in about 6 mins.

I want to add to this discussion, but the only helpful response at this point is for the development team to be transparent about their latest release. Caspar and Daniel have been replying intermittently to various complaints in different places. We need a comprehensive listing of issues and a method of following them (ala Github).
My observations to add to this forum are from two production sites, on totally different hosts, where the BackWPup failed in different ways as soon as I updated the plugin from 2.17 to 3.06
In the first case it seems to have lost the authentication information for a Dropbox account. Easily remedied (the error log made it clear), but then I was unable to test. Like others, the Job won’t run on demand. I saw Daniel and Caspar’s response to this in another thread, and it is clear that the new ‘test’ invoked during the ‘Run now’ command, is preventing a lot of users from effectively testing their backups immediately. I see the same error as everyone else: “The HTTP response test get a false http status (401)”
The second failing case is more difficult. It targets Azure storage and the credentials seem to be intact. The error log is not as helpful. But on that host I am able to execute a ‘Run now’ which is helpful if testing after making changes to backup settings.
I’ll add more information here if I can resolve the second site issues.

My only other comment is that you cannot make a bold statement like “tens of thousands of sites must be working” because of the trickle of issues popping up here. IMHO, most websites are pretty poorly maintained and errors like a backup not working may go completely unnoticed for weeks.

I want to add to this discussion, but the only helpful response at this point is for the development team to be transparent about their latest release. Caspar and Daniel have been replying intermittently to various complaints in different places. We need a comprehensive listing of issues and a method of following them (ala Github).
My observations to add to this forum are from two production sites, on totally different hosts, where the BackWPup failed in different ways as soon as I updated the plugin from 2.17 to 3.06
In the first case it seems to have lost the authentication information for a Dropbox account. Easily remedied (the error log made it clear), but then I was unable to test. Like others, the Job won’t run on demand. I saw Daniel and Caspar’s response to this in another thread, and it is clear that the new ‘test’ invoked during the ‘Run now’ command, is preventing a lot of users from effectively testing their backups immediately. I see the same error as everyone else: “The HTTP response test get a false http status (401)”
The second failing case is more difficult. It targets Azure storage and the credentials seem to be intact. The error log is not as helpful. But on that host I am able to execute a ‘Run now’ which is helpful if testing after making changes to backup settings.
I’ll add more information here if I can resolve the second site issues.

My only other comment is that you cannot make a bold statement like “tens of thousands of sites must be working” because of the trickle of issues popping up here. IMHO, most websites are pretty poorly maintained and errors like a backup not working may go completely unnoticed for weeks.