Backup Restore Failed Maximum request body size 16777216 exceeded

I’m running home assistant container 2026.7.4 and I’m trying to restore a backup. When I choose my tar file I get the error “Maximum request body size 16777216 exceeded” and the upload seems to stop.
There doesn’t seem to be a relevent issue open on github

How do I restore my home assistant?

(This has worked previously)

Same here. Trying to upload a HA OS 2026.7.4 backup to restore on newly setup HA Container 2026.7.4

Do you have more than 16mb of space on your drive (The number the error mentions).

If 2 of you are seeing this, is there an issue in HA core?
¯\(ツ)/¯ Sounds like you are looking for…

Does anyone have the answer to the question part of my post? A CLI tool in the docker image maybe? A python script which will interact directly with an api? Placing the backup in a certain folder so it get’s processed?

I recall seeing something like this that was a limit of nginx.

nginx? In the container image? It’s pure speculation.

What programs are you opening your tar file with? Is it 32bit, or nobbled and outdated? Can you wander over with Samba, and open the file up from another computer?

I refuse to believe you’re not aware backups are encrypted by default now. If that is indeed the case, you’re adorable.

Also, where did I mention samba? What in the LLM made you think I was using samba?

Kisses! :slight_smile: Some deliberately do not encrypt their backups, specifically to avoid the sorry situation you find yourself in, so they can recover files using third party tools. I’m guessing that this experience may make you consider doing the same. No LLMs here - I’m not that naive. I go back to the days when 16Mb was a lot of memory, pre-AI era, and CLI was the way to go, no GUI or web browsers whatsoever. Days of pkarc and floppies, where every bit counted. When even 640k memory was king.

In your haste to respond, you appear to have overlooked my question - what tools are you using to access your backup, and are they unable to cope with large*(ish)* files?

Using Samba to access your tar file across a network, or even move it as you have asked, using alternate tools that are known to be able to open those sized files is just one troubleshooting option you may wish to consider as part of the process of elimination to narrow down the issue. Yes, there may be problems with the OS, the restore routines, your tar file may be corrupt, or the problem may be unique to your hardware and software configuration. The lack of detail you have offered so far would probably make it difficult to narrow down. Just trying to help…

The fact some people don’t want to encrypt their backups is irrelevant. It is a default. It is also a view I align with.

The fact you want me to copy around a file, which I already have makes little sense to me. I have the file. Surely with your vast experience with computers, which you want to share with me, would suggest copying a file I have from a samba share I don’t use to be needless.

Some good news for everyone however, I have the previous three backups stored in two separate locations. I have tried restoring with them all. I concede it is possible they could all be corrupt.

This was in my first post but you did not comprehend it. But to put it into simple, easy to understand terms which you will not require for you are experienced. I am using the homeassistant provided workflow to restore a backup. The tool that is throwing the error. Where it did not before. You can tell me it might be a bug if it makes you feel like you are being helpful.

My question still is: in the absense of this one provided workflow actually working. How can I restore a backup?

Additionally. How can I verify if an encrypted backup is corrupt using official means?

Use a third party tool! Move your file to a known stable environment (that’s where Samba comes in) where the underlying platform is not suspect, and use a tool you know works.

Obviously the method you are using doesn’t work, otherwise we wouldn’t be here, back and forth, so try and narrow down the three options you may be facing, either the file you are accessing is corrupted, or the software you are using is faulty, or the method you are using does not follow the original coder’s documentation and expectations. There may be others too, but experience, and many years of patience with handholding, unable to peer over your shoulders and guess, taking your posts at face value, shows that the process of elimination, crossing off what works and what doesn’t, eventually finds the problem, and is the most efficient method to arrive at the solution.

Yes you want to get your data back. Desperately. Anxiously. Accept whatever ideas are offered to help you, document what you observe closely, and hope for clarity and a fix. If using an alternative way of bypassing your problem until a solution can be found, won’t you at least try it? Yes, as a byproduct the approved method may need fixing, and that will be a benefit to others reading along that have the problem you do, and the programmers that may need to change their software.

