Backintime vs. Grsync {SOLVED}

[cliffcoggin]

Having relied on Grsync for four years to back up my precious data, I have experimented today with Backintime from the Software Manager, and have to say it was easier to set up than its predecessor. The only odd thing I have noticed so far is that the files in the back up were read only. Is that normal?
Mint 19.2 Cinnamon.

[AndyMH]

The only odd thing I have noticed so far is that the files in the back up were read only. Is that normal?

No. Mine are all owned by me. Did you use backintime(root)? or check permissions on the backup destination.

[cliffcoggin]

No, I used the non root version. The destination was a new USB stick that I had formatted to ext4 and named with the USB stick formatter.

[AZgl1800]

don't know what difference it makes,
but for myself, as I back up to a 2nd partition and also to an extUSB drive,

I use the Root version.

[AndyMH]

The destination was a new USB stick that I had formatted to ext4 and named with the USB stick formatter.

Never used it but can't think of any reason why it would give any problems. I normally use gparted. If you use it to create an ext4 partition then it is owned by root. But that would throw lots of permissions errors doing a backintime snapshot as it wouldn't own the destination.

All I can suggest is have a look in the last log and see if there is anything there to provide clue.

Workspace 1_006.png (36.85 KiB) Viewed 1573 times

[cliffcoggin]

OK. I'll explore tomorrow.

[sanmig]

The only odd thing I have noticed so far is that the files in the back up were read only. Is that normal?

No. Mine are all owned by me.

Mint 19.3 Cinnamon, I have Back In Time 1.1.12, not root, all backup files are read only.
This is the default.

In Settings/Options there is a checkbox for
“Full rsync mode. May be faster, but: - snapshots are not read only”.

Probably Andy has set that option?
(ups, … seems older versions don’t have the option, see screenshot in B.I.T docs?)

[AndyMH]

In Settings/Options there is a checkbox for
“Full rsync mode. May be faster, but: - snapshots are not read only”.

Probably Andy has set that option?
(ups, … seems older versions don’t have the option, see screenshot in B.I.T docs?)

I vaguely remember something like that and would have set it, but can't find it in options or expert options in V1.2.1 (LM20.1). Think I started using it in LM18 and with a separate /home partition have kept all my configs, so that might be where it came from. Which version are you running?

[cliffcoggin]

Mint 19.3 Cinnamon, I have Back In Time 1.1.12, not root, all backup files are read only.
This is the default.

In Settings/Options there is a checkbox for
“Full rsync mode. May be faster, but: - snapshots are not read only”.

I missed that setting. Thanks for the tip. Have you restored your backup files, and if so did they revert to normal permissions?

[AndyMH]

I missed that setting. Thanks for the tip. Have you restored your backup files, and if so did they revert to normal permissions?

I've not done a full restore, but have restored individual files and folders. Usually when I've screwed up some source code and it is easier to go back to yesterday rather than try to untangle what I did wrong. No problems.

[cliffcoggin]

So Andy can restore from read/write backup. I wonder if Sanmig can do the same from read only backup. I will have to test this after creating some disposable files for experimentation with.

[cliffcoggin]

I found some time to test the non root version of BIT as follows.

I created a folder called TEST containing a variety of files (jpeg, Calc, and Writer,) and sub-folders. I made a snapshot of it on a USB stick, and confirmed that some, though not all, of the files on the snapshot were read only, even though the originals were read & write.

The next step was to delete the originals in the TEST folder, and then restore them from the snapshot, and sure enough everything was restored as it was initially. I noted the log of the process mentioned that its final step was to restore permissions, so it looks if my concerns over permissions were groundless.

Nevertheless I don't like a backup that is not identical in all respects to the original, and requires some sort of intervention by me or a piece of software to restore it. I need to experiment further.

[cliffcoggin]

I repeated the above tests in full Rsync mode, and as expected the files in the snapshot were read & write, furthermore restoring them worked fine.

That leaves me wondering what the advantage of the default setting might be. Why would one not use the full Rsync made?

[AZgl1800]

I repeated the above tests in full Rsync mode, and as expected the files in the snapshot were read & write, furthermore restoring them worked fine.

That leaves me wondering what the advantage of the default setting might be. Why would one not use the full Rsync made?

Interesting find.

I will have to double check my BIT settings.

[sanmig]

That leaves me wondering what the advantage of the default setting might be. Why would one not use the full Rsync made?

N00b mode? (n00b here )
As you wrote, at restore all the permissions are restored, e.g. -rw what was -r-, it would be useless otherwise.
I think the read only is an attempt to protect the backup’s integrity, as I haven’t seen data files with rw in the backup?
Also all attributes are stored in an extra file so one could use a NTFS destination for the backup, with full rsync it requires the ext format.

