OpenWrt on Mikrotik - backup RouterOS

Edit: Please read the full thread, as some of the responses included answers that is in actual fact false!

Good day,

From the page " Common Procedures for Mikrotik RouterBoard Products"
https://openwrt.org/toh/mikrotik/common

Towards the bottom there is a section:
Saving MikroTik RouterOS

From TFTP booted OpenWrt:

cat /proc/mtd
rem the following expects that kernel is mtd1 and rootfs is mtd2
mkdir /mnt/kernel /mnt/rootfs
mount -o ro /dev/mtdblock1 /mnt/kernel
mount -o ro /dev/mtdblock2 /mnt/rootfs
cd /mnt/kernel
tar czf /tmp/mikrotik-kernel.tar.gz .
cd /mnt/rootfs tar czf /tmp/mikrotik-rootfs.tar.gz .
cd /tmp
scp mikrotik* username@your-server:tmp

This seems to be outdated if booted via netboot with the latest OpenWrt image prescribed.
I believe RouterOS uses an old version of JFFS2 and this does not work with the newer linux kernels, hence one cannot mount the drive.

A workaround would be:

dd if=/dev/mtd1 conv=sync,noerror | gzip -c | ssh user@host of=~/a-dir/kernel.backup.img.gz
dd if=/dev/mtd2 conv=sync,noerror | gzip -c | ssh user@host of=~/a-dir/rootfs.backup.img.gz

The reverse, to restore from the directory on pc where backup should then be:

dd if=kernel.backup.img.gz conv=sync,noerror | gunzip -c | ssh root@192.168.1.1 of=/dev/mtd1
dd if=rootfs.backup.img.gz conv=sync,noerror | gunzip -c | ssh root@192.168.1.1 of=/dev/mtd2

Can anybody please confirm if this will work, and if if=/dev/mtdX or if=/dev/mtdblockX should be used as input file for dd when creating the backup, as well as for the output file (of=) when creating restoring the image?

Do you need some forum super-credentials to fix the documentation? If allowed, I will do so if somebody can positively confirm this to be a proper way to backup/restore RouterOS on RB devices.

Edit: Any advice on how to mount the images on a linux box for evaluation and exploration purposes would also be appreciated.

Thanks in advance.

1 Like

You didn't list the results of this command.

Mount what drive?
You're only backing up the partitions.

Most Linux distros with a GUI allow you to mount an IMG file.

dd should be used to backup a partition.

No I did'nt - I quoted the documentation, as per the link. At least we are in agreement the documentation can be improved.

Once again, that was taken verbatim from the documentation:

That is what the documentation instructs - instead of backing up the drive with dd, the documentation advises to simply copy all the files from the NAND using scp. Any user following the instructions will quickly realise the method described is not valid anymore.
My suggestion is to backup the partitions, which may be simpler.

As I said:

You cannot mount the actual NAND partition if you TFTP booted into the RB with the OpenWrt image, and if you used dd to create an image you cannot mount that image , irrespective of which GUI or kpartx or jefferson or mtd utils you use. As far as I could establish, it is due to the old standard/version of JFFS2 that RouterOS uses.

I may be wrong, I really hope so, but I did not come ask here for help before trying, and researching.

I really would like to deploy OpenWrt on my RB device, but would attempt that once I have a safe backup, using a confirmed method, of my RouterOS on the device.

I am of the opinion that to use dd to create images can be a workable solution, but I am not sure if mtdX or mtdblockX should be used to create, and later restore, the backup image.

Also, It may be very usefull to test RouterOS on a VM and therefore it would be usefull if the rootfs partition files on the backup image could be accessed in order to transfer them to a VM running the x86 version of RouterOS, though that is beyond the scope of this forum.

Thanks

Edited typos. Sorry, not English 1st language user.

root@OpenWrt:~# mount /dev/mtdblock3 /mnt
mount: mounting /dev/mtdblock3 on /mnt failed: Invalid argument

I am using a RB951Ui-2Hnd

There is a thread here:
https://forum.lede-project.org/t/how-to-install-to-rb750gr3/4654/30

That cover the same issue for the RB750GR3

However, not sure if that image will work on the RB951Ui-2HnD and the methods described there require some work that I think can all be avoided with making backup images using dd.

If you're a n00b, don't waste your daily post quota by triple-tapping threads!!!

