LuCI->Backup does not work!

I have been trying to do a configuration files from Lucy->Backup and it is not working neither with OpenWrt v24.10.8 nor v24.10.7.

Does anyone realized that it is not possible a Backup from Lucy?.

Shall it be this incidence corrected in the next OpenWrt v24.10.9?.

Define "doesn't work" ?

You have not provided any details...

  • how it fails? What errors / symptoms? (are there temporary files created in /tmp or elsewhere?)
  • what router ?
  • what is the expected size of the backup? (does it fit into router's RAM?)

It seems to have been fixed in the "next release" , it's working fine on my 25.12.5.

But some more info details of your setup, would not be a bad thing.

It has been working all the time for most users...

It is very simple: Lucy->backup does not backup any configuration file!

As soon as you want to to a Backup from Lucy, you only get a tar.gz file with size of 1KB and whose content is this: /etc/uci-defaults

However when you do a correct Backup from Lucy, you will get a tar.gz file with size of 7KB and whose content should be this:

  • /etc/config/dhcp
  • /etc/config/dropbear
  • /etc/config/firewall
  • /etc/config/fstab
  • /etc/config/luci
  • /etc/config/network
  • /etc/config/rpcd
  • /etc/config/system
  • /etc/config/uhttpd
  • /etc/config/wireless
  • /etc/dropbear/dropbear_ed25519_host_key
  • /etc/dropbear/dropbear_rsa_host_key
  • /etc/group
  • /etc/hosts
  • /etc/inittab
  • /etc/luci-uploads/.placeholder
  • /etc/nftables.d/10-custom-filter-chains.nft
  • /etc/nftables.d/README
  • /etc/opkg/keys/d310c6f2833e97f7
  • /etc/passwd
  • /etc/profile
  • /etc/profile.d/busybox-history-file.sh
  • /etc/rc.local
  • /etc/shadow
  • /etc/shells
  • /etc/shinit
  • /etc/sysctl.conf
  • /etc/uhttpd.crt
  • /etc/uhttpd.key

I have noticed this error in several wireless routers: Huawei HG556a, Observa Telecom VH4032N, and Arcadyan VRV9510KWAC23. I have not checked more routers because I have no more, I suspect there must be more affected routers.

just a silly question (I understand you are using "luci") but if you run these commands does it work or not:

sysupgrade -b /tmp/backup.tar.gz
sysupgrade -l

I only use LuCI, because it is the easiest for me. I was asking to do a Backup from Luci, not from the command shell.

Here the main problem is that you can not use Luci->Backup from the GUI due to it is not working correctly the backup and It's been dragging on for several versions and the bug has not corrected yet!.

Bingo, probably you get the reason, however you will agree with me that we are in the 2026 year and this problem, bug, error or like you want to name it, it continues nowadays. It is shameful!.

Totally understand you want to fix the LuCI path, not work around it with the CLI β€” that's the actual bug we need OpenWrt to fix. The reason I'm suggesting the sysupgrade -b / sysupgrade -l test isn't as an alternative workflow, but purely as a diagnostic step.

LuCI's backup button doesn't have its own backup logic: it just calls the same underlying sysupgrade backup routine (which in turn reads the file list from /etc/sysupgrade.conf plus the built-in defaults) and streams the resulting tar.gz back through the browser. So there are really only two places this can be breaking:

  1. The low-level file list itself is broken/empty on these devices (in which case LuCI is just faithfully reporting a broken backup, and the fix belongs in the base backup logic / config).
  2. The low-level list and archive are fine, and LuCI's wrapper (the cbi/controller code that calls it and serves the download) is the one dropping data.

Running sysupgrade -l and sysupgrade -b /tmp/backup.tar.gz from the shell tells us in 10 seconds which of the two it is β€” no GUI workaround intended, just isolating where the regression actually lives before anyone spends time patching the wrong layer. If the CLI backup also comes back at ~1KB with only uci-defaults, that's strong evidence the bug isn't LuCI-specific at all (which would actually make it easier to track down and more likely to get picked up, since it'd affect sysupgrade -b on its own too, not just the web UI). If the CLI backup is correct and full-sized, that narrows it down squarely to LuCI's backup controller and saves everyone from chasing it in the wrong codebase.

Would you be able to run those two commands on one of the affected routers (HG556a, VH4032N, or VRV9510KWAC23) and post the output?

Fair enough, and I get the frustration β€” a long-standing bug like this shouldn't still be around. That said, I'd push back a little on calling it universal: LuCI backup works correctly for me on my own routers, so whatever's going on here doesn't seem to hit every device/build. That's actually why the diagnostic matters rather than dismissing it as "well-known, everyone knows about it" β€” if it were a blanket regression in LuCI itself, it'd be failing for a lot more people than the handful reporting it in this thread.

Without having your specific router in hand, there's not much I can conclude from guessing β€” I'd really need the output of sysupgrade -l and sysupgrade -b /tmp/backup.tar.gz on one of the affected devices to see whether the low-level backup is also broken, or whether it's isolated to LuCI's wrapper on those particular builds/targets. That's the difference between "OpenWrt has a systemic backup bug" and "these specific firmware images/configs have a broken sysupgrade.conf or file list."

Happy to help track it down further once we have that output.


The file in question should be this one if I'm not mistaken:

https://github.com/openwrt/luci/blob/master/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js

You were asked to run a test from the command shell to verify the backup command actually works on your system.

That file should not even be backup-up...
Is something referencing it?
Do you have any special uci-defaults stuff built into the image?
Or any non-default symlinks set for /etc something ?

Just trying to understand, what in your config would make it to affect several of your routers, but does not affect other users.