Usually there are return codes in the error logs. If not, there should be. Feel free to post them (suitably formatted </> for readability please). The developers will need those as well. Third party tools will also tell you if your file is intact, and whether we need to investigate further if there may be another cause if they are accessible, but internally corrupted.

I feel your frustration clearly. We’ve all been there, our expectations let down. As a suggestion: Remember we are volunteers here, offering free advice, with varying levels of experience and expertise. Throwing shade about may not be wise, and may cause people that might have offered suggestions to just click away - your loss. You are welcome to also report your problem in GitHub (with accurate detail) where it will be looked at by the programmers. Be a little less aggressive and you may find a little spoon of honey goes further than a faceful of pepper.

I was going to suggest trying this, AFTER you had checked the files were intact, you listed any error codes, your platform was stable, and nothing corrupted.

It makes a lot of assumptions that everything is in place and functioning and I strongly recommend you eliminate them as potential sources of error FIRST, but may suit your requirements. You may have to dig out the the underlying concepts and do the hard work yourself.

Ironically, a third party tool.

You may find useful hints here as well that I’m sure you have studied hard, but others may not have stumbled over, in addition to the important ones already suggested by @Sir_Goodenough

I used a third party tool. Thank you for suggesting a solution.

Just to add I hit this too - I don’t think it takes much for a backup to be over 16mb

Somehow we are left guessing as there wasn’t enough clues to narrow down this problem, nor even what tool was eventually used by the original poster.. Love to see feedback that helps others too, not just jump in, demand help, grab a fix and disappear. What I offered was a workaround someone coded, not a solution. Their fix had issues too that needed a further workaround - see Possible securetar version problem? · Issue #1 · acaranta/home_assistant_backup_decryption · GitHub and may break again if the underlying algorithms and code is amended by the devs.
The original problem may still exist, biting others, and may still need more information to narrow down the underlying issue.

A backup solution that has a non-functional restore process is fundamentally broken. This is mission critical. Please help to get it fixed, rather than use a workaround.

Nothing reported in GitHub? This not relevant from months ago? Next: real backup fixtures, schema variants, and restore runbook output · Issue #1 · brandonwise/ha-restore-drill · GitHub

  1. Please post the appropriate information as recommended by @Sir_Goodenough in the third post to help yourself and others that may strike the same issue, clearly document it, and get the devs to code a long term solution. Reporting issues - Home Assistant

  2. Have you installed the latest August updates? Does it fail with those too? Exactly the same way?

  3. What web browser are you using to access your HomeAssistant backup and restore pages? Version number too please. What platform are you running it on?

  4. How big is your database? The actual one on your server, not backup copy.

  5. How big is your tar backup file, in compressed format? How big is it uncompressed?

  6. How much free space do you have on your server?

  7. What sized storage and what type is it?

There was an issue reported at Uploading backup TAR archive not possible when file is above 16MB - 'Maximum request body size 16777216 exceeded.' · Issue #177999 · home-assistant/core · GitHub but it was closed as ‘not a bug’.

The problem is it looks like Home Assistant is set up to reject any upload over 16mb long - which includes when you try to upload a backup. My backup was 75mb - I wouldn’t have considered that to be huge - I have a handful of sensors, running for a year or two so far.

I fixed it myself by editing Home Assistant to increase the limit. I have mine in a Docker instance:

sudo docker cp homeassistant:/usr/src/homeassistant/homeassistant/components/http/server.py server.py  # download file
# edit server.py, change  MAX_CLIENT_SIZE: Final = 1024**2 * 16 
# to  MAX_CLIENT_SIZE: Final = 1024**2 * 128 
sudo docker cp server.py homeassistant:/usr/src/homeassistant/homeassistant/components/http/server.py # upload file

Yes, doesn’t look like a feature request to me.

