does auto remove smart mode merge incremental backups?

No, when BIT take a new snapshot (and there is an older one) it make hard links from previous snapshot for unchanged files and it does a full copy of changed files. This is why it is safe to remove a snapshot.

Hi Dan,

I've read this discussion and I'm afraid I did not understand it either.

You say that unchanged files are represented by hardlinks and changed or new files by copying. Where does BIT copy these files? If they were in the folder of the removed snapshot they will also be deleted.

For example:
I have done an initial snapshot on Sunday and then had daily snapshots of a folder for one week.
On Tuesday file1 has changed - so I assume that the original file1 is in the initial snapshot folder and the altered one is in the Tuesday snapshot folder. The Monday snapshot would contain a hardlink to the file in the Initial folder and the others contain hardlinks to the file1 in the Tuesday folder.

Now I remove all snapshots except the initial and let say the saturday snapshot. From my undestanding the Tuesday folder will be removed and therefore also the modified file1. The hardlink in the Saturday snapshot would direct to an empty position. This means I could not restore the modifed file1 in case I have deleted it today. Only the version contained in the initial snapshot would be available.

Did I get this wrong?

Thanks,
Guenther

Hi all,

I'm with Guenther on this one. Please explain the exact workings of 'smart remove'.

Best regards,

Stijn

I am also interested in the answer to guenni's question. I have the same doubts...

If you create a new file on a Linux filesystem (e.g. ext3) the data will have a unique number that is called inode. The path of the file is a link to this inode (there is a database which stores which file point to which inode). Also every inode has a counter for how many links point to this inode.
After you created a new file the counter is 1. Now you make a new hardlink. The filesystem now just has to store the new path pointing to the existing inode into the database and increase the counter of our inode by 1.
If you remove a file than only the link from the path to that inode is removed and the counter is decreased by 1. If you have removed all links to that inode so the counter is zero the filesystem knows that it can override that block next time you save a new file.

First time you create a new backup with BIT all files will have an inode counter = 1

snapshot0:
path inode counter
fileA 1 1
fileB 2 1
fileC 3 1

Lets say you now change fileB, delete fileC and have a new fileD. BIT first makes hardlinks of all files. rsync than delete all hardlinks of files that has changed and copy the new files.

snapshot0:
path inode counter
fileA 1 2
fileB 2 1
fileC 3 1

snapshot1:
path inode counter
fileA 1 2
fileB 4 1
fileD 5 1

Now change fileB again and make a new snapshot

snapshot0:
path inode counter
fileA 1 3
fileB 2 1
fileC 3 1

snapshot1:
path inode counter
fileA 1 3
fileB 4 1
fileD 5 2

snapshot2:
path inode counter
fileA 1 3
fileB 6 1
fileD 5 2

Finally smart-remove is going to remove snapshot0. All that is done by smart-remove is to 'rm -rf' (force delete everything) the whole directory of snapshot0

snapshot0: (path no longer exist)
path inode counter
        1 2
        2 0
        3 0

snapshot1:
path inode counter
fileA 1 2
fileB 4 1
fileD 5 2

snapshot2:
path inode counter
fileA 1 2
fileB 6 1
fileD 5 2

fileA is still untouched, fileB is still available in two different versions and fileC is gone for good. The blocks on your hdd that stored the data for inode 2 and 3 can now get overriden.

I hope this will shed a light on the 'magic' behind BIT. If it's even more confusing don't hesitate to ask ;)

Regards,
Germar

Hi Germar,

Thank you for clearing this up! I think I understand the inner workings of BIT much better now. :)

Best regards,

Stijn