Automate ".backup" files?
-
- Posts: 15
- Joined: Wed Jan 31, 2018 10:45 pm
Is there a way to use Unimus to backup the ".backup" Mikrotik files? We want to use those for Winbox restore for a router failure (ie: take new hardware off the shelf and upload the .backup file to it).
Hi,
.backup files in MikroTik are meant to be used only on the router they were taken from.
They contain router-specific things like MAC addresses, RouterOS license, MikroTik cloud identifier, etc.
So when restoring to another device, you need to use the export file (which is what Unimus backs up).
If you restore a .backup file to a different device than it was taken from, bad things will happen.
.backup files are also binary - so change detection and change notifications would not work.
For these reasons, we don't support retrieving .backup files from MikroTik, and we backup RouterOS using "/export".
.backup files in MikroTik are meant to be used only on the router they were taken from.
They contain router-specific things like MAC addresses, RouterOS license, MikroTik cloud identifier, etc.
So when restoring to another device, you need to use the export file (which is what Unimus backs up).
If you restore a .backup file to a different device than it was taken from, bad things will happen.
.backup files are also binary - so change detection and change notifications would not work.
For these reasons, we don't support retrieving .backup files from MikroTik, and we backup RouterOS using "/export".
-
- Posts: 15
- Joined: Wed Jan 31, 2018 10:45 pm
Interesting... Our network admin is working on a written process for replacing an edge router with an identical replacement. We have found that trying to CLI paste the Unimus backup file (or any export) does not work. It does not place the write commands in the correct order. We find that it writes a config line that references something else that has not been written yet so that line errors out.
What are people doing when they need to create a quick but exact copy of a config when replacing a failed router?
What are people doing when they need to create a quick but exact copy of a config when replacing a failed router?
Usually process to restore a MikroTik is fairly simple:
1) Get the backup from Unimus
2) Get new MikroTik, connect to it using Winbox
3) Make sure the new MikroTik is the same RouterOS version as old MikroTik
4) Issue "/system reset-configuration no-default=yes"
5) After MikroTik reboots, connect using MAC-Winbox
6) Open a console and paste the contents of the backup file from Unimus
Step 3 and 4 are very important, since you need an empty MikroTik ("no-default=yes") of the same version to properly import the configuration.
1) Get the backup from Unimus
2) Get new MikroTik, connect to it using Winbox
3) Make sure the new MikroTik is the same RouterOS version as old MikroTik
4) Issue "/system reset-configuration no-default=yes"
5) After MikroTik reboots, connect using MAC-Winbox
6) Open a console and paste the contents of the backup file from Unimus
Step 3 and 4 are very important, since you need an empty MikroTik ("no-default=yes") of the same version to properly import the configuration.
So what if the backup is not from the same firmware (packages) version?
How do I get the new device to be configured to match the version of the backup?
I presume Unimus uses "/export verbose" so that we can restore this onto an "empty" router without any defaults?
Thanks!
Yahel.
How do I get the new device to be configured to match the version of the backup?
I presume Unimus uses "/export verbose" so that we can restore this onto an "empty" router without any defaults?
Thanks!
Yahel.
This issue would be the same with backup.
For example, after bridging and VLANs was changed in RouterOS, if you attempted to recover a backup from a previous version, it would brick the router. (you would have to factory default, or NetInstall)
Unimus uses "/export compact", since "verbose" exports MAC addresses, and a ton of other things you don't want in your backups.
If you are restoring to a much newer version (like after bridging and VLAN changes), you have to adjust the configuration before applying it to the router.
This is not a MikroTik specific issue tho.
Same issue exists if you are restoring between very different versions of IOS, or ProVision (OS that runs on HP ProCurve - now ArubaOS), or any of the other vendors.
For example, after bridging and VLANs was changed in RouterOS, if you attempted to recover a backup from a previous version, it would brick the router. (you would have to factory default, or NetInstall)
Unimus uses "/export compact", since "verbose" exports MAC addresses, and a ton of other things you don't want in your backups.
If you are restoring to a much newer version (like after bridging and VLAN changes), you have to adjust the configuration before applying it to the router.
This is not a MikroTik specific issue tho.
Same issue exists if you are restoring between very different versions of IOS, or ProVision (OS that runs on HP ProCurve - now ArubaOS), or any of the other vendors.
So to clarify - does "/export compact" sufficient for restoring an "empty" router (without any defaults)?
Also - how do I get a particular packages version to match the backup --- is it available/possible, or is there no avoiding the manual changes to the restore if some major version changes exists?
Thanks!
Also - how do I get a particular packages version to match the backup --- is it available/possible, or is there no avoiding the manual changes to the restore if some major version changes exists?
Thanks!
Yes, "/export compact" is everything you need to fully restore a MikroTik.
The steps here describe what needs to be done:
viewtopic.php?p=1412#p1412
All packages need to be the same version.
You can always downgrade the router to the original version if it's on a newer version.
Manual changes are only required if something major changes in configuration of RouterOS between versions.
(like with the mentioned bridge/VLAN changes recently)
Understood...
It appears that "/export compact" does not include some parameters of value (probably intentional, but a bummer nonetheless) -
For example:
No password.
No certificates (and hence fail in configurations dependent upon these).
Also - it would fail when configuration is dependent upon or includes specific MAC addresses which are no longer valid (new hardware).
===============
On the flip side, I find that using the binary backups of Mikrotik work quite well when restored to different hardware (replacement router of the same model), as long as:
1. It only has wired interfaces (fails on wireless interfaces).
2. It has exactly the same firmware.
The beauty of this restore is that it restores everything, certificates and passwords included...
It also restores the MAC addresses of the old router, which could be a problem, but easy to fix later with a single MAC-reset command (in the rare cases where we care).
Thoughts?
Thanks!
It appears that "/export compact" does not include some parameters of value (probably intentional, but a bummer nonetheless) -
For example:
No password.
No certificates (and hence fail in configurations dependent upon these).
Also - it would fail when configuration is dependent upon or includes specific MAC addresses which are no longer valid (new hardware).
===============
On the flip side, I find that using the binary backups of Mikrotik work quite well when restored to different hardware (replacement router of the same model), as long as:
1. It only has wired interfaces (fails on wireless interfaces).
2. It has exactly the same firmware.
The beauty of this restore is that it restores everything, certificates and passwords included...
It also restores the MAC addresses of the old router, which could be a problem, but easy to fix later with a single MAC-reset command (in the rare cases where we care).
Thoughts?
Thanks!
Yes, router admin login credentials (under "/user") and certificates are the ONLY data not exported by "/export".
As you have guessed, this is for security reasons.
That is normal, you would run into this issue with any other vendor as well.
(Cisco, Juniper, HP, etc.)
This is simply NOT officially supported by MikroTik, so it is not guaranteed they will not break that at any time.yahel wrote: ↑Thu Nov 15, 2018 6:31 amOn the flip side, I find that using the binary backups of Mikrotik work quite well when restored to different hardware (replacement router of the same model), as long as:
1. It only has wired interfaces (fails on wireless interfaces).
2. It has exactly the same firmware.
The beauty of this restore is that it restores everything, certificates and passwords included...
It also restores the MAC addresses of the old router, which could be a problem, but easy to fix later with a single MAC-reset command (in the rare cases where we care).
You are not restoring just MACs, its also MikroTik Cloud identifier, RouterOS license, and many other things that are meant to be router-unique.
As this is not supported by MikroTik, and as you noted it does NOT work in many cases, for us to take this as a backup in Unimus would be quite a bad practice.
"/export" simply always works - you can move from an 1100AHx4 to a CCR1036 without any issues for example.
Also export is text and backups are binary - which as mentioned previously would cause many functions of Unimus not to work.
(Config Search, Change notifications, config diffs, etc.)
So for these reasons we chose to do "/export" instead of backup
![Smile :)](./images/smilies/icon_e_smile.gif)