[Snapshot Pro] Backups fail with "Error 429 Too Many Requests"

When creating a backup with Snapshot Pro, I'm getting an error - "Error 429 Too Many Requests".
We have tried enabling debug logging along with Snapshot backtrace but a debug.log file didn't generate, Snapshot log file didn't show anything relevant to the error (attached in ticket notes).
All other plugins were disabled, the default theme was activated but the backup still didn't work.

  • Kasia Swiderska
    • Support nomad

    Hello Dominique,

    I'm sorry that Snapshot is not working correctly on your site.

    I have performed more tests but without success :slight_frown: - so I have escalated this to our Second Line Support Developers to check why it is happening on your site.
    They will investigate this problem and let you know about their findings.

    kind regards,

  • Konstantinos Xenos
    • Rubber Duck Debugger

    Hi Dominique ,

    The 429 error by Varnish usually means that the server is using a php worker limiter. Unfortunately we can't be sure what that limit is as we don't have that kind of access to the server.

    Could you please contact your hosting provider informing them about the 429 error ( it's quite common with WordPress in general and various plugins as well ) and ask them what the current limit is and if they could raise it for you to see if that would fix the issue you're facing?

    Unfortunately I can't help more at this point without that information as the 429 suggest a hard limiter that we can't raise ourselves to make further tests.


    • Dominique
      • Recruit

      Hi Konstantinos, thanks for your reply.

      What bugs me out is that backups run fine when using UpdraftPlus. How can it be that Snapshot Pro is not able to create a backup, while another plugin runs fine? You write that there's nothing to do about it for you, but when another plugin does it's job fine, I'm not fully convinced that you can't this is the case. I hope you understand this!

      I still think Snapshot Pro is not in the same league as UpdraftPlus when it comes to reliability. WPMUDEV should take these things very seriously, because reliability is top priority when it comes to backups. Isn't it?

      About contacting the hosting party: I'm not directly in contact with the hosting party for this website, since it's a site of a client, not ourselves. It's being hosted by Amazon, apparently. I've got no clue how to reach them.

    • Dominique
      • Recruit

      Hi Kasia,

      This website is hosted at a Dutch hosting party names 'mijndomein.nl'. Are you sure that I need to login at Amazon for this?

      In the mean time I was able to retrieve login details for their account at mijndomein, and I've disabled Varnish caching. I can't see any settings for a 'PHP worker limit' in their interface. Could it be raised using code in wp-config or the htaccess?

      Also some good news: the backup process seems to work when it's started through cron (so initialized by the server), it only fails when it's started manually.

  • Konstantinos Xenos
    • Rubber Duck Debugger

    Hi Dominique ,

    I see that Varnish is still enabled. Preferably it should be disabled while we're working on the ticket.

    More on that point is that it should be fully disabled on the wp-admin side of WordPress. Only the front-end should have any kind of cache and this is why it seems that it's breaking at the moment.

    I've also run 3 managed backups that somewhat confirm this as a proof of concept. You can see them in your Hub as well.

    The first ( since it was not yet cached ) finished fine ( 90mb ).
    The 2nd got broken by varnish as most probably the cache started bumping in ( 25mb broken backup ).
    The 3rd was stuck on creation progress.

    Those three can be seen in your Hub, but your Admin will show that there are no managed backups at all. This indicates that the wp-admin is actually cached and it shouldn't for no reason at all.

    If you disable Varnish completely then we could see if Snapshots/Managed will be working properly to make a more rounded bug report so our Developers can see this through inspecting Snapshot/Varnish together. In any case though the Admin should not have a caching system either way.

    As for the Varnish limits being raised that depends on how everything is set up on the server and what the limiter actually is. There's a difference if it's a rate limiter vs a php worker limiter etc. So that is something to be handled by any sysadmin that is taking care of that system. We can't possibly know how the setup is as you can understand to help on that end.


Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.