I have lots of hotspots to set up on wAPac

Why does backup/restore never work

They are both on the same version, I have even put an 'accept all' at the top of the configuration before doing the backup.

I guess it's because interfaces don't match up, but that's really bad

last time I had to do this I seem to remember the certificate private keys also got messed up ::(

can't you make this easier MT? I'm an hour into restoring a working config from one wapAc to another and I have still not succeeded

this is turning into a really bad day for me now

I restore the config - from same type of device running same firmware. It has hotspot enabled.

when the new device boots, wlan is down, and ethernet I guess is blocking everything. I know it has an IP from my other router, but I can't get into it.

so I guess the best I can do is /export cfg then /import ?

I dread to think what would happen if I had to get a stand-in person to figure all this out if a customer's box needed replacing. I have a 9-interface rb1100ahx4 dude edition at a very important site. Would none of the interfaces work/match up with the configuration if that was restored to a replacement identical-model unit as well?

Define "same type of device"? Backup was never intended to work between different HW models.
You can restore backup reliably only on exactly the same HW model.

Define "same type of device"? Backup was never intended to work between different HW models.
You can restore backup reliably only on exactly the same HW model.

wAPac to wAPac. They look the same to me but who knows what goes on inside!

I guess the backup has the interface configs tied to mac addresses :-/

It would be better if the backup at least was consistent with ether1 = ether1, ether2 = ether 2 etc,

anyway I have managed it now with /exported config, and I've written down my steps for future reference.

To be fair, I didn't know about /export and it's pretty useful. It's nice that I can edit in a text editor. I thought I would be able to do that with a 'do not encrypt' backup, but discovered that's not the case (unencrypted backup is still an obfuscated pile of hex)

@mrz, point me to one example when restoring configuration from identical devices works 100%, I've never met such situation. There are always empty bridges, different eth order, lack of assignemt of IP to interfaces, wrong SSID etc.
Frankly I thought it's intended to be such way, never expected to do broken hw replace with simple restore config...
Not to mention that other vendors gears doesn't have this problem what helps running bussiness but not on Mikrotik. It's better to do step by step from old device, if it's available. But when old HW is broken, fired or drowned in water problem is more complicated.

Did you report any of these problems to support?

Same issue with my rb2011-uias's. Tried to duplicate the one in production to my lab.
After restore rb started into secondary partition. Tried again with no success and gave up.

But when old HW is broken, fired or drowned in water problem is more complicated.

Exactly. I starting taking backups of my customer's Mikrotik boxes some time ago. I was also hit with the RB450G capacitor failures ~5 or 7 years ago..
but.. these backups are basically useless aren't they.
If the restored backup locks you out of the router then you are totally screwed and there is no 'in-between' such as 'restore backup but don't activate immediately'

in fact, if we could have a 'restore backup but do not activate until config confirmed', and allow editing of settings before making live, then that would fix it. Or allow console access or something, but that's not there on most of the MT routers.

Define "same type of device"? Backup was never intended to work between different HW models.
You can restore backup reliably only on exactly the same HW model.

I've used the word 'identical' a few times here. I even ensured the routerOS was the same version too. Identical model hardware - from the outside! I don't know if you use a slightly different chip revision on the WLAN or ethernet though do I.

Like I said, did anyone reported these problems to support?

Like I said, did anyone reported these problems to support?

Only now, with this thread to you. Hopefully you can put it on the agenda

使用导出到文件。然后使用终端和过去的交会tions one at at time. It’s usually a OS version mismatch issue. I find pasting in terminal much more reliable but I don’t suggest importing the whole file at once. Make sure your autocomplete in terminal is set if not the paste command will fail use the mouse, right click past option not cntrl + v

The backup file I find should only be restored on the device it was made on and only when it’s the same OS version for restore.

Like I said, did anyone reported these problems to support?

Only now, with this thread to you. Hopefully you can put it on the agenda

Write to support, specify what configuration you had on the router when you created backup (preferably generate supout file) then restore backup and generate another supout, so that we can see what exactly is not restored correctly.

使用导出到文件。然后使用终端和过去的交会tions one at at time. I find pasting in terminal much more reliable but I don’t suggest importing the whole file at once.

So backup is useless when restoring to IDENTICAL hardware like e.g 2011, but export and step by step import is a workaround and is not conveniant especially with distant acces :/

The backup file I find should only be restored on the device it was made on and only when it’s the same OS version for restore.

Why only on the exact same device? other vendors are less restrictive, and You can EASILY restore backup from one to another what makes job a LOT faster and nicer.

I'm not sure writing to support will work; backup is not intended to be used between identical devices, it works only with the SAME device.
From RB2011 A to RB2011B -> won't work.
Don't use backup to duplicate configs over devices, use export/import instead.

Well, restore from A to B can work IF you reset the MAC address of ALL physical interfaces. Also, if you have an address in a bridge, make sure that it's pointing to a real MAC, not the one in the backup that doesn't exist anymore.

Cheers

Sent from Tapatalk

Regardless of whatever the official stance is from Mikrotik, some sort of useful backup/restore which doesn't require a plain-text config export, and/or have vital pieces missing, would be a very useful feature to help in disaster recovery.

Instead, it seems like the best option is to keep a pre-configured device on hand, but that means every configuration change needs to be repeated to the spare device. For example. I have been through quite a few of the higher performance routers, just because.. well just because I want to try them. So the site that has the rb1100-ahx4, also has a decommissioned Rb3011, so I could get that back online, configure it all, and document it as a spare, in case I die or something and the company needs somebody to fix/swap the router.

It would be really nice if the Backups that I have been doing on all my routers were actually useful though and could be used for the purpose for which I naturally assumed they would be.

Like I said, did anyone reported these problems to support?

Only now, with this thread to you. Hopefully you can put it on the agenda

Write to support, specify what configuration you had on the router when you created backup (preferably generate supout file) then restore backup and generate another supout, so that we can see what exactly is not restored correctly.

If I restore backup and it locks me out of the router how can I generate an spout from the second router?

You have enough info, and you are MT support, so as far as I can tell, you know about this issue now, if you didn't already! Hopefully my input and others here has been useful and you will take it onboard and improve the product for yours and my success going forwards.

Regardless of whatever the official stance is from Mikrotik, some sort of useful backup/restore which doesn't require a plain-text config export, and/or have vital pieces missing, would be a very useful feature to help in disaster recovery.

Well I agree with you there, there should be a simpler way of copying a configuration from one device to another. Both for devices that are exactly the same, and also for devices that are only similar. I have been through that a couple of times....
We don't need to copy the config of a CCR1072 on a HEX, of course. But for similar devices that one would buy as a replacement or backup of an existing device, it would be nice to have.

The method of using /export and pasting the output in the new device sort of works, but requires a lot of manual action (which requires expertise), and is quite error-prone.
也许应该有一个“导入一个佛的方法reign /export" where the device itself does the actions like "omitting MAC addresses", "handle minor differences like an extra interface or missing interface", etc.
Right now an import simply stops at the first minor error and this makes it unusable, forcing the use of copy/paste with careful circumvention of unwanted fields like MAC address.
Also, the /export does not contain the full router config (certificates, keys, users/passwords).

The solution should cover two common scenarios:
1. the user wants to build a second device configured the same way as their original (to keep as a spare or to replace their outdated model with a new one)
2. the user (likely some WiSP or project) wants to initially set all devices to some base configuration that they then further refine for the specific use

At the very leat, we should be able to import a backup into another device of same model and RoS/bootloader version. Certificates, users and all.

At the very leat, we should be able to import a backup into another device of same model and RoS/bootloader version. Certificates, users and all.

Like I said, you can do that provided you reset the MACs.

Not ideal, I agree, but workable. For the MACs, a simple "cleanup" script should make it that much faster and less error prone.

Sent from Tapatalk

At the very leat, we should be able to import a backup into another device of same model and RoS/bootloader version. Certificates, users and all.

Like I said, you can do that provided you reset the MACs.

Not ideal, I agree, but workable. For the MACs, a simple "cleanup" script should make it that much faster and less error prone.

Sent from Tapatalk

Official Mikrotik orientation is "do not do this". At least, where when I looked it up.

But, now, I got interested. What do You mean by "reset the MAC"? Say I restore backup of device A on device B. By "reset" the MAC I would be using the MAC of device A on B? Or I would be restoring the MAC of device B to its original value, after it being overwritten by the MAC of device A on the backup?

I totaly agree with you; it is "Official" policy, but... There's always a but

If you restore a binary backup of A on B (provided both are the same model. And I would STRONGLY advise to have them of same ROS and Firmware also), this should work. Thing is, you'll have the MACs of A on B. I hope I'm clear so far.

So...
Once this is done, you would do the following:and so on, depending on model.

The only thing I would recommend is that you check the WLAN interfaces' MACs. There is no reset-mac command for those, and since I haven't tested it on a wireless model, I can't give you the exact behavior. Check also your bridges if you activated "Admin MAC address" since this will also no longer be valid. Basicaly, check all other virtual interfaces (bridges, tunnels, etc.) with MACs, just to be on the safe side.

As all things, you'll notice that there can be some differences between "official" and "real life". This is one of them .

Regards,

At the very leat, we should be able to import a backup into another device of same model and RoS/bootloader version. Certificates, users and all.

I think that is working. But in practice it is not enough. E.g. I have 2 installs of CCR1009-8G-1S-1S+ which when broken is no longer available and would have
to be replaced by CCR1009-7G-1C-1S+ for example. But I could also consider to use RB1100AHx4 instead. It should be easier to transfer configuration between
such devices of similar number of ports but not identical.

W.r.t. the reset-mac-address posted by AlainCasault: It would be nicer when there was an option for "restore" to "skip MAC address" to they are left to
the current default value, or for bridge admin addresses they are again set to a value unique and within the range of the local device. Probably this option
should be set by default when the backup is restored on a different device than where it was made.

At the very leat, we should be able to import a backup into another device of same model and RoS/bootloader version. Certificates, users and all.

I think that is working. But in practice it is not enough. E.g. I have 2 installs of CCR1009-8G-1S-1S+ which when broken is no longer available and would have
to be replaced by CCR1009-7G-1C-1S+ for example. But I could also consider to use RB1100AHx4 instead. It should be easier to transfer configuration between
such devices of similar number of ports but not identical.

W.r.t. the reset-mac-address posted by AlainCasault: It would be nicer when there was an option for "restore" to "skip MAC address" to they are left to
the current default value, or for bridge admin addresses they are again set to a value unique and within the range of the local device. Probably this option
should be set by default when the backup is restored on a different device than where it was made.

This is exactly what im sure everyone needs, way to 100% clone devices, while ignoring/reseting MAC adresses.
Im also irritated that i need to spent 1 + hour setting new router for customer every time, while i could just restore my master configuration and just change few things...

At the very leat, we should be able to import a backup into another device of same model and RoS/bootloader version. Certificates, users and all.

I think that is working. But in practice it is not enough. E.g. I have 2 installs of CCR1009-8G-1S-1S+ which when broken is no longer available and would have
to be replaced by CCR1009-7G-1C-1S+ for example. But I could also consider to use RB1100AHx4 instead. It should be easier to transfer configuration between
such devices of similar number of ports but not identical.

W.r.t. the reset-mac-address posted by AlainCasault: It would be nicer when there was an option for "restore" to "skip MAC address" to they are left to
the current default value, or for bridge admin addresses they are again set to a value unique and within the range of the local device. Probably this option
should be set by default when the backup is restored on a different device than where it was made.

This is exactly what im sure everyone needs, way to 100% clone devices, while ignoring/reseting MAC adresses.
Im also irritated that i need to spent 1 + hour setting new router for customer every time, while i could just restore my master configuration and just change few things...

I hear you! I developed a way of speeding things up using Excel. The first tab shows things like IP addresses and various other parameters that change from router to router while the second tab is the final configuration. Just cut and paste and voilà!

The advantage of being lazy


Sent from my tablet with Tapatalk. Sorry for my typos.

I totaly agree with you; it is "Official" policy, but... There's always a but

If you restore a binary backup of A on B (provided both are the same model. And I would STRONGLY advise to have them of same ROS and Firmware also), this should work. Thing is, you'll have the MACs of A on B. I hope I'm clear so far.

So...
Once this is done, you would do the following:

Code:Select all

/interface ethernet reset-mac-address ether1 reset-mac-address ether2 ...

and so on, depending on model.

The only thing I would recommend is that you check the WLAN interfaces' MACs. There is no reset-mac command for those, and since I haven't tested it on a wireless model, I can't give you the exact behavior. Check also your bridges if you activated "Admin MAC address" since this will also no longer be valid. Basicaly, check all other virtual interfaces (bridges, tunnels, etc.) with MACs, just to be on the safe side.

As all things, you'll notice that there can be some differences between "official" and "real life". This is one of them .

Regards,

That is really great! I'll keep this one written somewhere - thanks!

This is exactly what im sure everyone needs, way to 100% clone devices, while ignoring/reseting MAC adresses.
Im also irritated that i need to spent 1 + hour setting new router for customer every time, while i could just restore my master configuration and just change few things...

Too true. It can't be that hard to implement.

In the backup the MAC are different then those in the restored to device. It could be so that restore always respect the devices MAC and use them.