How to really make backups (by script) ?

Hello all,

for years I am looking for a method to backup a running configuration. Of course one might think to simply use (winbox) File → Backup. But the problem is, you cannot restore this backup on another hardware of same type. Basically all devices with MAC adresses fail to configure correctly, which means you may even lock yourself out of the box if restoring.
Another problem: the backup is not human readable, which means you cannot search it for any keywords.

So one might think, well use “/export somescript.rsc” then. But trying that once reveals that you cannot “restore” (i.e. import) this script either because it fails on every script-line already configured in the default-config of a newly unboxed router.

Now, this leaves you with - nothing! So my question: has anyone ever found a solution how to backup a router config and restore it on another one of equal type without having to rework the backup-file/script by hand? I mean, I missed something, or not? Because I find this pretty unbelievable …

Regards

Use export. Upload export.rsc. Do /system reset-configuration no-defaults=yes run-after-reset=export.rsc.

This will reset device without default values and import the new settings.

Hello,

This topic has been documented MANY times. But, yes, you CAN restore a binary backup of one device to another of SAME model. But:

  • Make sure they’re both running the same version of OS
  • Reset each interface’s MAC address.

Voilà!

As far as running and storing backups, that too has been documented. Some use scripts with FTP, some email their backups. Choose what you want to use and look it up.


Cheers,

Yes, it has been documented many times, but we’re still waiting for proper solution. Even though restoring binary backup to other devices will probably work, it’s officially not supported. But even it it was, it’s not very practical, because sometimes I’d just like to see what’s inside, but unreadable binary file is useless for this. Export is nice and readable, but it doesn’t export everything, at least certificates and users are missing, so it’s not perfect either.

Don’t forget to backup certificates and keys, if you have VPN server/client definitions. Also files if you have a custom hotspot. While the hotspot problem is not big, the restore will fail if the certificates are not there, so you should upload and import them in the “run-after-reset” script
While at that be careful to edit the export file to remove mac addresses if you are cloning (they appear in bridges and virtual devices)

Hm, all the answers do not look like a real solution to the problem. Surely the best is by script, as it is the only human-readable option. Nevertheless certificates and users/passwords are completely missing. For me the users/passwords are not a big deal, but certificates are. So something simple as a working, readable backup is really not existing. I really do wonder how we all manage to use this stuff in a professional environment without being able to do working backups …
We must all be madman :slight_smile:

How do you do that in one go at restore?

Copy and past your MAC reset script in the export.rsc file.

You mean you would export a script from the to-be-backuped router, then edit it manually to enter all the MAC addresses on the box? Have fun doing that for some hundred boxes. And in the end this leaves you with a script that does neither restore certificates nor user/passwords.
You call that a backup?

It seems that the MAC address is programmed in the hardware which appears when you erase the restored MAC.

It is config backup and the setting you mention a for the same device or if you want to duplicste a device.

You could add a mini-script at the end of the rsc file which resets all mac-addresses and sets the bridges to auto-mac.
This goes into the scheduler, to be run at startup.
The script will delete itself from scheduler once finished.

Like this:

/system scheduler
add name=resetmac on-event=":foreach k in=[/interface ethernet find where (name~\"sfp\" || name~\"ether\")] do={\r\
    \n[interface ethernet reset-mac-address \$k]\r\
    \n}\r\
    \n:foreach k in=[/interface bridge find where (name~\"bridge\")] do={\r\
    \n[interface bridge set \$k auto-mac=yes]\r\
    \n\r\
    \n/system scheduler remove resetmac\r\
    \n" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup

Forgive my ignorance, to my knowledge the backup/restore procedure does not restore the old mac addresses but in fact leaves you with completely broken network setup, as all the ip addresses once bound to a device point to now “unknown device” exactly because the MACs of the new box are not equal to the ones the backup was made on. Effectively the situation can only be returned from brick-state by login via serial (if available) or by reset-procedure (to factory reset), both not ending up in a duplicate of the originally backup’ed box.
The more wireless interfaces a box has the more useless it gets after restore. The config ends up being filled with “unknown” stuff (IP, DHCP, firewall, wireless settings lost completely).
We tried for years to make anything useful out of the backup files, but in the end gave it up this year. Now we export a script, which at least has the wireless settings in readable form, so we can restore them manually if necessary.
We are working for 20 years in linux development and have yet to see another company with such a high benefit from the community and such a low understanding in open strategies (besides AVM maybe).
It is obvious that even a simple readable backup is actively denied to the user that owns the box. What a shame …

The binary backup will let you restore a perfect/complete copy of the config of the original router (A) on the new router(B). It will work. But DO reset the MACs, either manually or through a script as suggested.

Obviously, it should NOT be done if the original router (A) is still running as you’ll have duplicates all over the place. Yes, officialy, it’s not supported, but unofficialy, it works as long as you restore all MAC addresses. Do it while router (B) is off the network. Then, swap routers during your maintenance window.

Granted, it may not suit everybody’s needs, but that’s how it is. Imagine a complete backup in readable format falling into “hostile” hands. That would force a password change sprint in record time, provided you do it before the other with your password changes your routers. Arrrggh!!!

If you want to see everything for analysis, then restore to a standalone router and analyse away.

Cheers,

No, just no! :slight_smile: That’s an argument against being careless with readable backup, but not against the possibility to have it.

True!

Sent from my cell phone. Sorry for the errors.

I always hated the fact that people could easily steal you scripts with passwords in them. (dyndns)