Snapshot Scheduled Backups Not Working (Even when I 'run now')

Greetings!

I've had snapshot installed for a few months now, and I cannot get the scheduled backups to show as complete, even when I hit 'run now'. This includes the WPMU Cloud Managed Backups.

  • Mark
    • Site Builder, Child of Zeus

    I went in and deactivated most of the Network Active plugins. (I kept domain mapping and WPMU on). Is there a way to test the scheduled jobs that is quicker than hitting 'run now' and waiting several hours to see if it ever completes?

  • Mark
    • Site Builder, Child of Zeus

    So, I also noticed that the scheduled run in Defender isn't working. It's also stuck on a much earlier time. Could it be that WP-Cron isn't functioning properly?

    That said, I've been working on researching a move to a new hosting environment. I think I'm going to start rebuilding my network on SiteGround. I'll do a fresh install and then use All in One Migration to move over a site at a time without most of the plugins. I'll start with making sure I have Snapshot working properly on the network before I start importing all the sites.

  • Mark
    • Site Builder, Child of Zeus

    UPDATE: A short while back, I was looking into a hosting move. I had SiteGround import my network over from BlueHost, but I haven't actually moved my clients over yet. So there's a copy of the network just sitting there. I decided to alter my hosts file so I could access the SiteGround version and use it like a staging/development server.

    So I deleted all the sites, deleted all the plugins and themes except for the WPMU dashboard and SnapShot.

    It still isn't running scheduled backups properly. I even re-installed Snapshot from scratch in the process. It did the usual first manual backup just fine. But the scheduled backup refuses to run.

    Kasia Swiderska If I grant support access there, will you be able to access it, even though my domain DNS isn't pointed to it?

  • Kasia Swiderska
    • Support nomad

    Hello Mark,

    I'm extremely sorry for delay on my end - due to family emergency I had to take few days off.

    It did the usual first manual backup just fine. But the scheduled backup refuses to run.

    That would be possible if you relay on WP Cron - that cron only works when there is traffic on site. When there is none it wont fire. Try this tutorial https://www.siteground.com/tutorials/wordpress/setup-cron-job.htm

    Kasia Swiderska If I grant support access there, will you be able to access it, even though my domain DNS isn't pointed to it?

    We can try. Thats the same domain? You would need to give me IP of your staging site and enable access there and I will add record to my /etc/hosts/

    kind regards,
    Kasia

  • Mark
    • Site Builder, Child of Zeus

    Kasia Swiderska Thank you so much for the reply! I'm sorry that you had a family emergency. I do hope everything is good.

    My staging server IP is: 109.199.109.118

    I went in and disabled WP-Cron and setup a cron job for every 30 minutes in my cPanel account. So I guess now I can assume that any backups will begin to run within 30 minutes of their scheduled time regardless of traffic. Is that correct?

    I did the above on both the staging server and the live server.

    Then, I deleted any previously scheduled jobs and will re-add them to Snapshot. I'll give it some time (30 minutes or more) and then check again.

    Thank you!

  • Mark
    • Site Builder, Child of Zeus

    FIXED!

    Thank you so much. Setting up cron in c-panel seems to have fixed it in both server environments.

    My error email was received because I had set it up in the wrong cpanel account (another server account I have with that same host).

  • Mark
    • Site Builder, Child of Zeus

    NOT fixed yet... I spoke too soon.

    So, visiting the wp-cron.php/?doing_wp_cron page seemed to trigger the job with no issues, so I waited a while and came back to check... the jobs still aren't running automatically.

  • Kasia Swiderska
    • Support nomad

    Hello Mark,

    I think I may have found the root of the problem. My wp-config.php file never had the closing

    That is not error. It should not have it - closing ?> are source of many problems because it is very easy to add after them space or enter (white characters) that will cause error "Headers already send".

    So on SiteGround it works with real Cron job, but on BlueHost it's not working at all? I found this article and it looks like BlueHost might need different configuration https://phpmatters.com/how-to-fix-up-wp-cron-php-issue/ (it uses wget command). Let me know if this will work on BlueHost.

    kind regards,
    Kasia

  • Mark
    • Site Builder, Child of Zeus

    Okay, it's still not working properly on either server. I assumed it needed the PHP closing tag based on what it said in the article from siteground about setting up the cron job.

    First, you need to disable the file to be hit every time someone loads your pages. To do this, open the wp-config.php file in your main WordPress folder and add this line at the end, before the closing ?> tag:

    So I'll go back in and take out that closing tag.

    It seems like when I visit the link to activate wp-cron.php it successfully triggers the jobs, but that's the only way I've been able to get them to trigger.

    I'm going in to try the wget command now.

  • Mark
    • Site Builder, Child of Zeus

    Okay, so I decided to try to get some help from SiteGround support as well. They went in and looked around but said it was beyond their responsibility.

    So I started digging through some Wordpress.org support articles to see if anyone has had similar issues. Even with all WPMU plugins deleted in my development server, WP Crontrol still shows everything is hanging up.

    So then I got to thinking... in WP-Crontrol, the job at the top of my list is a Jetpack job, but I've had Jetpack disabled for a while now, so I thought maybe I needed to re-install it, re-connect it, and see if it works out any bubbles in the cron system. When I tried to connect, I received the following error from Jetpack:

    Error Details: The Jetpack server could not communicate with your site's XML-RPC URL. If you have the W3 Total Cache plugin installed, deactivate W3 Total Cache, try to Connect to WordPress.com again, reactivate W3 Total Cache, then clear W3 Total Cache's cache.

    SCREENSHOT

  • Mark
    • Site Builder, Child of Zeus

    Well, I was using WP Super-Cache because it seemed to be simpler to configure that alongside hummingbird, but I have used WP All In One Migration to import full sites... one of which had W3 Total Cache working on it. So then both caching plugins were active for a while. I think they set conflicts that may be the cause of all my issues. Is there any way to totally clear my system of all caching effects after all the plugins have been disabled and deleted?

  • Mark
    • Site Builder, Child of Zeus

    I had SiteGround support install the package needed for wget and it seems to be triggering my cron jobs now. I just installed Snapshot back into that instance and it did the first backup. I'll know in about 30 minutes if it will continue to follow the schedule I set for backups.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.