steveroot

I feel your pain, probably too late but;

• I noticed updraft when restoring moves all the existing folders into folder-old (eg images-old, if I remember correctly). Maybe it did the same with the backups? Not sure if they’re on your server or hosted elsewhere
• That it restored your settings, as included in the backup, is logical I think. How would it know which settings you didn’t want restored? I can see that when the backup next runs it would prune the backup destination again. I had another problem, leaving a setting to keep too many backups and filling a disk.. spotted just in time.
• I have also learnt the hard way that if I need to restore from a backup, get all backups from the destination to somewhere else first (eg; all to my laptop).
• For future pain avoidance, and depending on your host, backups of the whole server might be useful. EG: I have a digitalocean VM and have a weekly backups kept for a month, as well as targeted backups of directories/databases more frequently.

I hope the error was an easy recovery/fix.

I came here having found the same problem you have described and looking for something/a setting I mised.

I have customised a style in twenty-twenty-four theme how I like it. Click on that style to make more edits and it has all reverted back to default. Ideally I’d like my customisations to show as a new style option, for now I just have to hope I don’t accidentally reset them ??

@nehaa1509
What size is the image you are trying to upload?
Does it work if you upload a small image in the same format (eg: wordpress logo .jpg if you’re uploading a jpg)
For me, I had to increase the upload size allowed by the web server as well as php. If I remember correctly, One setting was in nginx config file for site, the other was in php.ini

@fallback2
through 25 years of messing with computers, I’ve learnt that software is frustrating. I’ve also learnt some techniques on how to solve problems, let’s see if we can work this out with you.

Step 1) When you try to upload the file, can you see an error in any log files?

For me (detailed answer a few posts back), I could see an error in /var/log/nginx/error.log but you can also look for PHP logs, or apache logs.

Reasons: There are a myriad of steps involved in uploading an image. The error message displayed may not always be helpful and the fundamental problem could be showing in error logs for the the software (wordpress) but also things wordpress is using behind the scenes (nginx/apache, mysql, firewall running on the server, external firewalls)

If you can’t find the logs and haven’t found their location by google searches share here your system setup (OS, web server, etc) and maybe someone will know where they are.
Once you’ve found an error, try googling it and if you’re stuck, post that here too.

Between steps, something else worth trying is working to the simplest possible solution. For me, my issue was images that were over a certain size being stopped first by nginx, and then by PHP, before wordpress had even got to see them.
Try uploading small images.
Try uploading different types (jpg, png, and others)
Try uploading files instead of images
Try sourcing from another server instead of uploading (wordpress has an option to get the image from a url, you can use this one: https://www.rkbb.co.uk/wp-content/uploads/2021/06/hero2.jpg
It’s small enough it should hit any file size limits.

HTH
Steve

So, if you’ve read this far through the comments you’ve probably worked that out the error message is vague.

I solved it by checking the log files. That could be for wordpress, but for me (ubuntu, nginx) I found the cause straight away in the nginx error log at /var/log/nginx/error.log

2021/06/30 15:40:11 [error] 702#702: *2169 client intended to send too large body: 1257288 bytes, client: 1.2.3.4, server: myserver.co.uk, request: “POST /wp-admin/async-upload.php HTTP/1.1”, host: “myserver.co.uk”, referrer: “https://myserver.co.uk/wp-admin/upload.php”

nginx restricts the maximum size of file that can be uploaded so the solution for me was to add a line to my virtual server file (or it could have gone in nginx.conf but that affects every site on my server)

server {
...
        #increased for uploading images to wordpress
        client_max_body_size 10M;
...
}

Set the client_max_body_size to a value appropriate for what you expect to upload. 10M = 10 Megabyte and plenty for what I’m uploading. Don’t make it larger than you need and bad people could try and break your site by uploading very large files in a denial of service type attack.
NB: Other comments here said the upload worked for them when their source was another server, this would bypass the upload stage so I suspect they have the same issue as me.

nginx -t (to test I didnt mess up the config), then restart nginx, try the upload again and it worked fine.

Still not working for you?
After this, the next place to look is PHP error logs. Maybe my file was larger than what PHP allowed and that can be increased.
After this, the next place to look is the graphics program that’s being called to manipulate the image. For me I’d guess that’s PHP calling imagemagick and I’d be hoping the errors arrive in PHPs error log but maybe imagemagick would write it’s own error log. I read here lots of people are using GD for image manipulation, that may also have it’s own error log. Things that might be happening: The image needs too much memory to process, the image is in a format that can’t be processed (maybe allowed by wordpress/php but not allowed to be manipulated by the image software default).

*If I had the skill and time, I’d look to contribute code to generate a more useful error messages for this, alas I don’t so hopefully someone find this answer useful.

If you can’t recreate it, feel free to ask me to try again and let me know where any log/debug output will be.