Restore a system from a system snapshot

[codesmaker]

Hi,

I have been trying to restore a system (ubuntu 16.04) from scratch using a system snapshot but I'm facing some problems.

1- It seems that there are some files that are restored with wrong permissions. I can give one example:
Before the restore:
-rwxr-sr-x 1 root mlocate 39520 Nov 18 2014 /usr/bin/mlocate
After the restore:
-rwxr-xr-x 1 root mlocate 39520 Nov 18 2014 /usr/bin/mlocate

2- After the restore has finished, I can login with no problem but if I lock the PC, the same password which was used to login doesn't work anymore. I can work around that by clicking on the swtich account (on the upper right corner) and then I choose the same user and the password works. This could be related to wrong permissions?

3- It seems that when I restore, the old files don't get deleted. It means that the restoration process doesn't delete the files then restore. Does it mean that I won't get an exact copy of the snapshot? Yes, there is an option to restore and delete files but I'm restoring from a live image and it seems that this option always restore to the "/" which is a USB drive, not to a mounted partition. Is there a way to restore and delete while choosing a specific partition?

Thanks a lot for all your help and efforts!

[Germar]

Hi

1. You need to remount your drive first with SUID option enabled (see AskUbuntu):

   sudo mount -o remount,suid /mnt
   

2. sorry, I have no clue. But sounds reasonable. So it would be best to fix the permissions first.

3. I did not thought about restoring to an external mounted, none-empty drive during adding the "delete" restore options. But it's on my Todo list. For now you can use command-line restore with backintime --delete restore / /mnt 0 (restore filesystem root to /mnt from last snapshot).

[codesmaker]

Thanks a lot for the quick reply and help!

I still have the same problem with the permissions. So, I remounted my partition on which I want to restore my system without "nosuid". Here is how it looks when I run mount:
/dev/sda5 on /media/ubuntu/part2 type ext4 (rw,relatetime,data-ordered,uhelper=udisk2)

After the restore has finished, I checked the mlocate file and it didn't have the guid set exactly as I showed you above. When I checked the restore log, I could only find a chown to /usr/bin/mlocate but there was no chmod. Am I missing something?

[Germar]

I'll try to reproduce this. Yesterday I just double-checked restoring SUID permissions on a local, internal drive which worked.

[codesmaker]

OK, thanks! It's pretty much a standard Ubuntu 16.04 installation that I'm testing.

[Germar]

Hmm. Now I'm confused. I tested it on an external drive and it does restore setuid and setgid permissions even with nosuid mount-option...

/dev/sdb on /media/germar/external type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)

Can you change permissions manually on the external drive with chmod g+s /media/ubuntu/part2/testfile?

EDIT: 3. is almost done. Just need some more testing. So maybe tomorrow evening I'll push a new 1.2.0~alpha to ppa:bit-team/testing which will include this.

[codesmaker]

WOW, that was fast, the testing and adding the feature:). Yes, I can set the guid manually without no problem even when the partition is mounted with nosuid. I also tried to delete all the files in the partition and restore but I always have it without the guid set. Have you checked this particular file after you restored (/usr/bin/mlocate)?

Here is my restore log restore.log.txt
Maybe it will be useful for you. I can see in the log that there is a chown for this file:
chown /media/ubuntu/844b7144-b424-468e-8c55-8f8985b62221/usr/bin/mlocate 0 : 117
But there is no chmod for it. Is that normal?

[Germar]

I just pushed a new alpha to ppa:bit-team/testing. Should be up and running in half an hour.

I checked again with /usr/bin/mlocate and permissions are restored correctly here.

Rsync also handles permissions during restore and so the restore permissions routine will only change permissions if they differ between the restored file and the entry in fileinfo.bz2

[codesmaker]

Awesome! I tested it quickly and it works. I think the restore menu now is clear and clean more than before. I'll test it more and keep you posted.

I have no idea what's causing this issue. What I've also noticed is that during the restore of files, before restoring the permissions, the mlocate permissions are correct but when the BIT starts to restore the permissions, it changes to:
-rwxr-xr-x 1 root mlocate 39520 Nov 18 2014 /usr/bin/mlocate

Here is the mlocate permissions in fileinfo.bz2:
34285 root mlocate /usr/bin/mlocate

The problem is that I have no idea how many files are affected. Any ideas? How can I debug more?

[Germar]

Ah, okay! Now I get a picture about what is going wrong. The restorePermissions function will read stats (owner, permissions, etc) first from the file. Next it will change the user/group if they do not match and finally change permission if they do not match with the stats read at start. But here is the bug: chmod does remove the suid bit for security reasons and if BiT compare the stats (read at function start) with the permission from fileinfo.bz2 they still match but the real file permissions does not match anymore.

[codesmaker]

I've installed v1.2.0-alpha12 and restored the system from a snapshot and voila! Everything works as it should :). Thanks a lot for all the help and the very quick responses!

Do you have an idea when this version 1.2.0 will be released? I can't wait.