[SOLVED] Unable to restore configuration

I'm having some issues trying to restore a configuration that I backed up prior to updating OpenWrt on my NETGEAR R7800. Whenever I try to upload the backup file in LuCI the page just refreshes and nothing happens. I've looked in both the system log and kernel log to see if there are clues as to why it's failing, but there's nothing there.

Here's a short list of what I've tried so far:

  • Creating a new backup file to test if it works (it didn't)
  • Tried a different web browser (I've tried both Firefox and Chrome)
  • Reflash OpenWrt through TFTP recovery (I'm running OpenWrt SNAPSHOT r6727)

Can you extract the "backup" and confirm that the files are there? It is, as I recall, a gzip-compressed tar file. If your OS is unwilling to extract it, try a copy and renaming it with an extension of tar.gz or .tgz

Which version are you updating from?

There currently is a bug in LuCI, leading to data corruption in uploaded binary data. This is likely causing your problems.

As a work around, you can transfer your backup archive using scp, then restore it using sysupgrade --restore-backup /tmp/backup.tar.gz

@jeff I've looked inside the extracted files and it's all there. What I found out is that it doesn't matter which version I'm upgrading from, because restoring from a backup created on the same snapshot also doesn't work.

@jow Thanks, it worked! I'm used to having LuCI automatically reboot the router after a restore, but that doesn't happen when performing a restore with sysupgrade. Is this expected behaviour?

Yes, this is expected. LuCI simply reboots the board after config restoration to ensure that the changes are fully effective. Sysupgrade does not do it automatically to give the user a chance to still do changes after the restore.

1 Like

Do you know if this data-corruption bug is fixed in the LUCI repo? I cannot find an open issue for it in their bugtracker. If you don't know if it's fixed, do you maybe know when the bug first occured? It seems to be able to evade my efforts to find anything about it anywhere.


ok, I was afraid you were gonna say that because I hoped this might just refer to the sysupgrade part.
Sysupgrade works for me, but restoring a backup still doesn't. I tested this yesterday with openwrt master 751746c736bbda828ff1add002a0419a3b883e63 (22.04.2018).
What can I do to debug this? Using the network console doesn't really help in finding a hint.

  • Is scp + sysupgrade --restore-backup working?
  • Edit /usr/lib/lua/luci/controller/admin/system.lua, comment out (with two leading dashes):
    -- os.execute("tar -C / -xzf %q >/dev/null 2>&1" % archive_tmp)
    -- luci.sys.reboot()
  • Check if md5sum /tmp/restore.tar.gz matches the MD5 sum of the backup tar.gz you upload to the router.

I'm running the very latest master snapshot (r6744), and LuCI restoration doesn't work for me either, but scp + sysupgrade --restore-backup works.

I've compared the MD5 sums and they're the same.

Then the issue seems unrelated to LuCI. Can you reproduce the same problem by running tar -C / -xzf /tmp/backup.tar.gz; reboot ?

I reset the router to defaults before I uploaded my config backup through the LuCI interface. After running tar -C / -xzf restore.tar.gz; reboot my config was successfully restored.

I don't understand why it is unrelated to LuCI if the manual way works?

Anyways, I tested the tasks you gave me with the same results as @huaracheguarache:

  1. scp + sysupgrade: works
  2. md5sums: match
  3. tar -C / -xzf restore.tar.gz; reboot: works (you wrote "backup.tar.gz" but the filename has to be "restore.tar.gz", as @huaracheguarache correctly posted.

So, how can we continue to debug this behaviour?

1 Like


Thanks, that solved the issue for me!

Works for me, too. Thank you @jow and @huaracheguarache!

This topic was automatically closed 6 days after the last reply. New replies are no longer allowed.