The problem is not simply "fixing" backup/restore with options like "reset MAC".
The underlying issue is there is not some "declarative config" (e.g. some JSON/YAML/etc like netconf/YANG/etc) instead of even the export format.
An export is easier to modify to "clone" to a new devices, so that is better than using backup/restore..but it export is a just script with device-specific things, and also loosely bound to RouterOS version (since MT does rename/change attributes/commands). So, sure,export + customizing is the "right" way to "clone", but it's not panacea. And the backup file is opaque, making it worse than export. But both methods require some work for clone.
With some schematized config would allow checks/adaptations when cloning. In the export "script form", the config still has to be a valid RouterOS script, which opens the door to all sorts of complexities.
But that is something that MikroTik could fix. Only they refuse to do it.
When a config has items that cannot be applied to the hardware, they could be skipped and the next config item could be applied.
Unfortunately whenever there is the slightest error in a script, even the add of an item that already exists, the import stops. Instead it should write a logfile of issues and continue as much as possible. That would enable the import of a config from a different device and avoid issues like the automatically created DHCP client being in conflict with one in the file.
Thanks folks for the input. I elected to use the perfectrestore.rsc script to clone/copy/doppelganger the second router. I did need to tweak the script slightly since the files were not stored in flash/ directory. Nothing that wasn't solvable without hand-holding.
The success tune the script generates is a nice touch.
There's absolutely nothing "perfect" about the script,
but it's impossible to brick the device with that script.
Whoever wrote in the comments on that page that the script produced a "bricked" device is clearly wrong.
Nothing a netinstall can't fix.
For the tools we have now,
the best thing is /export; there's not much more to add.
And then in the future, who knows...
Then for "people like me",
what does it take to make a "parser" that reads a .rsc file section by section,
tests for compatibility before applying the line, and then applies it or not...
What's the point? It's simple programming.
I'm not kidding, and I'm not bragging.
What stops me is: the inherent, haphazard changeability of RouterOS commands.
RouterOS is notorious for not having "aliases" or consistent methods when syntax changes.
It would truly be a constant grind with every version of RouterOS, and honestly,
I just don't want to spend hours and hours for nothing (it's not about the money)
when it's EASY for me to open the .rsc file and paste it in piece by piece on another machine...
(or better create scripts for auto-config based on model and version, since on production I'm not an idiot and use only a new version after six months or more...)
Only thinking aloud, but let's say you have two devices, A and B (identical, same model and same hardware revision). Device A Is fully configured and device B Is new or however reset (even better of freshly netinstalled) without configuration.
In 12 steps:
verify that both devices run the exact same firmware and RouterOS version.
make a backup of device A
make an export of device A (let's call It full_export)
reset device A without configuration
make an export of device A (let's call It min_export)
make a diff file between full_export and min_export
since min_export will be only a few lines long It should be easy to find which lines need to be removed or "add" commands need to be converted to "set" ones
optionally verify that this diff file Is correct by applying It to router A and make another export (let's call It check_export) if check_export Is identical to full_export the diff file Is correct, otherwise loop to #6. Don't worry, in the worst case you can still restore device A through the binary backup and bring It back to the situation It was at step #1
Reset router B without configuration and make an export (let's call It min_exportB)
compare min_exportB against min_exportA, they should be identical with only MAC addresses different.
Here I was drinking my coffee, reading the topic title and thinking that you should look for some "MikroTik Anonymous"
And then you decide to post this.
Welp.
Well of course I know how to do that, and as my system has always been running Linux I have the required tools easily available, but maybe it would be good when MikroTik or some other developer made a tool that is dedicated to doing that.
You could have some option if you want router B to be an exact (as possible) clone of router A e.g. when you have bought a new device that should replace your current one, or if you want to clone a config for use in another device in the same network, same company, or whatever. In that case you would give a new IP address (or addresses), or tell the program to leave IP addresses untouched.
Well yes, it would be the easiest when the config migration assumes that both routers run the same version of RouterOS. Fortunately it is usually possible to upgrade any device so the two devices are on the same version.
This would only fail to work when your router suddenly dies, it was running an older version (maybe still a v6 version), but you have made your exports or backups and still have them. Now you bought a shiny new router and want to use the old config. That indeed is tricky to get working without knowledge and experience.
I think there is no table of command and parameter names that have changed in some version anywhere in the docs. And also the internal v6-to-v7 converter (which still is in RouterOS!) is not available as an offline tool.
Yep, that is exactly my point , the half-@§§ed 12 steps procedure I quickly summed up doesn't look like something that cannot be emulated/replicated in a relatively simple piece of software, should the good Mikrotik guys have the time/willl to do so.
But at the very least they could make a more proper list and add it to the documentation.
I would not like that behaviour. What if a follow-up line relies on the previous commands to be properly executed? Then everything afterwards will also fail. So for a simple export and import of that, such a "soft error' behaviour would improve nothing. If you write super-defensive script, you check everything possible, then you do not need such a "soft fail" behavior anyways.
My point is: this mix of configuration and scripting language is and will never be "I take this export and apply it elsewhere" and it will not even be "I take this export and apply it over same device default configuration". This is a design decision by Mikrotik, made many years ago. It is carved in the "Stone of ROS", found nearby historic Mikrotik headquarter.
I can follow your argument. Sometimes it may be more helpful to have the import finished and just have some "warnings" logged. Your point of view. For me configuration is binary: correct or broken.
, the half-@§§ed 12 steps procedure I quickly summed up doesn't look like something that cannot be emulated/replicated in a relatively simple piece of software, should the good Mikrotik guys have the time/willl to do so.