andfarr

Hi,

I received the response, and the API was operational for a brief period of time. However, it appears you WordFence API errors are resurfacing. Is this issue still considered resolved?

This is the most bizarre behaviour.

I have the same issue:

Wordfence connectivity tester

DNS lookup for noc1.wordfence.com returns: 69.46.36.8

STARTING CURL http CONNECTION TEST….
Curl connectivity test passed.

STARTING CURL https CONNECTION TEST….
Curl connectivity test passed.

Starting wp_remote_post() test
wp_remote_post() test to noc1.wordfence.com passed!

Starting wp_remote_post() test
wp_remote_post() test to noc1.wordfence.com passed!
—-
In options:
Key type currently active: The currently active API Key is a Premium Key. Premium scanning enabled!
—-
ERROR:[Mar 01 04:11:29] Call to Wordfence API to resolve IPs failed: WordFence API error: The Wordfence key you’re using is not valid. Make sure you copied it correctly from https://www.wordfence.com.
—-

On the WordFence website profile area, I checked to make sure I have the right WordFence API Key, copied it again making sure that is not the issue, but in the “Get you API keys” area of the WordFence member area, under website, it for some reason displays: “Not assigned yet” when it has been assigned.

Cloudflare is not the issue. I am not using Cloudflare. It is without doubt a strictly WordFence issue.

From what I recall, the very first backup (which was manually initiated) following the update of the plugin to the most recent version worked normally without errors. It was subsequent updates that is where the errors began occurring. Not sure if that helps you at all, but that was how I think it went this most recent run at it.

Thanks Mikey!
Andrew

Yes, that is a message from 1.5.4. Actually this has been occurring for at least this most recent update and the previous one as well. I just reverted back to 1.4.5 after trying a few backups with each release when I found the error persisted instead of messing with it. 1.4.5 works for me with a smaller sized backup so that is what I have been relying on.

Let me know if there is anything else I can do to help.

I tried to update (as opposed to re-install) and came up with the 500 internal server error message. Luckily I had copied my folder and switched the names around just in case so it wasn’t a big deal. Any thoughts? Should I do a full re-install?
It mentions access levels. Is there certain file permissions I should double check?

500 error

I downgraded to the previous version. I had gotten it to work without any issues for my ~250mb backup, so I’m just going to sit tight for the next release ??

Thanks for all your hard work!

I have a massive php error log full of what looks to be exactly the same type of errors.

Massive list

Correction: The settings-display section I referred to is actually in Settings: File Browser -> “Post ID of the File browser”

I am having this issue as well. However, I am using the zip extension.
When the extension was finishing successfully my site was around 450-500mb.

