This script provides an ability to create Mikrotik's daily backups to email. You can also enable automatic RouterOS upgrade or leave only notifications about new firmware versions.

Features:

• Ability to choose script operating mode according to your needs. (Read below)

• Script creates backups of the whole system and exported config.

• You can set a preferred update channel.

• If automatic updates are enabled, you can set script to install only patch versions of RouterOS updates. This means if the current RouterOS version is v6.43.6, the script will automatically install v6.43.7 (new patch version) but not v6.44.0 (new minor version), for example.

• Script includes primary information about the device into the email message. So you can easily find the backup you need among multiple devices.

• For safety purposes, an automatic update process will not be started if script could not send backups to email.

• Routerboard firmware can be automatically upgraded according to the installed RouterOS version.

Script operating modes:
Backups only - script creates system and config backups and sends them to specified email as an attachment. Using email account as storage for your backups.
Backups and notifications about new RouterOS release - Except backups, script also checks for new RouterOS firmware release and provides this information in the email.
Backups and automatic RouterOS upgrade - Script makes a backup, then checks for new RouterOS version, and if new firmware released, script will initiate upgrade process. By the end, you receive two emails. The first one contains system backups of the previous RouterOS version, the second message will be sent when the upgrade process is done.

Here is a script and installation manual: https://github.com/beeyev/Mikrotik-Rout ... and-update

it is very useful

Hi - Thank you for all your great work on this!

I have been testing it was great (perfect) success. I would like to offer a request for future enhancement.

Some background.... The issue for me comes down the risks of auto update VS un-patched and updated systems in the wild. In my experience it is easy to "plan and talk" talk about upgrading existing routers but another to actually do it. At the very least, the task it is laborious and something to keep getting put off and off.... perhaps its just me. Not enough hours in the day.... I have been doing this long enough to have lived through updates the break things, so I am hesitant to go all in. Can we get the best of both worlds?

Hence - a possible enhancement that gets us some of the way there. Could we "pause or delay" an update from installing from a time perspective?

For example -
1 - Execute the check for new update for whatever channel you are on - as it does today.
2 - Add a variable that delays the actual update by some number of days - say 7 for example. This could be done by creating schedule/script for that future time or perhaps disables the process on a timer?
3 - Pause "disable" the daily check
4 - Execute the upgrade after the delay expires or date is reached and send emails
5 - Re-enable the daily check schedule

That would give us time to evaluate new updates. We could intervene if necessary and stop the update, delay it, etc.... or simply let it upgrade automatically.

This would give a little buffer for us to do our due diligence and intervene if necessary. If reports are good then let it update as scheduled. I realize this may not be perfect and some issues that may have not been discovered in the 7 day example window could still persist, but should catch most.

Curious what you think and others think.

Curious what you think and others think.

Great idea, think i could implement it in a future release.

Why such difficulties?

default update script: Simple script backup and export configuration:
Very simple script send backup and configuration:

Manipulate the presented scripts in the scheduler or glue them into one script

Example:

Bee I'm running the script, and it never updated to the latest version even though it came out on April 30th. What could be the problem?

The funny thing.. I just manually ran the script, and it immediately updated.

When it runs automatically, it does not see the updated firmware and does not do it on it's own.

Any ideas?

Auto upgrade MT routers may fail. There has over the last years been several times bug has been introduced or change to some like Wifi that made the router stopped working.

So a delay is minimum thing that should be in the script.
But If I had lots of routers and lots of time, I would have setup a web page there I could control the scrip remote.
Its easy to make a script read an external webserver. Then depending on the information there, control what the upgrade should do.
You could have one setting to allow/prevent upgrade.
One setting to tell what version to upgrade to. Testing/longterm/stable etc.
One stteing for what type of Router to upgrade.

With this type of approach you could the the router to downgrade if needed.

The funny thing.. I just manually ran the script, and it immediately updated.

When it runs automatically, it does not see the updated firmware and does not do it on it's own.

