John-Pierre Cornelissen

No of course not. That exactly proofs my point.
Updraft never deletes zip files of incomplete backups.
Why are they not automatically deleted?
Why are they kept forever?
They are useless, so delete them
It doesn’t make sense to do that manually like you said.

Right, that’s what I said. But it doesn’t make sense. If I set Updraft to keep 2 backups, it should delete all backups that are older, regardless if the backup was completed or not.

Hello,

I understand you replied to that earlier question, but didn’t understand what you mean with the term ‘merge request’. It’s not ‘the’ answer to the question I had.

Anyway, I have been monitoring the backups now for a few weeks. The .part files are deleted now, so that’s good, but there is still a remaining issue left.

What I see is that if a backup fails, it partially fails. Meaning, there is are .zip files for the plugins and themes folder while the others are .part files. The .part files are deleted the next day but the zip files are never deleted.

I have configured Updraft to keep two daily backups, so today I have backup files for 22 and 21 november. Previous backups should have been deleted. The backup of 20 november is deleted, but the partial backup files of the failing backup on 19 and 18 november (plugin and themes zip) are still there.

Hi, just to let you know that the issue seems to be fixed by excluding the reservation page from cache.

Following questions remains though:

1. Is there a difference in the free and premium version that could affect caching (the issue doesn’t happen on sites with the free version)?
2. Why would it throw error 403 on /wp-admin/admin-ajax.php and not on /picker.js?
3. Any other ideas why this could happen on this specific site and not on the others?

Thanks
JP

I have excluded that page from caching to see how it goes.

However, I have 9 websites with this booking plugin and all these sites also have that caching plugin with the exact same settings. Only this site has this issue and only since a few weeks.

The only other difference is that this particular website is the only one that uses the premium version (sorry, didn’t think about that before). We have max reservations and max people specified, but if we get this error we get it for all dates, and clearing the cache fixes it.

Is there a difference in the free and premium version that could be affected by caching?

Why would it throw error 403 on /wp-admin/admin-ajax.php and not on /picker.js?

Any other ideas why this could happen on this specific site and not on the others?

Ok, thank you.

Mmm that’s weird, I just tried to replace Easy WP SMTP with FluentSMTP, but it doesn’t offer me the option to import the Easy settings like it did when I created this ticket. Is there a certain condition that should be met?

Here is a video: https://somup.com/cZXXqfJoy6

Here is an article on your website that it can import from Easy WP SMTP.
https://fluentsmtp.com/articles/fluentsmtp-2-0/#easily-switch-from-wp-mail-smtp–easy-wp-smtp

Thanks, it has been solved by now. The O365 made 2 mistakes:

1. They first creates the client ID/secret/token from their admin account.
2. After that they made it from a shared mailbox but they disabled authentication for that shared mailbox because actual users don’t need to login there because it’s shared. Turns out shared is ok, but authentication is needed.

Hi, what do you mean with ‘fix Merge Request’?

This ticket is about the .part files not being deleted according to schedule.

Thanks, that’s a quick fix. Awesome.

Which item in the release notes contains te fix? None of the mentioned tweaks seem to be related to this issue.

JP

I enabled the email option and today I received an email saying that the backup wasn’t successful. I checked the backup folder and it indeed contains a lot of .part files from last nights backup.

I see something strange in the log though. Here it says successfully uploaded, but for the plugin there is a .zip and two .part files.

1076.013 (2) Recording as successfully uploaded: backup_2024-11-01-0208_PALUX_Bedrijfskeukens_13382cb59871-plugins.zip
1076.014 (2) Deleting zip manifest (backup_2024-11-01-0208_PALUX_Bedrijfskeukens_13382cb59871-plugins.zip.list.tmp)

And at the end

4579.678 (10) [Updraftplus] The backup is being aborted for a repeated failure to progress.
4579.679 (10) An error condition has occurred for the first time during this job

If I search through the log for ‘fail’ and ‘error’, only these last two lines are found, so where are the ‘repeated failures’ or how can I find them?

Here is a Google Drive link to the log file (website name redacted for security).

Thanks
JP

PS: the subject line of the email with the backup result could be made clearer. It says “Backup created”, even though it has failed.

• This reply was modified 3 weeks, 3 days ago by John-Pierre Cornelissen.

Thanks Nick, I didn’t check if the errors were from the same day as the .part files. There were so many of these files that the disk space was full and caused issues, so I deleted all of them to get things going again. There are no warnings in the dashboard about failed backups though.

I could imagine that it’s caused by a slow or overloaded server. Know issue and a website owner who thinks the website is fast enough ??

Is there any reason why the .part files are not deleted with the same schedule as the succeeded backup files? If they are incomplete, then it doesn’t make much sense to keep them forever?

Thanks
JP

Is there no support here?

Still disagree. If a rule works without WPFC and stops working with WPFC, then it’s definitely WPFC that breaks it.

Problem solved with a change in the redirect rule. This one works correctly with and without WPFC.

RewriteEngine on
RewriteCond %{HTTP_HOST} !^(www\.)?brasseria\.nl [NC]
RewriteRule ^(.*)$ https://www.brasseria.nl/$1 [L,R=301,NC]

• This reply was modified 3 weeks, 5 days ago by John-Pierre Cornelissen.