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 …
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.
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
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?
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.
7 years gone now and still no solution to something simple as a really complete backup. In the meantime everyone should have noticed that the common case of restoring a backup is to use a new type of router and not the original type one - a hardware upgrade. So the binary backup is really useless.
That's not true. If it's same router, use Backup. Simple. We can quibble if it's best practice or just being anal, to save a :export so you have one to review as well as backup file.
So the "backup my router" is well-covered IMO. e.g. if hardware failed and replaced the router => restore the backup (and return the bad router), or you FUBUR the config and want to get back to a baseline state from backup.
Now, it's when you want to "migrate" to a new router or add new one etc etc, or doing more ISP/OEM deployment things where config file scheme is needed.
The latter does happen, but necro-posting ain't going to fix it. The config file is "lossy" so it does take more knowledge to understand how to use it. For example, it does not have accounts or certificates in the :export... But depending on use-case... this may be exactly what's needed or not. The config file is flexible, but it certainly not the "source of truth" for the full configuration, only a template of how to create a new (or same router minus user/certs).
The only confusing part is thinking that the "config file" is some persistent state of the router, it's not. It's a script that can be used as-is or adapted to re-create the networking configuration of a device, but not the "whole device" like auth things like user/certs (although you can add those on your own, why this scheme is flexible).
Certainly the scheme could be improved, but too many folks depend on how it works today. Which is why it's same state today as 7 years ago. Perhaps V8 might offer new schemes, IDK. There is certainly room for improvement, but the current scheme is at least explainable and consistent. The latter being more important than the former.
I guess you still have not understood the point of it. And it makes sense to talk again after 7 years. Because it should be very obvious that some of the routers existing 7 years ago and still working will be dead somewhen and you will not be able to revive their function through a backup you took, because it does not restore on a todays box with todays routeros. And that is a problem. My company is in this business since 1995 and I am really fed up with people and their short-sightedness. You think we survived because we looked forward only 5 years periods at a time?
The truth is that Mikrotik does well know and this was in my judging one of the reasons for the CHR - because it does not die out like all other hardware routers which are always dead including their setups/configs.
I guess I'm saying, what are you asking for specifically. A "complete backup solution" is vague, and there are third party ones that get good review if you have a lot of routers.
I get RouterOS is not the most user friendly platform. And got plenty of complaints about MikroTik decisions in places. Including that there is not some canonical representation of the config state - other than backup of a single router that is not transparent. So I'm with you in principal, but the practical reality in middle of V7 release cycle changing fundamental things like how the config system works is just not possible, without breaking things for a lot of folks.
Generic posting "backup sucks" isn't very actionable for anyone. MikroTik do a have a feature request system, or you can post your idea on what could be better on forum. But just because it's 7 years, I'm not sure what that has to do with that a backup from last decade should actually restore.
Now you're better of restoring the same version it was taken from... But as a general matter internal to restoring a backup is crossfig which should migrate the config in backup to the current version. If that didn't work, well ,that is a bug worth reporting.
