@ikerrg,

Just an idea (I don't use backupmenu). Depending on how backupmenu is packing the rootfs it may be that the backup contains parts of the filesystem that shouldn't be there.

An example: /tmp is a RAM disk. If backupmenu includes /tmp in the rootfs backup, then when you restore the image it will restore the /tmp directory on-disk. Later when you boot /tmp will be mounted as a RAM-disk, meaning your on-disk /tmp will be "hidden" underneath the mounted /tmp.

I suppose that the above is not actually happening with backupmenu. It would be seriously sloppy to backup a filesystem by including parts of other file systems (option "--one-file-system").

Just in case, I'd suggest you inspect the backup image created by backupmenu and check if there is something there that shouldn't be.

*** Update: I just checked a .tar image I happen to have here, and it looks OK.

Re. UBIFS compression. Sounds plausible enough. There may be a significant difference in the overall compression ratio depending on the other in which the files are written to the file system. One could try experimenting with this by splitting the .tar image into separate images (one with binaries, one with text files, etc.) and then unpacking them one after the other (each time in a different order), and see the effect this has (if any in the overall compression ratio for the whole rootfs.