Best approach to replicate configs in a backup router

Hi everybody,
I'm evaluating which is the best approach to have a backup router that I can use to easily replace the main one in case of any need.
The so-called backup router is a second offline router, same model, with the same configs (or, almost the same... see later); the replacement should be easy, just "swap" the main with the backup one and the network will re-work as before.
Please note that part of this work/approach could be applied for upgrade, adding a value to the work itself (this can be considered a secondary goal).
Now, let me explain a little better. I see two options:

  1. export the configuration and import it in the backup with the native tool. I'm not sure this can be done with different items - even if they are the same model - I remember I have read somewhere that because of little hardware differences you can have problems and brick the router. Besides, even if it was sustainable, it is very risky for major update (read: do not do that :D)
  2. write a shell script to config the most of the router: the packages I use, the network, wifi, hostnames... Of course this approach is absolutely manual and depend on the config you need. Actually I apply the following manual checklist, you may note that some steps may interest everyone (between brakes my peculiar/optional step):
(flashing from windows with: tftp -i 192.168.1.1 PUT firmwareName.img)
(config putty)
change root password
add certificate for certificate access
disable ssh access for root for forcing certificate access
config lan/dhcp: ip space addresses...
config timezone and ntp servers
enabled and config wlans
config local subdomains: uci add_list dhcp.@dnsmasq[0].address=....
add static hostnames
add firewall rules
installing packages
enabling/disabling services
(enabled adblock, added some blocklists)
(install tcpdump-mini and enable report for adblock)
(install and config dns-to-https proxy)

Finally, the question(s):
can I do everything via CLI? I think yes, so.. how: can I copy (before bricking the main router) this or that file(s) into the backup router? Which are this file? I'm seeing the wiki, this wiki page seems to be where to find the info... should I copy all files I found in the /etc/config folder of the main router ( I suppose there are only file of services and config I need and I'm using)? When, what and how do I have to commit (uci? network?)? This way should allow to easily modify the script when you would like to apply a major release that requirements config changes here and there, leaving all other things untouched and usable as is, just copying them.
I know I can find most on the wiki itself (I'm going to see), but if someone could give some tips to speed up my work it will be very very appreciated, hoping that can be useful for more than me.
Thanks, W.

I've got 2 (almost) identical routers, which I use alternating. Each time when an upgrade is available I upgrade the (on that moment) backup router, download the config of the active router using Luci, and upload it to the new router, after which I swap them, and check/adjust configs.
I think I've been following this scheme since Barrier Breaker, (yes, my routers are aging).
Bricking is not an issue. Even if an old, now incompatible, config would render the router unreachable, you can always use failsafe to reset it. And failsafe runs before any config is apllied.

1 Like

if devices are the same (model/brand) you can just export config and import config.

Then you only need to install the same packages.

If they are not the same you can copy over only the specific config files of the services you want to replicate from /etc/config with scp. Since you are on Windows, you can use WinSCP application https://openwrt.org/docs/guide-quick-start/sshadministration#winscp

If you edit the files from Windows it is VERY important to use a text editor that is aware of Unix/Linux text file standards, like Notepad++. http://notepad-plus-plus.org/ If you use the default Windows text editor (i.e. Notepad) it will write in Windows text file standard and then the OpenWrt device won't be able to read it.

thanks to both of you, I had misunderstood something... I remembered that even two routers of the same model can have little differences. I will try.

afaik the only difference between two devices of the same model/brand/revision is in the factory wifi radio calibration data (that lives in its own dedicated partition on flash), but that's not part of the backup, as there is no point in backing that up or restoring it, it's static data that never changes.

There can be small (but important) differences, quite a few devices (more with the new network configuration syntax in 21.02+) encode their MAC addresses in /etc/config/network. If you restore such a backup to a different device from the same model range, you'll effectively close the MAC addresses of the original device - that will work, unless both devices ever come online at the same time...

That's a strange choice imho, what's wrong with reading MAC address on boot from uboot or from factory partition

But still, if you clone the config it's obvious that both devices will have same IP and same wifi network, so I think it's also obvious that it's not a good idea to have them both powered on at the same time already.

Multiple orthogonal reasons:

  • ath9k/ ath10k often cache a patched (fixing MAC addresses, eventually doing endian conversions or decoding proprietary vendor formats (Mikrotik?)) ART partition, e.g. /lib/firmware/ath10k/pre-cal-pci-0000:01:00.0.bin et al
  • devices storing the main device MAC in ASCII (e.g. u-bootenv, nvram, etc.) can't decode the MAC address at boot time (no fixed offset to use for the DTS/ nvmem), here the MAC is extracted once by the firstboot setup scripts and stored in /etc/config/network (e.g. nbg6817, g10, ea8500, ea7500v1, …)
  • the new netifd syntax in 21.02+ likes to hardcode the MAC addresses via config device 'wan_wan_dev'/ config device 'lan_lan1_dev', etc.
1 Like

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