[Plugin: Online Backup for WordPress] Online & Email Backups Fail

Hi Steve,

We’re working on a few minor tweaks to resolve the error you get in Manual Email. This should be ready in a couple weeks or so. Version 2.0.2 also did a few tweaks that made the error happen less often so make sure you are fully up to date.

For the Manual Online error, this is because the blog told the vault a backup was available, but the vault couldn’t connect back to find it. The blog does need to be reachable on the internet for online backup to work.
If you email your vault username to support at backup-technology.co.uk we can look further to find what the problem was – there is normally an error logged on our side.

Regards,

Jason.

Hi – I’m having the same problem as Steve. The scheduled backups have stopped, and when I try manual backups – Online, Download, or Email – I get the same error message:

The backup failed to initialise: 2: fopen(/home/mckeegan/public_html/wp-content/plugins/wponlinebackup/tmp/full/backup.zip.enc.php) [<a href='function.fopen'>function.fopen</a>]: failed to open stream: No such file or directory.

Deleted, reinstalled – same problem. Any ideas?

Hi DaveMcK,

Your error message is slightly different.

Can you login to FTP for your website, and browse to wp-content/plugins/wponlinebackup/ and tell me if there is a folder called “tmp” there, and also tell me if inside “tmp” there is another folder called “full”?

It’s quite possible your issue is a permission issue and WordPress doesn’t have the ability to write into the plugins folder.

Regards,

Jason.

Hi DaveMcK,

Thinking again you did manage to install the plugin… So probably not a permission thing lol. Check the folders are there anyway. And can you give me the full event log for the activity? (Click Activity Log and then View Events to view it.) It might give a bit more information.

Jason.

Hi Jason

I checked and the tmp and full folders weren’t there!

I created them, each with 755 permissions, but I still got an error message.

The backup failed to initialise: 2: fopen(/home/mckeegan/public_html/wp-content/plugins/wponlinebackup/tmp/backup.data.php) [<a href='function.fopen'>function.fopen</a>]: failed to open stream: Permission denied.

So it might be permissions this time! What should they be?

Thanks for your help!

Dave

Hi Dave,

That is really strange. The plugin comes with a tmp folder in it already so there should be no reason for either of those to be missing.
When a full backup starts (during download and email backup) it tries to create the full directory – so this must be failing and then giving the No such file or directory error about the full directory. (I think we don’t check for error when making directory – I’ll put this on the timeline as that error would’ve been more helpful to us!)

Can you try 777 permissions on those folders? Some oddly setup servers need it like that.

Let me know how you get on.

Jason.

I did:

chgrp -R 777 tmp

and it looks like the backup is working (54% as I speak). I’ll wait till tomorrow to see if he scheduled backup is working as normal.

Doesn’t seem like an ideal setup, security wise? But I’ll be happy if it’s all working again.

Thanks for your help, and for a great service.

Dave

Hi Dave,
Great news! Least we now found the root cause.
But definitely, you are very right, not the ideal setup. 770 would be a bit better if that works. Best to contact your host about what setting you need to keep it secure as it can differ from host to host.
Jason.

For the record – in case anyone is referencing this thread – that command I did was

chmod -R 777 tmp

NOT chgrp.

I tried 770, but the backup failed, so back to 777 for now.

D

Same problem here.

The backup failed to initialise: 2: fopen(/home/BLAH/domains/BLAH.com/public_html/wp/wp-content/plugins/wponlinebackup/tmp/backup.data.php) [function.fopen]: failed to open stream: Permission denied.

There was no tmp directory, so I created that directory and the full subdirectory with my FTP client. The manual backup runs when permission is 777 but not at 770.

FYI, hope this is fixed; feels strange to be doing this the same day that I got hit with the index.php exploit!!

Hi,

There is nothing we do to fix this issue. We can only make the problem more clear and give more information on why it is there.

The problem lies with the host’s poor infrastructure design. On such hosts it is almost certain they are using PHP versions that are more than 2 years old so they can utilise PHP Safe Mode to secure the server. If they aren’t, then I wouldn’t worry about the 777 as the server is already completely insecure.

PHP themselves have always recommended against using Safe Mode to resolve shared hosting security, and have completely removed the feature 2 years ago in PHP 5.3. If you host is not running PHP 5.3 or above it is more than likely because they rely on Safe Mode.
https://php.net/manual/en/features.safe-mode.php

Hope this information helps – but if your host’s shared servers are setup this way I would advise to switch.

Jason.

I don’t think this is a safe_mode issue. My host (Positive Internet Co) is using php 5.2.9-0.dotdeb.1 with Apache 2.0 and safe_mode OFF – but I can’t get the backup to work without 777 or 707 permission on the tmp directory.

For this reason, I have had to abandon this backup method. Those permissions are just asking for trouble.

Hi DaveMcK,

The issue isn’t Safe Mode, the issue is the server configuration. Safe Mode is something that allows hosts to secure their server and get around the security problems that arise from running PHP under a single anonymous user (which means you need 777 permissions to write to your directories using PHP.)

As I have said though, if your server is NOT using Safe Mode, then it is already extremely insecure and your site is already highly vulnerable to all other users on that host. So in this case it is best to switch provider.

I’m afraid there is no way we can support such servers – there is no way we can do a secure backup if the server itself is not secure – so all I can do is offer advice. As I’ve said we’ll be improving documentation etc soon so we can make people aware of all this.

Jason.

After I made the changes above, I scheduled a backup (database only) to run on Monday at 6am. The activity log shows it took 1 minute and 5 seconds and emailed me a 6.57M file. I didn’t get the message and I don’t see it in my Gmail spam folder.

So I just decided to do a manual backup and try the email option again.

It held at 60% for almost 20 minutes; it wasn’t until I started looking at the activity log to write this post that it somehow finished. And in fact the email did arrive (although since the last time I used this, it’s now an .RC file?)

So not sure about the scheduled email not arriving and the change in file format and the variable time to create a backup….thanks for your help!

Hi steveportigal,

The backup may have timed out a few times and when you went to activity log it just happened to get through the bit that caused the time out. Next version will speed up the timeout recovery so its much much quicker.

As for the RC extension, that shouldn’t be there, you can just rename the file to remove it. This is sorted in next version too.

Not sure why you wouldn’t have received the first file. All I can think is it got rejected somewhere, or WordPress’s phpMailer failed to send it but didn’t raise an error.

Jason.