Thanks for another workaround. Frustratingly, I can see the GitHub report was treated as a feature request, not a bug. Maybe there wasn’t enough info for the dev to recognise it as a critical bug amongst the hundreds of other reports?

You say your backup was 75Mb. How much free space? How much compression? See what I mean, they need more info.

Can we collect the information to narrow down the bug even further so it can be fixed, not closed and ignored?

If the issue is space, the inbuilt restore routines should be checking and giving feedback. If the routines are failing, the error codes that are logged should be clear enough to identify the issue.

Please collect the data and post it. Thanks.

(Edit: I’ve gone back and modified my earlier post to make it seven questions)

@kid-pro-kuo and @Gibbo3771 may wish to respond here too, giving a broader picture, so it becomes clear what is the same and what is different.

I will chime in, and answer the questions (even though they’ve been answered above)..

I am migrating a docker-based HA instance (2026.05.01) from one machine to another. To do that, I did a manual backup on MachineA and downloaded it to then restore on MachineB.

I copied my docker compose over to MachineB and spun it up (so MachineB is now at 2026.08.01). I got the HomeAssistant setup screen about creating your smart home, or offering to restore from a backup. Hey, great, I have a backup I just made 3 minutes ago, let’s upload that… Then I get a message about uploads over 16 megabytes are not allowed. The restore process did not start, there were no error codes (again, because the restore process did not start)

The target machine has 30 gigabytes of disk space free. My tar file is 67 megabytes.

However, since 67 megabytes is more than the 16 megabyte upload size HomeAssistant comes configured with, per gfwilliams above, I grabbed server.py from my docker contianer, made the change to max_client_size to set it to 128 megabyte max, copied that back into the container, restarted the container, and I was then able to upload my backup tar file successfully. No other changes were made, etc; just changing 16 megabyte max upload size to 128 megabyte max upload size.

This is not a browser issue; it won’t matter if you use Chrome, IE, Edge, Firefox, Brave, Vivladi, Netscape, links, curl, wget, etc.. This is a “Home Assistant comes with a not-sane configuration for restoring backups via web upload, because backups of any reasonable system will be more than the maximum uploadable file size of 16 megabytes”… Why that 16 megabyte limit exists, I don’t know, maybe to stop some other issue? But, it blocks any sort of reasonable sized backup file from being used via HomeAssistant’s own built-in functions during setup of a new instance.

It’s not an issue with available disk space, processing power, ram, etc on the HomeAssistant instance. It’s a plain “HomeAssistant will not allow a file to be uploaded over 16 megabytes, and that given size is too small for even modest backup tar files, thus HomeAssistant’s ability to restore from backup during a first-launch is broken with even modest backup tar files”

I’ll be charitable and say “Maybe it’s different if you use HAOS…”

To sum up:

  • Migrating docker-based HA from MachineA (2026.05.01) to MachineB (2026.08.01)
  • MachineA’s entire home assistant data directory is 256 megabytes in size.. home-assistant_v2.db is 128 megabytes in size.
  • Did a manual backup on MachineA using HomeAssistant’s manual backup feature, downloaded the tar file (which was about 67 megabytes), tried to use the “Restore From Backup” on MachineB during the first run “Let’s set everything up” screen
  • For reference, my automatic backups are of a similar size, in the 65-70 megabyte range… I just wanted an up-to-the-minute backup
  • When trying to upload the tar file to MachineB, it told me the file was over 16 megabytes, so I could not upload it.
  • MachineB has 30 gigabytes of space free, one / partition, etc… IE, this is not a partition issue, especially given below…
  • I did the fix up-thread from gfwilliams, changing MAX_CLIENT_SIZE in server.py from 16 megabytes to 128 megabytes, restarted the container, and was able to successfully upload my tar file
  • the restore went off smoothly
  • if you really care, I’m using Brave. As noted, though, this is not a browser limitation/issue. This is a “HomeAssistant does not have sane defaults for typical scenarios” issue.