17:15:45: Backup started on Saturday April 20, 2013.
17:15:45: Your time limit is 14400 seconds and your memory limit is 1000M
17:15:59: Creating SQL backup of your WordPress core.
17:16:15: Creating SQL backup of your WordPress plugins.
17:23:17: There has been no backup activity for a long time. Attempting to resume the backup.
17:24:05: Creating zip archive.
17:24:19: Approximately 1% complete.
17:24:26: Approximately 38% complete.
17:24:33: Approximately 99% complete.
17:24:41: Approximately 99% complete.
17:24:53: Approximately 99% complete.
17:25:01: Approximately 99% complete.
[…]
17:36:19: Approximately 99% complete.
17:36:30: Approximately 99% complete.
17:36:43: Uploading /home5/andrexw1/public_html/blog/wp-content/backups/a-farr-|-riskier-market-backup-2013-04-20.zip (505.95MB) in chunks.
17:43:07: There has been no backup activity for a long time. Attempting to resume the backup.
17:47:08: Creating SQL backup of your WordPress core.
17:47:22: Creating SQL backup of your WordPress plugins.
17:49:33: Backup complete.
17:49:33: A total of 40789 files were processed.
17:49:33: A total of 56MB of memory was used to complete this backup.
17:58:14: There has been no backup activity for a long time. Attempting to resume the backup.
18:01:14: Creating zip archive.
18:01:20: Approximately 51% complete.
18:01:26: Approximately 51% complete.
18:01:32: Approximately 51% complete.
18:01:38: Approximately 51% complete.
[…]
18:05:45: Approximately 51% complete.
18:05:51: Approximately 51% complete.
18:05:53: Uploading /home5/andrexw1/public_html/blog/wp-content/backups/a-farr-|-riskier-market-backup-2013-04-20.zip (1.15MB).
18:11:10: There has been no backup activity for a long time. Attempting to resume the backup.
18:12:11: Creating SQL backup of your WordPress core.
18:12:31: Creating SQL backup of your WordPress plugins.
18:17:44: Creating zip archive.
18:18:00: Approximately 1% complete.
18:18:09: Approximately 38% complete.
18:18:18: Approximately 79% complete.
18:18:25: Approximately 99% complete.
[…]
18:34:01: Approximately 99% complete.
18:34:09: Approximately 99% complete.
18:34:25: Uploading /home5/andrexw1/public_html/blog/wp-content/backups/a-farr-|-riskier-market-backup-2013-04-20.zip (502.06MB) in chunks.
18:45:09: There has been no backup activity for a long time. Attempting to resume the backup.
18:46:10: Creating SQL backup of your WordPress core.
18:46:28: Creating SQL backup of your WordPress plugins.
18:46:57: Backup complete.
18:46:57: A total of 60711 files were processed.
18:46:57: A total of 63MB of memory was used to complete this backup.
18:52:12: There has been no backup activity for a long time. Attempting to resume the backup.
18:53:12: Creating zip archive.
18:53:18: Approximately 67% complete.
18:53:24: Approximately 67% complete.
[…]
18:57:22: Approximately 67% complete.
18:57:28: Approximately 67% complete.
18:57:33: Uploading /home5/andrexw1/public_html/blog/wp-content/backups/a-farr-|-riskier-market-backup-2013-04-20.zip (0.51MB).
19:05:15: There has been no backup activity for a long time. Attempting to resume the backup.
19:06:16: Creating SQL backup of your WordPress core.
19:06:49: Creating SQL backup of your WordPress plugins.
19:17:13: There has been no backup activity for a long time. Attempting to resume the backup.
19:18:19: Creating zip archive.
19:18:25: Approximately 50% complete.
19:18:31: Approximately 50% complete.
[…]
19:23:24: Approximately 50% complete.
19:23:30: Approximately 50% complete.
19:23:36: Approximately 50% complete.
19:23:41: Uploading /home5/andrexw1/public_html/blog/wp-content/backups/a-farr-|-riskier-market-backup-2013-04-20.zip (0.51MB).
19:28:06: Creating zip archive.
19:28:12: Approximately 51% complete.
19:28:18: Approximately 51% complete.
[…]
19:33:05: Approximately 50% complete.
19:33:11: Approximately 50% complete.
19:33:13: Uploading /home5/andrexw1/public_html/blog/wp-content/backups/a-farr-|-riskier-market-backup-2013-04-20.zip (1.07MB).
19:39:12: There has been no backup activity for a long time. Attempting to resume the backup.
19:42:13: Creating SQL backup of your WordPress core.
19:42:42: Creating SQL backup of your WordPress plugins.
19:48:13: There has been no backup activity for a long time. Attempting to resume the backup.
19:49:19: Creating zip archive.
19:49:26: Approximately 66% complete.
19:49:32: Approximately 66% complete.
[…]
19:51:48: Approximately 66% complete.
19:51:55: Approximately 66% complete.
19:52:01: Backup stopped by user.

[Terminated by me]

The first run through works fine, in that I receive the zipped folder in my dropbox and aside from the odd percentages in the log I can’t tell that there is a problem (Note in the log that it uploaded ~500mb). The problem starts where the plugin doesn’t doesn’t seem to realize it is finished with its backup. It appears after it uploads it starts another job. It keeps doing this until I manually intervene. Today when I caught it I had 6 cron jobs going on my server log all ostensibly from the plugin. Even after I stopped the backup via the button on the log, the processes do not stop unless I manually kill them in cpanel. Its also causing my account to be throttled. I’ve never been throttled until recently, coinciding with the recent update to the plugin along with these issues arising.

Here is my server processes before I killed the cron jobs:
17837 /ramdisk/php/54/bin/php5 /home5/andrexw1/public_html/blog/wp-cron.php Today at 17:51
17368 /ramdisk/php/54/bin/php5 /home5/andrexw1/public_html/blog/wp-admin/admin.php Today at 17:51
16186 /ramdisk/php/54/bin/php5 /home5/andrexw1/public_html/blog/wp-cron.php Today at 16:12
7502 /ramdisk/php/54/bin/php5 /home5/andrexw1/public_html/blog/wp-cron.php Today at 17:06
6287 /ramdisk/php/54/bin/php5 /home5/andrexw1/public_html/blog/wp-cron.php Today at 17:49
5926 /ramdisk/php/54/bin/php5 /home5/andrexw1/public_html/blog/wp-cron.php Today at 17:42
6139 /ramdisk/php/54/bin/php5 /home5/andrexw1/public_html/blog/wp-cron.php Today at 16:46

There is also a slew of php errors to go along. Instead of pasting a massive page of text I just zipped up all the logs as txt files in their entirety if that’s more helpful: errors.zip

So actually to update, my directory was already actually exploded (but not because of wpb2db, but because of another plugin), and after I cleared up the misbehaving plugin it worked fine on the first manual backup I prompted.

Although I’m still curious why it mentions the execution time as 120 seconds instead of 900 as the php error?