managed automated backups not working

the managed backups do not work, schedules are set but nothing happens, I have provided access to the dashboard

  • Predrag Dubajic
    • Support

    Hey VivaArturo,

    Hope you’re doing well today :slight_smile:

    Can you tell me if you seen any errors or something that will tell you that backups are not working?

    I accessed your site and the backup was in process, I thought it might be showing this for you for some time so I disabled automatic updates and started a manual backup, it seems ok so far and it’s currently on 60% but I’ll leave it to finish to see if everything went well.

    Best regards,

    Predrag

  • VivaArturo
    • The Incredible Code Injector

    there are no backups on the site or in the hub, see log files:

    [Cron][2016-11-17 10:33:04][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-17 18:33:35][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-17 21:08:36][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-17 22:09:37][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-18 04:36:15][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-18 13:24:16][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-18 13:36:20][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-18 14:32:17][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-19 11:48:54][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-21 03:49:00][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-21 05:18:51][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-21 07:33:25][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-22 00:38:33][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-22 10:17:49][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-24 02:04:15][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-24 09:45:10][Warning] Immediate hook misfired, kickstart backup processing

    [Cron][2016-11-24 10:16:45][Warning] Immediate hook misfired, kickstart backup processing

  • Dimitris
    • Support Star

    Hey there VivaArturo,

    hope you’re doing good and don’t mind chiming in! :slight_smile:

    I went ahead and inspected your website, and I have some proposals:

    1. First disable of kind of caching that’s involving in this installation, server-side, plugins, 3rd party services like Cloudflare etc.

    2. Raise the WP_MAX_MEMORY_LIMIT by accessing your server via FTP, editing the wp-config.php file and enter the following line just before the /* That’s all, stop editing! Happy blogging. */ comment

    define('WP_MAX_MEMORY_LIMIT', '512M');

    Reference: https://premium.wpmudev.org/blog/increase-memory-limit/

    3. Again in wp-config.php file, always before the /* That’s all, stop editing! Happy blogging. */ comment

    define('SNAPSHOT_FILESET_CHUNK_SIZE', 100);

    4. Increase maximum execution time. Details can be found here

    https://premium.wpmudev.org/blog/increase-memory-limit/

    http://codex.wordpress.org/Common_WordPress_Errors#Maximum_execution_time_exceeded

    Your hosting provider can also help you set this up in no time.

    Reference: https://premium.wpmudev.org/forums/topic/snapshot-pro-empty-response-during-managed-backups#post-1161095

    Give Managed Backups another shot. If the issue remains, then activate WP_DEBUG in order to get any other relevant error messages. Access your server through FTP, edit the wp-config.php file, find a line like

    define('WP_DEBUG', false);

    and replace it with the following (if the above line doesn’t exist, simply insert next snippet just above the /* That’s all, stop editing! Happy blogging. */ comment)

    // Enable WP_DEBUG mode
    define('WP_DEBUG', true);
    // Enable Debug logging to the /wp-content/debug.log file
    define('WP_DEBUG_LOG', true);
    // Disable display of errors and warnings
    define('WP_DEBUG_DISPLAY', false);
    @ini_set('display_errors', 0);

    Then go ahead and replicate the error by taking another Managed Backup. By doing so, a /wp-content/debug.log file should be created. Simply download it, rename it to debug.txt and attach it here in your next reply.

    Warm regards,

    Dimitris

    PS. Could you please inform me about your hosting provider too and the specific “package” that you’re using from them?

  • VivaArturo
    • The Incredible Code Injector

    Thanks for the reply, I have completed the above and still the same issues occur. All my other remote and local backups work with no issue, which are backupbuddy, blogvault, managewp and one other do not recall the name right now.

    To be honest I do not have time to facilitate your product to work correctly, I have spent a few hours to get this to work and no such luck. I may look at this product again later once it has been improved but till then I will continue to use my other backup services that have no issues.

  • Nahid
    • Tech Support

    Hey VivaArturo !

    Hope you are doing well today!

    Nahid here, following up from our last Live Chat session. Just responding here to state that, I am done with the troubleshooting tests and I was able to replicate the issue in your site. I have updated the internal notes of this ticket with the details of the issue and the results of my troubleshooting tests. The team working on this ticket will take over from here now and will get back to you with updates regarding the further investigation. We really appreciate your patience and consideration regarding this. Thanks!

    Kind regards,

    Nahid

  • Adam Czajczyk
    • Support Gorilla

    Hello VivaArturo

    It seems that the backups are now created fine but the upload to The Hub is the problem. It’s possible that there was a temporary issue with our API that broke that upload but the fact that it’s stuck there for that long (it still is – I checked it) isn’t expected.

    I’ve discussed that with our developers and they need to check it so I have forwarded all the information to them and we’re waiting for their their feedback on this so we’ll update you here as soon as we got to know more.

    Kind regards,

    Adam

  • Konstantinos Xenos
    • Rubber Duck Debugger

    Hi VivaArturo ,

    Could you please create an Admin account for us and send me the details so we can see this through? The FTP still works fine.

    You can send me the information needed privately through our contact form at https://premium.wpmudev.org/contact/#i-have-a-different-question by following this example:

    Subject: "Attn: Konstantinos Xenos"

    - Admin login ( if Multisite please provide Super Admin details ):
    Admin Username:
    Admin Password:
    Login URL:

    - Link back to this thread for reference
    - Any other relevant URLs -or- information regarding the issue that was not included in this thread

    Regards,

    Konstantinos

  • Leonidas
    • Developer

    Hi there VivaArturo ,

    I hope you’re doing well :slight_smile:

    After debugging your issues with created backups not getting uploaded to the Hub, we noticed that the site was blocking those requests to the Hub when dealing with files over a certain size. Now, Snapshot is splitting the backup zips in chunks of 50MB by default and sending those successively to the Hub.

    Since your site’s size is around 40MB, Snapshot tries to send the backup in one go and that request was keep getting blocked due to quite possibly some setup-specific reason.

    What we did, in order for backups to get uploaded seamlessly, was to manually tweak the chunk size backups are getting splitted into, in order to have less “heavy” requests to the Hub. After setting backups to get splitted in 5MB chunks (instead of 50MB chunks) while getting uploaded, we managed to successfully complete scheduled backups by triggering the appropriate cron event. The backup schedule is set to Daily, so we’re going to wait a day until we confirm that scheduled backups work as they should on their own (without us triggering the cron event, that is), but we have no reason to expect that this won’t work, since triggering the cron event managed to produce a properly uploaded backup, in multiple tries.

    It’s worth to mention that the aforementioned manual tweak in the chunk size was made inline in your site’s Snapshot. This means that with the next Snapshot update that change will be lost. But, the next Snapshot version is carrying fundamental changes in how backups are getting uploaded to the Hub in part to help such cases as your own. So even if that tweak will get lost in the next Snapshot update, chances are that the new way of uploading backups to the Hub will manage to solve this issue at your site, once and for all.

    I will personally check tomorrow whether Snapshot completed the next scheduled backup as expected and update this thread with the outcome, in order to keep you posted.

    Best regards,

    Leonidas

  • VivaArturo
    • The Incredible Code Injector

    Thanks for all the great work, do you know when the next update to snapshot will be as I have many other sites that would require this tweak.

    Out of interest how does your backup compare to blogvault and impact on servers resources to back up the sites

  • Predrag Dubajic
    • Support

    Hi VivaArturo,

    We don’t have any ETA on next release at the moment but our devs are working hard on finish it up and everything goes well by the QA team we should see it live fairly soon.

    You can use the version that Leonidas modified and upload it to your other sites as well.

    Out of interest how does your backup compare to blogvault and impact on servers resources to back up the sites

    I’m afraid that we didn’t have any official tests done to compare these two so I can’t really give you any proper information, especially because Snapshot has different tweaks that can be applied that affect backup process and they depend on the server configuration where the backup is being performed.

    Best regards,

    Predrag

  • Leonidas
    • Developer

    Hi there VivaArturo ,

    we took a further look into what is happening on your end and have to report the following:

    It seems like whenever we attempted a manual managed backup (not scheduled that is), the backup was completed and uploaded successfully every time. When we tried triggering scheduled backups, the results were varied.

    With scheduled backups the process was halting most usually on the upload stage and sometimes on the backup creation stage. Facing such issues only with scheduled backups, makes us think that replacing WP-Cron with server cron jobs would help the process a great deal. Server cron jobs are actually recommended by WordPress itself (https://developer.wordpress.org/plugins/cron/hooking-into-the-system-task-scheduler/) since WP-Cron is pretty much traffic-based, but servers crons are bound to run reliably at the interval they’re set.

    So, going forward, I’d recommend you to use the System Task Scheduler in your hosting in order to ensure that scheduled tasks will be checked reliably every 5 minutes. You can follow the instructions from the above link to do so. After doing that, you can reply in this very thread for us to confirm that this will resolve your issues.

    Best regards,

    Leonidas

  • VivaArturo
    • The Incredible Code Injector

    I find it challenging that any other remote back up solution such as blogvault, managewp works with no issue at all. The fact that I have to make adjustments on my server is an issue with your product and makes it unreliable for business

  • Adam Czajczyk
    • Support Gorilla

    Hello VivaArturo

    Thank you for response!

    I checked the site and it seems that this current Cron configuration is not working properly – cron events are not triggered. This is a screenshot of just a few scheduled events that should already be triggered and re-scheduled (taken from your site, from Crontrol plugin events list):

    If you look closer at the dates there, you'll notice that they were scheduled for yesterday while I took this screenshots just a few minutes ago.

    This suggests that the server cron isn't triggering WP cron run. That usually happens either because the configuration on the server must be adjusted (e.g. a cron callout URL) or because "something" is blocking requests.

    Once I requested WP cron URL directly in the browser, those events got triggered and run. Unfortunately, I have no access to your server settings (no cPanel or other management panel) so I can't check it but could you please double-check server cron configuration?

    Maybe you could share a screenshot of its current configuration then?

    Also, please try setting it to every 5 minutes instead of 30 minutes as that's the "base" WP cron schedule period.

    Kind regards,

    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hello VivaArturo

    Thank you for response!

    The cron seems to be set properly now but it still is not working.

    I checked the site and I can still see cron events “stuck” there. They are executed if I manually call the “http://dorys.com.au/wp-cron.php?doing_wp_cron” URL in the browser. Since that works, I assumed that either the “wget” command is not available/executed on a server or something’s blocking request.

    Sometimes it’s not actually allowed and in such cases you need to use curl instead or even executed wp-cron.php via .php. It’s not a big change and doesn’t require any custom code, it’s just a different line in the curl configuration.

    However, I did some more research on your server via FTP and I actually found some additional server logs there and found this:

    203.98.95.7 - - [09/Jun/2019:22:00:01 +1000] "GET /wp-cron.php?doing_wp_cron HTTP/1.0" 403 609 "-" "Wget/1.12 (linux-gnu)"

    This is actually very useful information that says that the cron did execute its command and there was a requests made by Wget 1.12 for the cron URL. So this confirms that cron’s working as expected.

    However, that request return 403 HTTP status code (and it should return 200) which stands for “Forbidden”. This means exactly that either the site or the server (but more likely server directly) has rejected request for that url.

    In other words, server cron is calling URL on your site to execute site’s cron tasks but that’s rejected by site or server.

    One of the common reasons for this in case of CURL/WGET is that server is set to reject “no referrer” or missing or unrecognized user-agent in requests from curl/wget. So I tested this from my end using both CURL and WGET and I could confirm that it does reject it based on user-agent. “Faking” a user-agent string (so kind of “faking” a real browser) seems to solve the issue and both CURL and WGET worked.

    To sum it up, please edit your cron settings on a server again and try replacing the command you’re currently using with this one

    wget -U 'Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0' -q -O - http://dorys.com.au/wp-cron.php?doing_wp_cron >dev/null 2>&1

    That’s exactly the same command that you already got set but it adds a user-agent string to fake some older Mozilla browser. Such requests issued to your server seems to be working fine and returns expected 200 HTTP status so that should do the trick.

    Give it a try please and let’s see if that “unlock” schedule finally.

    Best regards,

    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hi VivaArturo

    Thanks for response!

    I checked logs and site again and it still looks like the events are not really fired up. I must say I’m a bit out of options here, not being able to test that in “real time”.

    Is there a chance you could provide me with cPanel (or other server management panel that you’re using) access so I could be checking logs directly and also modify server CRON settings myself if necessary? That would let me test that better as I’m sure we’re just missing something really “small” here if it comes to cron schedule.

    If that’s possible

    please don’t leave your login details in this ticket.

    Instead, you can send me your details using our contact form https://premium.wpmudev.org/contact/#i-have-a-different-question and the template below:

    Subject: “Attn: Adam Czajczyk

    – Site login URL

    – WordPress admin username

    – WordPress admin password

    – cPanel credentials (host/username/password)

    – Link back to this thread for reference

    Best regards,

    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hi VivaArturo

    I received your message, thanks!

    I did some more checks and with some slight modification of the command I finally got Cron to be executed. I also had it set to send me mail reports so I new exactly whether server actually called cron or not.

    However, while that worked, it was a bit “too intensive” and I also would rather not “stick” with this reports for eternity :slight_smile: So, without touching the “core” of the command, I’ve redirected it back to be “silent” and removed e-mail reports. But let’s leave it for now as this is and see what happens.

    I believe it should be working now but if not, it will mean that the very specific part of the command is blocking it and that’d be actually quite strange, since it’s taken straight from cPanel :slight_smile:

    Anyway: at the current moment the nearest cron event to be exected is

    snapshot_local_backup_check Snapshot_Local_Backups->check_for_local_backups()

    to be executed at 2019-06-11 04:08:35 (22 minutes 37 seconds)

    If you could please check back the site and look at “Tools -> Cron Events” page and see if it has changed in some time after 23 minutes from now (not earlier because earlier it will only change remaining time and that says pretty much nothing).

    If the nearest (top-most) task list changes, we’re on the right path and in such case wait until next scheduled backup and let’s see if it fires up.

    Please keep me informed here.

    Best regards,

    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hello VivaArturo

    unfortunately the backup is still not working, this is a real challenge

    But what about those cron events that I asked about, have you checked if they are rotating now as expected or still not?

    I tried to check it myself but the support access seem to have expired already and the credentials that you shared back in the chat are not valid (they don’t let me in). Could you please enable support access to the site again for me please?

    Let me know here once it’s done as I won’t be automatically notified.

    Best regards,

    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hi VivaArturo

    First of all, I’m sorry for causing confusion. The credentials are working in fact, it was my mistake that I didn’t notice at first. Sorry about that!

    As for the case.

    I checked the site again and… the cron seemed stuck again. There were multiple events missed (or rather waiting to get fired). I made one more slight change (though a bit unexpected, I admit) to the cron command in cPanel and it does seem to by cycling-through on its own now.

    Addiitonally, I made it run every 1 minute, just to “speed testing up”. That shouldn’t cause any issues though.

    Apparently, managed backup was started finally. I checked internal snapshot logs after confirming that cron events are triggered and last log shows backup in progress. Here’s an exception (list messages at the moment I’m writing this, probably it went much further already):

    [Cron][2019-06-11 13:07:43][Info] Parsing self-ping action: [process_backup]
    [Cron][2019-06-11 13:07:43][Info] Prepare to actually process the backup batch
    [Cron][2019-06-11 13:07:43][Info] Processing backup
    [snapshot][2019-06-11 13:07:43][Warning] Unable to perform requested system backup, proceeding with builtin
    [Queue][2019-06-11 13:07:43][Notice] Fetching [30] files as chunk 66

    Basically, it says that it’s fetching files for backup and the process is working (the “Unable to perform…” is irrelevant so can be ignored).

    That said, I realize that entire issue is taking already quite some time but backup also needs some time so let’s give it at least few hours. Could you please check back in 5-7 hours and see on the “Snapshot -> managed backups” page if the backup showed up there?

    Let me know once you check, please.

    Best regards,

    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hello VivaArturo

    I understand that the one that is working is the on we’ve been investigating so far, in this ticket. Is that correct?

    The other ones, even if they’d be on the very same server, would still need to be checked. The thing is that even if the issue “looks” the same (or results in the same errors), it doesn’t necessarily have to be caused by exactly same reasons.

    In such case, I’d also need to be able to check them so I would need full and direct access to all of them. Could you please provide me with that?

    Note: Don’t leave your login details in this ticket.

    Instead, you can send me your details using our contact form https://premium.wpmudev.org/contact/#i-have-a-different-question and the template below:

    Subject: “Attn: Adam Czajczyk

    please follow the format below for each affected site, even if some credentials are the same

    – Site login URL

    – WordPress admin username

    – WordPress admin password

    – FTP credentials (host/username/password)

    – cPanel credentials (host/username/password) <- it’s preferred over FTP, if available

    – Folder path to site in question

    – Link back to this thread for reference

    – Any other relevant urls/info

    Best regards,

    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hello VivaArturo

    I’m very sorry for the delay. I’ve missed the notification of the last e-mail, I sincerely apologize.

    Meanwhile, I had to reach out to our developers again as I wasn’t able to find culprit/solution there. I’ve just asked them again to check it and get back to us as soon as possible.

    Kind regards,

    Adam

  • Leonidas
    • Developer

    Hi there VivaArturo

    We’ve taken an in-depth look at the 2 last sites and have to report the following:

    Firstly, for hydraulicsaustralia.com.au, although the I/O Usage limit there is quite often in the reds (4MB/s) while taking a backup, we were able to produce a successful scheduled backup after inserting the following snippet in wp-config.php:

    define('SNAPSHOT_FORCE_ZIP_LIBRARY', 'pclzip');
    define('SNAPSHOT_FILESET_CHUNK_SIZE', 50);

    which essentially uses an alternative zipping library for the backup zip and uses a smaller chunk size while adding files to that zip. Doing so, managed to produce and upload a scheduled backup seamlessly.

    For clubhousebootcamp.com.au though, no matter what we’ve tried, we couldn’t produce a backup successfully. Again, the I/O Usage is quite often right in the server’s limits and that results in the site grinding to a halt, which has an effect in the running backup. Which essentially means that the site is too big for the server’s resources to handle its backup through Snapshot. You could talk with your hosting provider to increase the I/O Usage limit, so we could try a backup without that restriction.

    Best regards,

    Leonidas

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.