
I am having difficulty in setting up backintime-qt to function as I expect; I would appreciate advice from experienced users. I’m running BIT 1.4.1-1 under Linux Mint 21.2 Cinnamon (based on Ubuntu Jammy), with Kernel 6.2.0-37. Hardware is 11th Gen Intel Core i5-11600, with 32 GiB. /Root and /Home are on separate NVME SSDs. Back up is to a 1TB 7200 rpm HDD. An nVidia 3060 GPU with 12 GiB of memory is installed. This post is about the process of restore, which seems to operate different to my expectation. That expectation is that a file which exists in the ‘original’ location in the file system at the time of restore will be overwritten by the file of the same name from the ‘full’ backup. This will in turn be overwritten by any later files of that file name in the sequence of incremental backups, from oldest to most recent, no matter how many incremental backups there are. The final state of the file will be identical to the newest incremental backup prior to the restore operation. There will be just a single file ‘A’ in the original location.. This is the process that every backup application, using incremental backups, appears to work, according to my understanding of the application descriptions that I have read on Google and YouTube. In contrast. the Man Page, for BIT, under the heading ‘DESCRIPTION’ says: “When you restore a file ‘A’, if it already exists on the file system it will be renamed to ‘A.backup.currentdate’.” I understand ‘currentdate’ to mean ‘current date and time to a sufficient resolution for file name to be unique’ – probably to the millisecond. The manual page statement then implies that after the restore, my data set will contain a file ‘A’ plus as many versions of the file A.backup.currentdate’ as there are unique versions of File A in the incremental backups. This could be 10’s to hundreds of additional file versions for EVERY file in my data set which has been changed in the period from the initial, or ‘full’ backup, to the last incremental backup. This could result in the original file location being filled to capacity, at which point I assume the restore will be terminated. This is not what I want and, more to the point, doesn't seem to be generally desirable. What have I misunderstood?