Backintime always does full backup, even when no files have changed

[MrAnon-dev]

Hi!

This is my enviroment

• Ubuntu 20.04
• Backintime 1.3.1 from official PPA
• Snapshots to USB hard disk, NTFS partition

And the problem is what every snapshot that I do, BIT copy again unchanged files, ¿how can I change that? I want to incremental backups

after read some issues #1207, #1093, #1128, #1086 I try add this to config but no luck...

profile1.snapshots.rsync_options.value=--no-perms --no-group --no-owner

I also tried install version 1.1.x but doesn´t work, dependencies problem.

thanks!!

[AlexSchr]

Your additional options should help to get the old v1.1.x style permission handling.
But this is only relevant when switching from BiT < 1.2 to BiT >= 1.2.
When the previous backup was already in BiT >=1.2, the new one should definitely not be a full backup, when no files have changed.

I guess there is some issue with NTFS.
NTFS as file system for the backup location should work according to #924, but it is not recommended. Some people report problems with it (e.g. in #762).

[MrAnon-dev]

Hi AlexSchr,

Well, I did a test with ext4 on a usb stick and it seems to have worked fine.

So there is no way for incremental backups to work on NTFS? if it's a problem with permissions mismatch, can't I get rsync to ignore them completely?

Thanks for the help!

[buhtz]

Is this related #988?

[emtiu]

Hi @MrAnon-dev, I'm sorry to say that this will always happen with NTFS, because NTFS doesn't support hardlinks. I'm closing this Issue, but feel free to re-open or discuss further if you have more questions.

[Depixelate]

@emtiu , this article by Microsoft says that NTFS does support hard links:

[emtiu]

Hmm, I see. Thanks for the information! Then I guess it depends on the NTFS driver whether or not rsync can really use those NTFS-native hardlinks.

I guess it's worth keeping this open to find out whether we can/should support NTFS as a target filesystem in principle.

[aryoda]

it depends on the NTFS driver whether or not rsync can really use those NTFS-native hardlinks.

I have just opened an issue for ntfs-3g to add documentation if Linux hardlinks are supported:

tuxera/ntfs-3g#91

Edit: NTFS-3G does support hardlinks so BiT should work (with the now known issues described in #988 (comment))

[Gabriel-p]

I' getting this issue on an external SSD drive formatted as ext4.

• elementary OS 7.1 (based on Ubuntu 22.04.3)
• Linux 6.2.0-34-generic
• Backintime 1.3.3-3

[aryoda]

@Gabriel-p Could you please double check that your snapshots are really a full copy (= using the same amount of disk space) or if only changed files are copied (unchanged files are hard-linked, use ls -la or stat to check this for files in the snapshot)?

If you are affected by this issue: Could you please apply the workaround described in our README and tell us if it works?

Note: Despite the workaround still some files are unnecessary duplicates because of the open issue #988 (comment)

[Gabriel-p]

I think I was wrong. I just checked and although the folder sizes seem equivalent, it appears to be because of hard links. This is what I did:

$ du -hc --max-depth=1 1/   
57G	1/20231011-190002-345
109M	1/20231012-120002-619
123M	1/20231013-095738-704
135M	1/20231011-164539-515
57G	1/
57G	total

Also if each of those folders really occupied ~57 Gbs each, my 250 Gb SSD would be out of space already.

[buhtz]

I always think about a GUI application to better visualize the difference between file size and "on disc occupied size"... 🧠

[Gabriel-p]

I always think about a GUI application to better visualize the difference between file size and "on disc occupied size"... 🧠

Would be great. My confusion originated from using Filelight to check sizes...

[buhtz]

IMHO this is about the hard-link feature which is documented in the FAQ for example. So closing this.
Feel free to reopen it.