Which version are you running?

Mint 19.3 Cinnamon, I have Back In Time 1.1.12, not root,

[Alan16]

Have you restored your backup files, and if so did they revert to normal permissions?

I wonder if Sanmig can do the same from read only backup.

I noted the log of the process mentioned that its final step was to restore permissions, so it looks if my concerns over permissions were groundless.

Nevertheless I don't like a backup that is not identical in all respects to the original, and requires some sort of intervention by me or a piece of software to restore it. I need to experiment further.

That leaves me wondering what the advantage of the default setting might be. Why would one not use the full Rsync made?

As you wrote, at restore all the permissions are restored, e.g. -rw what was -r-, it would be useless otherwise.
I think the read only is an attempt to protect the backup’s integrity, as I haven’t seen data files with rw in the backup?
Also all attributes are stored in an extra file so one could use a NTFS destination for the backup, with full rsync it requires the ext format.

Same here, original files are rw-, snapshots are r--, to protect them I guess.

readthedocs says:

"Backups are stored in plain text. They can be browsed with a normal file-browser or in Terminal which makes it possible to restore files even without Back in Time.
Files ownership, group and permissions are stored in a separate compressed plain text file (fileinfo.bz2). If the backup drive does not support permissions Back in Time will restore permissions from fileinfo.bz2. So if you restore files without Back in Time, permissions could get lost.

https://backintime.readthedocs.io/en/latest/

You see the seperate file here:

[Alan16]

I have two snapshots of the home/documents directory now, one made on feb 21, the next on april 4.
The original directory contains 5,5 Gb. The sizes of both snapshots are 3,2 Gb.
This raises a question. Since Back in Time snapshots are incremental, I would expect the first snapshot to be larger than the second?

[cliffcoggin]

I can not comment on the backup size as I have only made the one full backup of home, and that was in full Rsync mode so that original permissions were kept.

Whether I shall continue with BIT remains to be seen as it is not as simple to navigate to individual files as Rsync backups. For now I will run both backup systems in parallel. After all, you can never have too many backups.

[sanmig]

This raises a question. Since Back in Time snapshots are incremental, I would expect the first snapshot to be larger than the second?

I see two questions here.
The first is the difference between 5.5 and 3.2 GB -
I can not explain but suspect not all files were backed up: Compare them using Nemo and check the log (menu "View").
In my case, when using B.I.T as normal user, there are warnings and files missing because of deficient permissions (e.g. my foxclone test images require root permission to access - unfortunately Nemo offers “Copy” but fails to do it as standard user …).
- Otherwise original and backup must have the same size!

The second:
Yes, the backups are incremental, but because of using Rsync (hard links, see https://www.geeksforgeeks.org/soft-hard ... unixlinux/) the incremental (hard) link presents the same file size as the first file to the OS, it is the same file. Each hard link is a perfect pointer to one and the same file, not ‘just a link’ … think of something more bidirectionally, similar to a mirror.
Only the total size of two (or more) incremental backups will be smaller than the sum of both (or all), depending on the difference in the data files.

But when you create a new backup folder (in the Settings) and take a backup the source file will be copied again into the new back up folder, requiring the same space there, too.

[Alan16]

I see two questions here.
The first is the difference between 5.5 and 3.2 GB -
I can not explain but suspect not all files were backed up: Compare them using Nemo and check the log (menu "View").
In my case, when using B.I.T as normal user, there are warnings and files missing because of deficient permissions (e.g. my foxclone test images require root permission to access - unfortunately Nemo offers “Copy” but fails to do it as standard user …).
- Otherwise original and backup must have the same size!

The second:
Yes, the backups are incremental, but because of using Rsync (hard links, see https://www.geeksforgeeks.org/soft-hard ... unixlinux/) the incremental (hard) link presents the same file size as the first file to the OS, it is the same file. Each hard link is a perfect pointer to one and the same file, not ‘just a link’ … think of something more bidirectionally, similar to a mirror.
Only the total size of two (or more) incremental backups will be smaller than the sum of both (or all), depending on the difference in the data files.

But when you create a new backup folder (in the Settings) and take a backup the source file will be copied again into the new back up folder, requiring the same space there, too.

Thanx sanmig, I only read your reply just now.

Yes, I found the answer to the first question: there’s a file excluded in the settings, and its size is 2.3 Gb, which makes up for the difference.

As for the second question:
So a hard link presents the same size as the file it points to.
When I delete data in that file, it becomes smaller. I save the file and take a new snapshot. Then the new hard link should present a smaller size then the old hard link.

I’ll experiment with this to see it.