Can KBackup or KUP use Checksum to determine changes in files to be backed up

Help
,
1

Is it possible for KBackup and/or KUP to use file checksum when they create backups to check for changes? So that instead of access time or modified time that is used to backup the modified files, checksums (MD5/6 or CRC32/64 or SHA1 or SHA256, etc ) are used? If yes how can it be done?

2

KUP Versioned Backups use bup to do the work and if I understand the design documentation correctly bup uses SHA1.
I’m not familiar with KBackup.

1 Like
3

Kup uses bup as its backend, and it can/might be using SHA1, but I have no idea if Kup uses this for its incremental backups, or how to tell.

4

What I meant was that in case of KUP application once the external data storage, i.e. network share or external disk, becomes available then Kup will automatically start copying the latest changes. This it does on the basis of the file last access/modify time in the filesystem. Rather than use that, is it possible for KUP to use checksum functionality in which it creates a hash and if the hash has changed then only it copies the file?

KBackup on the other hand creates a single tar file for the backup. And if we want to do an incremental backup then also it uses file access time rather than file contents for checking if it has changed.

5

Kup is just a front-end GUI that uses Bup to do the work, depending on the type of backup.

But I forgot that if just syncing, it uses rsync. Which does not create or use hashes, iirc.
Incremental backups would seem to include various attributes, including SHA1.

You can see the specific commands used for a plan by peeking at the log files in ~/.cache/kup

Looking at one of my incremental plans, it runs bup save, which does create hashes for the files, according to its man page.

My sync plan just uses rsync -avX

6

I did this experiment which I think confirms that kup/bup uses the sha1 hash to determine if a file needs backing up:

  1. Run a backup
  2. make a copy of a simple text file that is included in the backup plan using cp -p orig copy to preserve the original timestamps
  3. edit the original file to change its hash
  4. use touch --reference=copy original to reset the timestamps of the original file to what they were before the edit
  5. from the terminal run the bup index command that’s shown in the log file
  6. from the terminal run the bup save command, but capture its stderr messages. These show an ‘M’ next to the original file indicating bup thinks it’s modified