I don't agree. It really seems like you're not following the instructions. If you didn't run the command, why did you mention it above...?

You posted yourself:

So if you didn't run the command, how do you know the partition numbers???

I can't assist unless you show the results of the command. That's why I said you didn't post the results. Are you just ranting about the Wiki, or do you need some assistance?

  • Also, why are you following the MANUAL directions???
  • Do you really need to backup the original OS when you can re-flash it anytime (you only need to do this if you don't control the activation key)?
  • You have not noted the model MikroTik you're working with

It's also beyond the capability of computers in 2018, an x86 is not the same CPU as the an ARxxx.

If you never ran the command, you don't know the correct number.

INCORRECT; but again, I don't need to mount old router partitions. Nonetheless, the only issue would be that you need the correct kmod for jiffs2.

Go, you try and show me!!!

I know I tried both ways. Was possible to create the image from mtd2 and mtdblock2.

Trying to mount as per the documentation DOES NOT WORK, irrespective of what flags are being used.

But as you are not a noob, please show me how it can be done!

The wiki page is " Common Procedures for Mikrotik RouterBoard Products", show generally it should not matter what the RB model is then.

Varies between the different RB models - of which I work with several.

Hence why it is a common practice to install the different RouterOS x86 on a VM and transfer the settings files only, in order to have a test bench - as you are not a noob I presume you are aware of this.

Your comments and response are definitely not helpful my question and I believeto the purpose of this forum or the project as a whole.

  • OK, I would blow the partitions away, not worry about mounting or anything.
  • Again, you didn't follow the instructions, you have to know the parittion number, that was my point. You cannot follow Manual without completing all steps
  • I wouldn't mount partitions, and I wouldn't use manual
  • Just boot OpenWrt (You have to be at this step to attempt mount)
  • :point_right: FLASH via LuCI :point_left:
  • Done
  • You likely cannot use the MikroTik setting files in the way you describe (LICENSE)

Hope this helps (and you follow my suggestions not to use the manual instructions.).

Thank you.

Should I update that page then? What would you suggest?

My problem is some of the devices has Licences that I would like to preserve in the event that I cannot obtain my objectives using OpenWrt. (and yes, the license issue can be a problem on a VM, but as it is usually only for short term testing/fault-finding purposes the demo licence allows sufficient time.)

If if I follow the page for the router specific device:
https://openwrt.org/toh/mikrotik/rb951ui
Common Procedures for Mikrotik RouterBoard Products
https://openwrt.org/toh/mikrotik/common
The page describing the first time setup and Flash from Luci:
https://openwrt.org/docs/guide-quick-start/factory_installation

the "Manual procedures are the only place I find information about creating a backup of my existing OS/settings and licences on the currently on router. All good and well if I missed something, then please advise me.

I was not able to perform the only backup instructions I could found on the these pages that seemed relevant to my devices. Hence why resorting to the forum - and receiving such a fairly, lets say harsh , response dis surprise me somewhat.

If I missed something, please tell me. I will put my arms up and opologize. noob as far as OpenWrt is concerned is reasonably accurate.

Now, I did mange to dd the images of both /dev/mtd1 (kernel) and /mtd2 (ubi) as well as /dev/mtdblock1 and /dev/mtdblock2 and I am still not sure what is the correct procedure, as these NAND devices are different from block devices I am familiar with - quite frankly, I need working routers and the ability to restore to the not-neccesarily-so-good-old ways in a short space of time if the migration from one OS to the other does not prove to be viable.

Is this my best option in order to create a backup?
Is it in fact a viable backup and will I be able to restore from this.?
Is there a different/better way?

This can surely be done, but I need to know I have a backup before proceeding, as I do not want to venture beyond the point of no return - too much at stake.

Can I use my NAND images created with dd to restore?
Then I can proceed.

Lastly, yes RouterOS has backup functions etc. If you like primitive methods. However, a one-shot restoration will be first prize, and if this can be easily executed it may encourage more people to try OpenWrt.

I will admit, the sysupgrade isn't mentioned. You may wish to update the page.

You can definitely use dd to back up the partitions; but I' not sure about restoring them to a VM.

I apologize for the "harsh" tone, I was simply trying to ask about the partition numbers if you wish to use the Manual method (can't safely backup or erase partitions without knowing the correct partition number). No harm intended. :hugs:

If you mean restore, you should be able to use dd to copy them back if needed.

You should be able to. DD to backup, DD to restore.

I'm not sure what you mean. Are you volunteering :smiley: to rewrite the WIki, so that it instructs a user on how to restore the backup-ed MikroTik partitions...or saying RouterOS should have a one-click backup solution?

I say I am volunteering to edit certain sections . I did so in my first post already.
I say you can backup licenses and settings with RouterOS. Primitive as in not a very easy simple process, as in case of restore you have to restore the OS and then the settings. Restoring an image with dd it is both done at once.

Are changes moderated/reviewed before posted/published, or do you risk envoking the wrath of the community in case of errors.

Depending on the model, there are fom 3 to 7 different partitions (that I have encountered) and according to the model the description varies (some cat /proc/mtd yields a mtd2 referred to as "rootfs" and others as "ubi". These NAND devices do not have the partition table on the actual NAND and therefore you mount the mtd2 device vie /dev/mtdblock2 , or some explanation along those lines. (do not take this as a technical reference). So if I backup, is it mtd2 or mtdblock2 that needs to be backed up and the same for restoring? Sorry to be a pain, but this last question remains unknown to me (mtd2 vs mtblock2 as backup-source/restore-target.) I presume it to be mtX for the various partitions, but I can't safely say I'm sure, as I indicated from the start.

What is the result of the ubinfo -a command on your device?

Will revert when back in the office, sitting at GMT +2

1 Like
BusyBox v1.28.3 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 18.06.0, r7188-b0b5c64c22
 -----------------------------------------------------
root@OpenWrt:~# uname -a
Linux OpenWrt 4.9.111 #0 Mon Jul 30 16:25:17 2018 mips GNU/Linux
root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "booter"
mtd1: 003c0000 00020000 "kernel"
mtd2: 07c00000 00020000 "ubi"
root@OpenWrt:~# ubinfo -a
UBI version:                    1
Count of UBI devices:           0
UBI control device major/minor: 10:59

viva la ssh

1 Like

So, it seems impossible to mount the image. I set up the vagrant box provided by the page Test Yaffs under Linux using Virtualbox and Vagrant and restored my images to the nand device created with nandsim, only one directory "lost+found"

Here is a discussion regarding the RB750GR3, that uses a different SOC. "So the only thing that would potentially hold one back from using a stock, netbootable OpenWRT kernel with an embedded initramfs userland to monkey around with ("jailbreak") an installed RouterOS is the right set of modifications to YAFFS"

So, am I missing something? please help with specific, as it seems RouterOS does not use a standard implementation of yaffs2 and no kmod for jffs2 will resolve that.

I am still stranded with nobody who could confirm the dd image can be restored with dd to the RB device, I will have to get a surplus RB that can be taken out of action if it fails to test this theory. In the meanwhile I will check again if it is possible to mount the mtdblock devices and scp the files.

Either way, it seems to me the documentation is wrong and currently I am not able to advise the correct way to backup the RouterOS before proceeding with the OpenWrt installation.

If you install a different OS and want to revert to RouterOS mikrotik expects that you buy a new license and deems the old license invalid. In many countries, as in mine, that is illegal, as consumer protection acts recognise the license is sold with the device in order to operate software on the device, hence the license is transferable if the device is transferred to a new owner and as long as the device is working the license should be valid.

Correction, it seemsto be an old version of YAFFS as opposed to a nonstandard version. The Chaos Calmer netboot image will allow one to access the files.

Okay, several things here.

First of all, RouterOS either uses YAFFS or UBIFS, depending on board model. One of the posters in the RB750Gr3 thread mistakenly said JFFS when he meant YAFFS, and if marakasmalan had been reading that thread, that might explain why he mistakenly typed JFFS2 originally, as well. JFFS is not used in any version of RouterOS, past or present.

Second, it is actually not settled whether RouterOS version of YAFFS has custom modifications or is simply "older". I suspect it has actually been modified by MikroTik, though I admit have not taken the time to study this in detail. I just know that even back when I was playing around with Kamikaze, Backfire, Attitude Adjustment, etc. on YAFFS RouterBoards, and even if the OpenWRT kernel I was using had the exact same partition layout burned into it as RouterOS (partition offsets were all correct), trying to mount one of the RouterOS MTD partitions using the OpenWRT kernel's YAFFS implementation would end up causing filesystem corruption. Apparently @sidepipe from the other thread had similar experiences. I have not tried to repeat this experiment in some time. These days I just make sure that if I actually care about preserving the contents of the partitions, I build and use a kernel based on MikroTik's official Linux patch sets which contains their (allegedly) forked implementation of YAFFS, instead of an official OpenWRT kernel.

Finally, I am sure that the author of the bits quoted from the wiki page at https://openwrt.org/toh/mikrotik/common had good intentions, but there is no need to back up either the RouterOS software license key, or even RouterOS itself, from a RouterBoard before flashing it with OpenWRT. Doing that is a complete waste of time.

A quick primer on RouterOS licensing:

License enforcement is made up of two parts: Software-ID, which is an 8-character string that uniquely identifies a RouterOS installation, and the license key file which describes the RouterOS feature set that you are allowed to use on a given installation. The license key file is generated based on a particular Software-ID, so that you may only load the license file onto the particular router that you bought the key for (otherwise you could buy a single key and load it onto as many routers as you wished).

This system was engineered by MikroTik back when they only sold software, and did not manufacture any hardware. RouterOS started out as x86-only, and you would buy a software license to install it on any standard PC hardware. For x86 RouterOS -- which still exists! -- the Software-ID was generated based on a hash of several unique properties of the disk that the OS was installed on...only MikroTik knows the exact "recipe" of the hash, but it is believed to take into account the disk make, disk model, and disk serial, as well as possibly the contents of the MBR partition table and/or the particular ext2/ext3 filesystem that RouterOS lives in. The good thing about this system is that it means your RouterOS license is tied only to the disk itself, and not to the entire PC (for example, Microsoft / Windows Product Activation), so you could take a disk with RouterOS out of one PC and put it in another (to upgrade your "router" hardware) and not have to buy a new license. Since it is tied to the disk, you cannot "clone" the license by making a bit-for-bit copy to a second disk...when you boot the "cloned" RouterOS on the second disk, you will find the Software-ID has been re-computed and so your license key will no longer work. Unfortunately, since it also seems to be tied somehow to either the MBR or the main filesystem, if you reformat and reinstall RouterOS onto the same disk, the Software-ID will also change then, too, and your license key will be forefeit. Also, if your disk dies, your license is also forefeit.

When MikroTik started making their own hardware, and that hardware wasn't x86-based and had built-in, non-user-replaceable storage (soldered-on flash chips), they continued to use the same licensing model but came up with a different way for non-x86 RouterOS to generate Software-ID. Software-ID on a RouterBoard is NOT based on the disk/storage. It is based on something else about the RouterBoard that never changes...we don't know what exactly (maybe board serial number, or MAC address of eth1? who knows), but we do know that a given RouterBoard will never have its Software-ID change. The Software-ID that it ships with from the factory is the same one that it will have for life, no matter how many times you wipe the flash chip that holds RouterOS on it and re-install the OS.

Not only that, but both the Software-ID and even the license key itself appear not to be stored anywhere on the main flash chip where RouterOS lives, but rather somewhere on the bootloader's SPI flash chip, which is a separate chip, and it is not touched at all by the OpenWRT flashing/installation process (unless you decide to replace MikroTik's RouterBOOT bootloader with something else like U-Boot...so don't do that!)

I have written zeros to the entire main OS flash chip on a RouterBoard many, many, many times, both via RouterBOOT as well as via "flash_eraseall" from within OpenWRT, and then re-installed RouterOS on it later, and the license key that the board originally came with was always preserved and always automatically detected by the RouterOS installer ("NetInstall"). I have never, ever had to back it up...it is always just "there".

So not only is there no reason to back up RouterOS on a RouterBoard in order to preserve the license key (since the license key isn't even stored on the filesystem with RouterOS for non-x86 versions of it), but there is also no reason to back up RouterOS simply so that you can return to it later...you can always reinstall RouterOS onto a RouterBoard that you have flashed with OpenWRT using MikroTik's "NetInstall" utility, and if you are worried about backing up RouterOS so that you can preserve the version that your board shipped with, you also don't need to worry about that since you can install any past version of RouterOS with NetInstall...you aren't forced to go to the most recent release if you don't want to. There's no downgrade prevention or any of that nonsense.

In fact, as long as you don't touch the SPI flash where RouterBOOT lives, RouterBoards are virtually unbrickable[1], which is one of the reasons why I like them so much...

Hope this helps,

-- Nathan

[1] ...the main exception is if eth1 is physically damaged, because that is the only interface that RouterBOOT can netboot from. So if eth1 is dead and you screw up the contents of the OS flash, then you're in trouble...

3 Likes

Thank you for clarifying, very insightful!

From the supout.rif file, if it is of any use. I presume charles refers to Charles Manning, the NZ bloke who wrote YAFFS

^E^@^@^@^@^B^@^@^@^Eyaffs^A^@^@^@^D^@^@��^C^@^@^F^FYAFFS built:Mar 22 2018 09:40:54
$Id: yaffs_fs.c,v 1.53 2006/10/03 10:13:03 charles Exp $
$Id: yaffs_guts.c,v 1.35 2006/06/05 04:10:49 charles Exp $

Device 0 "RouterBoard NAND 1 Main"
startBlock......... 0
endBlock........... 991
chunkGroupBits..... 0
chunkGroupSize..... 1
nErasedBlocks...... 729
nTnodesCreated..... 1200
nFreeTnodes........ 549
nObjectsCreated.... 600
nFreeObjects....... 143
nFreeChunks........ 57692
nPageWrites........ 311
nPageReads......... 13255
nBlockErasures..... 78
nGCCopies.......... 2
garbageCollections. 77
passiveGCs......... 77
nRetriedWrites..... 0
nRetireBlocks...... 0
nBadBlocks......... 0
eccFixed........... 0
eccUnfixed......... 0
tagsEccFixed....... 0
tagsEccUnfixed..... 0
cacheHits.......... 207
nDeletedFiles...... 34
nUnlinkedFiles..... 142
nBackgroudDeletions 0
useNANDECC......... 1
isYaffs2........... 1

Device 1 "RouterBoard NAND 1 Boot"
startBlock......... 0
endBlock........... 29
chunkGroupBits..... 0
chunkGroupSize..... 1
nErasedBlocks...... 18
nTnodesCreated..... 100
nFreeTnodes........ 52
nObjectsCreated.... 100
nFreeObjects....... 92
nFreeChunks........ 1294
nPageWrites........ 68
nPageReads......... 71
nBlockErasures..... 1
nGCCopies.......... 64
garbageCollections. 0
passiveGCs......... 0
nRetriedWrites..... 0
nRetireBlocks...... 0
nRetireBlocks...... 0
nBadBlocks......... 0
eccFixed........... 0
eccUnfixed......... 0
tagsEccFixed....... 0
tagsEccUnfixed..... 0
cacheHits.......... 0
nDeletedFiles...... 1
nUnlinkedFiles..... 2
nBackgroudDeletions 0
useNANDECC......... 1
isYaffs2........... 1

Thanks you to anathan for directing me to the excellent document Forensic analysis of the android file system YAFFS2
In there:

Physical acquisition with dd command
As Android is based on the Linux kernel, the “dd” command can be used. The dd command can be issued for each mtd partition as follows:
dd if=/dev/mtd/mtd* of=/sdcard/mtd*.dd bs=4096
where * indicates the partition number. When analyzing a seized device, the resident SD card should be removed to be imaged separately, and another cleanly erased SD card should be used in its place to store the image files from the dd command. After imaging all mtd partitions, each image should be validated to verify the data structure of the yaffs2 file system. The result of the validation indicated that the image files have only the chunk data without any spare data. Hence, the dd command does not produce a complete image of the flash memory.
This image cannot be realistically used to retrieve files. Due to the unavailability of the spare spaces, each chunk data cannot be mapped to the corresponding file object. The spare data structure, such as the object_id, is not available to facilitate this process.

So, be careful, dd cannot be used to backup or restore YAFFS2 images

I am very greatful I decided to wait for confirmation before proceeding.

mkyaffs2 from yaffs2utils can be used, but only files are retrieved when unyaffs2 is applied, all data related to deleted items are not recovered, i.e. only logical data is retrieved. This should be sufficient for backup purposes. xRecovery uses yaffs2utils and will preduce the same results.

For an accurate and complete image containing all data, nanddump from mtd-utils should be used. Carefull, as mtd-utils also contain stress-tests that will shorten, if not demolish, the lifetime of the nand flash memory.

1 Like