Any ideas?

Mark dont-require-permissions script policy

Auto upgrade MT routers may fail. There has over the last years been several times bug has been introduced or change to some like Wifi that made the router stopped working.

So a delay is minimum thing that should be in the script.
But If I had lots of routers and lots of time, I would have setup a web page there I could control the scrip remote.
Its easy to make a script read an external webserver. Then depending on the information there, control what the upgrade should do.
You could have one setting to allow/prevent upgrade.
One setting to tell what version to upgrade to. Testing/longterm/stable etc.
One stteing for what type of Router to upgrade.

With this type of approach you could the the router to downgrade if needed.

Hi Jotne - I am not the author of this well done script, but my comments a few posts above are similar to yours.

I agree bugs can be introduced in new versions. I think we need to have a variable that delays the installation of a new version (once discovered) by some time, 7 days for example. Consider it a cool off period.

While maintaining a webserver is good idea - I don't want another "thing" to manage. I personally like the simplicity and thoughtful design of beeyev's script. If something went terribly wrong in an update, I believe it would be exposed on the forum and elsewhere in short order. We could make a decision to either manually stop, pause, allow, etc... the update based on the specific use case for that router in it's environment. I understand the it involves somebody to manually step in at that point. I believe that using/having an automatic upgrade capability is a better option than leaving a number of systems out in the wild not being upgraded and patched. Risk vs reward for sure, everyone will have a different comfort level with it for sure.

Another wrinkle to be sorted is, what if another updated was released in the "cool off" period to address a Wi-Fi bug as you alluded to from a previous release? I guess I would want it to check again after the "cool off" prior to determine if a newer version was available. Either way, I don't think this or any other upgrade solution is a perfect answer in the sense that becomes a substitute for good oversight, due diligence, and proper system management. Others may disagree.

I do agree, however, if I was into the 100s of routers I would look at Unimus, Ansible, or the like. Controlling the upgrade and config based on environment you are upgrading from would be great. I assume (and hope for their sake) anyone with a large base of deployed routers would already have a solution for getting updates and change management done... For the rest of us, I think this is a great solution.

Again - thank you beeyev for all your great work on this.

Beeyev,

Would it be possible to also add an option to ftp along with email?

Also, is there a way to remove the backups created on the router itself?

Thanks!

Beeyev,
Would it be possible to also add an option to ftp along with email?
Also, is there a way to remove the backups created on the router itself?
Thanks!

Would it be possible to also add an option to ftp along with email?
Maybe in future, these days I am quite busy.

Also, is there a way to remove the backups created on the router itself?
This feature was already implemented, and should work correctly.
Here is line 377

Thanks I look forward to it!

which is useful when upgrading devices in bulk

And this should only be used when software has been tested on the current hardware with the same config as you have.
MT has several times change stuff that breaks the config so that you can not reach the device after upgrade.

Here is how to send this as a single command which is useful when upgrading devices in bulk:

Code: Select all

/system package update check-for-updates once; delay 3s; if ( [/system package update get status] = "New version is available") do={ /system package update install }

This is one of the stupidest things you can ever do.
Given MikroTik's increasing unreliability in releasing long-term updates that don't block machines,
just an idiot would set up automatic updates on their network.

And about the command, is really redundant, if you want rouin your day, simply "/system package update install", the install command already check for new version.
If the version is the same, do nothing, not reinstall the same version.

Beeyev,

Would it be possible to also add an option to ftp along with email?

Also, is there a way to remove the backups created on the router itself?

Thanks!

Here is a fork of the script which supports FTP, SFTP and also email: https://github.com/BrandonSk/Mikrotik-R ... e-With-FTP
You can use that before Beeyev merges it into the master script.

Cheers,
B.

Not a big deal, but if you have made the script, I do suggest that you remove all ; at the end of each line.
Its only needed when you are separating multiple command on one line.

As its now it its a mix.