Backup not completing (tried 3.6.3 beta)

That’s interesting as I host with Siteground with no problems at all. See what your max is on the max_execution_time and try bumping it up a bit more? Also, depending on your plan, that memory_limit but actually be an invalid limit and be overwritten by the hard limit set by Siteground. I thought they maxed out at 512 for GrowBig but I’m not positive on that. You might also check that.

Just to test – when you run a files-only backup, it also never completes? How about if you excluded the wp-content folder and then tried to run the files-only backup? (Just for testing!) If you haven’t tried that already, try that and see what happens, okay?

Let me know!
Kat

I confirmed with SG — max for max_execution_limit and memory_limit are as I have them set, and those are both valid (120 and 768M).

I went in and set up a files-only backup. Ran that manually — Included Size column icons spinning, backup icon still spinning. I stopped it.

Did a files only backup with wp-content excluded, ran that manually — Included Size column icons spinning, backup icon still spinning.

Removed wp-content from the excluded list and started that backup again — I’ll let it run for a bit and see if it completes.

(All this done with 3.6.3 beta.)

Update: 32 minutes later, still running. I’m going to stop it.

Update 2: I ran the one without wp-content and it’s 41 minutes later and that one’s still running, too — gonna stop it.

• This reply was modified 7 years, 11 months ago by bdd. Reason: Updated

Hello @bws-online

Can I have the ticket ID in your User Area related to this issue? I am part of the senior technical support team at SiteGround and it would be easier for me to investigate the issue if I have a test case:)

Hi Ivan. I spoke to SG live chat support on this, so I don’t have a ticket for it — is that what you’re talking about? Would you like me to submit a support ticket via SG for this? I can PM you on Slack if you’d like any details there. Thanks!

Yes, please submit a support ticket and let me know the ticket ID:)

Done. 2019850

Ivan and Kat — I took a copy of my site and set it up on a subdomain and ran a manual all files and DB backup, and it worked.

When I look at the BackUpWordPress support info, it seems that the dev version is able to calculate the size of the site (but on the main version, that seems to be where it’s getting stuck with all the spinning icons).

Thanks.

Hey there @bdd – interesting information there. I’d sure love to try and get more information on the spinning site. I’m on Siteground as well and haven’t had any problems – I even have a test site set up there for testing the plugin specifically and no issues. I wonder what the difference is between the two being able to figure the size of the site. ??

If Siteground (and so amazing that @ivanyordanov-1 showed up to offer assistance) sees anything upon looking at the live site I’d love to hear it. Our working theory is that the spinning and calculating and never-completing backups are due to a combination of factors, including the fact that seeing the file size is very memory-intensive, and also including factors at the server level. I’m wondering if looking at the php.info for each site would show any additional discrepancies between them, since they’re on the same server and therefore shouldn’t really have different php settings, at least usually.

Please keep me informed!
Kat

I’ll keep you posted. Anything in particular you’d want to know about from phpinfo()? There are differences between the two sites, but I don’t know what’s what (and am not comfortable posting all the details here).

Support said they fixed it. Here was the detailed technical response — does it mean something to you?

Our developers have designed and developed special Apache module called mod_dtimeout. It allows as the adjust the server settings and limits dynamically in accordance with the applications specifics. Its settings can be adjusted with .htaccess rules, but before this Apache logs need to be examined. The module checks for the presence of DynamicTimeout environment variable. If it exists, the module checks its value and if it is a digit, the module then use that value as the value for the Timeout. For your convenience I did that and fixed the problem with sgtest application.

They’re testing it out now on my live site.

• This reply was modified 7 years, 11 months ago by bdd.

Hello @bws-online @katmoody

Seems the issue is caused by symlinks. The backup functionality is breaking even on a default, empty installation if you have a symlink pointing to the current folder e.g:

lrwxrwxrwx 1 user user 1 Dec 15 09:14 symlink -> ./

This leads to a loop, that can be seen by stracing the admin-ajax.php process once you start the backup and eventually the process gets killed because a Timeout limitation, max_execution_time, etc. The backup process is completing for less than a minute on the same default WP installation when the symlinks are gone.

@katmoody , do you think that there is a way to deal with such symlinks in the plugin’s code?

Thanks for the follow-up Ivan. Kat, I’ll await your response on this. Thanks.

@ivanyordanov-1 – I definitely think we can find a way to work around those – I’m listing this in GitHub for the developers to weigh in on and so we can work on it as soon as possible. I’m not sure how long it will take with the holidays coming up so soon, but we’ll definitely dig into it.

So when you fixed those symlinks that allowed the plugin to work with @bdd’s site, then? I’m wondering if this is behind a couple memory-type errors we’ve been seeing on other sites.

If there’s any additional information any of you guys can add please don’t hesitate to let me know!

Thank you!
Kat

Hey Ivan – @ivanyordanov-1 – I’m opening a GitHub issue for this if you are able to weigh in with any further information for the developers. It’s here: https://github.com/humanmade/backupwordpress/issues/1150

Can you also confirm whether the Apache module that @bdd referenced above was part of the solution? Or did fixing the symlinks fix the issue completely for them? And did you put in absolute paths to fix those, then?

Thanks,
Kat

Hi. Unfortunately, the only fix I found was to remove the symlinks . But I have brought them back because they are needed in order for @bws-online ‘s SSL to be working as expected.

I suppose that the issue is caused by the fact that the symlink is pointing to the current directory:

symlink -> ./

which creates a loop. Maybe excluding the symlinks from the backup would be a good idea?