backup and restore brings strange loss of many folders

[benit]

I used a backup software to backup and restore a maui partition. I got no errors, but the result of restoration is strange: a lot of folders are missing. How can that happen?

Has anybody any idea, if there is a common denominator for the missing folders? Any idea what could be wrong? I would assume that the backup software would give warnings, if any error should occur.

If that helps: It was done using an "incremental" backup technology that would allow me to re-use this backup incrementally so that only changes would be secured in the second turn and so on.

[leszek]

Could it be that you only restored or tried restoring one incremental snapshot instead of the whole backup?
What software did you use exactly?
Did the software had permissions (usually it needs root/sudo permissions) to access all files?

[benit]

I do use Macrium Reflect backup software. It can copy a partition in a "compressed" form with all files that are in or in a "forensic" form that exactly makes a bit-by-bit copy including all sectors that may contain deleted files etc. I have written to the support to ask what is going on. For the future I have to be sure what I should do so that my backups are safe.

[benit]

Support told me that Macrium allows to backup ext4, but that there is "no support" for it. So it seems that this a "non-guaranteed" way to go.

Is there any other backup software with GUI that allows for incremental / differential backups both of NTFS and Linux partitions or folders? I would consider also a commercial solution if this is easy-to-use and rock solid.

[leszek]

I always used backintime which under the hood uses rsync to sync things up.
But I think this is only available for Linux. It should however be able to also backup data from ntfs partitions (practically all partitions linux can read)

[kdemeoz]

I always used backintime which under the hood uses rsync to sync things up.
But I think this is only available for Linux. It should however be able to also backup data from ntfs partitions (practically all partitions linux can read)

Hi leszek. Thanks for posting this cool advice. For years i used Areca Backup, but it broke a few years ago [anyway i was not happy about its Java dependency, really]. Since then i have used luckyBackup [yes, that's the weird way its Dev spells it], which has been pretty good although rather idiosyncratic [but its development froze in 2014, which has been becoming more & more of concern to me]. Post-Areca i tested several possible candidates & liked none of them til i found lB... but for inexplicable reasons somehow i did not discover BIT at that time. 

Reading your mention of it here intrigued me, so i researched it, installed the repo version [1.1.12], liked it, & so have now added its PPA which has upgraded me to the latest release 1.1.20 [includes a critical bugfix, as also have other releases >1.1.12]. I'm just about to erase my lB archives from one of my two backup USB sticks, create the applicable BIT snapshot profile for it, & run it to see if indeed this will become my new backup tool. I feel positive towards it from what i've seen so far.

It's lovely that i keep learning good things here    

[kdemeoz]

Hi again leszek. I have now used BIT several times, initially creating full backups of my pertinent Tower user files last week on two USB sticks, & just now completing the first incremental backups to the same sticks. BIT is seriously impressive!! I like it more than my previous b/u pgms.

The only criticism possible is that, compared to the other pgms, it seems to use a lot more cpu. The full backups frequently used 90% - 100%**, & today's incrementals often used ~60%.

**As i was not expecting this, last week during the first attempt at the first full b/u to the first stick, i had kept one of my VMs running during the b/u [coz i wanted to play around inside the VM, until the b/u's on my "real" Maui were finished so that i could then stop playing in the VM & reopen my docs on my "real" Maui to get on with my activities]. Well, the combined [unexpected] cpu load of VM + BIT was so extreme that it actually froze Tower [yes, yet another freeze, but i'm assuming this one was my own fault]. Hence today i learned my lesson & ensured no VMs were running when i did the b/u.