Well, I didn’t post anything yesterday because I was messing around with some code the night before and managed to crash my Router OS router.
Look at the picture above, clearly supposed to go here, but the router decided to send me there. For a moment, you might think the two internet giants have merged or something.
After nearly half a day of messing around, I finally restored the Router OS router.
At this point, I thought of a question: why haven’t I backed up the router settings? The iN router has been up since 2020 and hasn’t seen much change.
During that time, I just made minor tweaks and changes to the settings. So when the router crashed yesterday, I had to reset dozens of settings one by one. It can be quite frustrating sometimes. Looking at the router’s storage space, the most recent backup file was from three years ago, which was basically useless. Resetting, troubleshooting, and reconfiguring it all felt like starting from scratch.
By the time I finished, it was already past 3 PM. With this lesson learned, it’s time to discuss the importance of backups. Generally, once a router is set up, it rarely needs to be modified again, and it can run stably for years or even decades. So, in most cases, the value of backups on a router isn’t that significant. However, for home users, we are constantly tweaking and modifying settings. Sometimes catastrophic events make having a backup configuration to roll back to more essential.
Backing up on Router OS is quite simple. You just need to run /system backup on the command line, and it will generate a backup of the current system in the file storage area. Alternatively, the /export command can also export all settings into a script configuration file.
However, both of these commands need to be manually executed. While Router OS does have a task scheduler, and we can generate time-stamped backup tasks, routers typically have limited storage space. This means that after a while, the backup files will fill up the storage, and manually deleting them can be quite a hassle and time-consuming.
So, what’s the solution?
Write a script to handle it. Here are a few key points:
- To avoid backup files filling up the router’s storage space, I used a cyclic backup mechanism. This backs up the router’s settings for the past week, with each weekday’s settings overwriting the previous week’s. So, only seven backup files—AutoBackup-0 to AutoBackup-6—will exist on the router.
Of course, you can adjust the script to something like :local day daynum % 7. The number 7 represents the number of backups, which returns an integer between 0 and 6. If you want a half-month backup cycle, you can change 7 to 15. Then adjust the rest of the program accordingly.
- To map the numbers 0 to 6 to actual weekdays, you’ll need a date-to-weekday algorithm. However, Router OS scripts don’t have this function built-in, so I wrote one. This is how the weekday is generated:
(($dayNum + 6 + ((13 * ($monthNum + 1)) / 5) + $K + ($K / 4) + ($J / 4) + (5 * $J)) % 7). - If a backup file already exists on Router OS, it will overwrite it. If it doesn’t exist, a new one will be created. Using this mechanism along with the algorithm above ensures there will only ever be seven backup files, preventing storage space from being overwhelmed with backup files.
Here’s the complete script. Save it in “System – Scripts” under the name “AutoBackup.”
:local date [/system clock get date]
:local firstDashPos [:find $date "-"]
:local secondDashPos [:find $date "-" ($firstDashPos + 1)]
:local year [:pick $date 0 $firstDashPos]
:local month [:pick $date ($firstDashPos + 1) $secondDashPos]
:local day [:pick $date ($secondDashPos + 1) [:len $date]]
:local yearNum [:tonum $year]
:local monthNum [:tonum $month]
:local dayNum [:tonum $day]
:if ($monthNum < 3) do={
:set yearNum ($yearNum - 1)
:set monthNum ($monthNum + 12)
}
:local K ($yearNum % 100)
:local J ($yearNum / 100)
:local weekday (($dayNum + 6 + ((13 * ($monthNum + 1)) / 5) + $K + ($K / 4) + ($J / 4) + (5 * $J)) % 7)
:local backupName ("AutoBackup-" . $weekday . ".backup")
:log info ("Backup file name is: " . $backupName)
/system backup save name=$backupName
This morning, I checked and found two backup files in the storage area. One was from yesterday’s testing, and the second was auto-generated.
The dates correspond correctly too: 0 stands for Sunday, 6 for Saturday (yesterday), and tomorrow morning, it will generate one for Monday, labeled as -1.
Once the script is ready, all you need to do is schedule it under “System – Scheduler.”
In the task window, set the start time and execution interval, and the script will run at the scheduled time.
In the “On Event” field, enter the script name “AutoBackup,” and you’re all set.
This backup method may seem pointless, fitting our “Useless Skills” theme, but it guarantees that Router OS users can always restore their router configuration from any day in the past week—provided the router hardware itself hasn’t failed. It’s a peace-of-mind solution.
But what if the router does fail, and you can’t log in anymore? Are these backup files useless?
Actually, you could add a line in the script to use /tool sendmail and send the backup file to your email. For me, this isn’t really necessary, so I didn’t include it. If you feel like receiving the backup file in your email daily would be annoying, you could also use an if-statement to only send the backup on Sundays, for example.