Using inode number but not inode count

Getting Help
1

Dears,

Using restic backup on different configurations, I’ve observed that in some configuration I had to use the --ignore-inode switch to restic backup command.

As the inode number of backuped files is constant, I was a little surprised/disapointed!

Finally, I’ve understood that the problem is coming from the count of hard links.
Of course as in this configuration, the root of backuped files is already a backup.

Here, my old backup-rotate script do something like:

cpylink=$(date -r "$backups/$root" +"$root-%Y-%m-%d-%Hh%M")
[ -d "$backups/$cpylink" ] ||
    cp -al "$backups/$root" "$backups/$cpylink"

(from more than 20 years ago;)

Then now, if I try to cd $backups && restic backup $root, the ignore-inode flag is required, even if all files in $root keep a constant inode number: all files will see the count of hard links modified.

So I think:

  • Considering count of hard link in the same flag than inode number is wrong.
  • There must be a different flag!
  • If the only thing varying in a file entry is the numbers of hard links, having all other properties (dates, owner, perms, dates and inode number) constant, they could be considered as unchanged by default?

Anyway, many thank for sharing your work and happy new year!

2

Hey, welcome to the forum :slight_smile:

The --ignore-ctime flag might be what you’re after, rather than --ignore-inode. A quick test on my system shows that ctime/change time gets updated when making a hard link (because the file metadata has been updated):

❯ touch file
❯ stat file
  File: file
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 0,39	Inode: 10272969    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  user)   Gid: ( 1000/  user)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2024-01-02 11:48:59.849067349 +0000
Modify: 2024-01-02 11:48:59.849067349 +0000
Change: 2024-01-02 11:48:59.849067349 +0000
 Birth: 2024-01-02 11:48:59.849067349 +0000
❯ cp -al file file2
❯ stat file
  File: file
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 0,39	Inode: 10272969    Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/  user)   Gid: ( 1000/  user)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2024-01-02 11:48:59.849067349 +0000
Modify: 2024-01-02 11:48:59.849067349 +0000
Change: 2024-01-02 11:49:10.800302768 +0000
 Birth: 2024-01-02 11:48:59.849067349 +0000

From the docs, restic will re-scan a file if it’s ctime has changed, so that might be what you’re seeing.

1 Like
3

Many thanks shd2h,

This did the job!

But now, I don’t understand why --ignore-inode did the job too !?

4

@F-Hauri if you follow the documentation link you can see the answer, as both options ignore ctime changes:

  • --ignore-ctime: require mtime to match, but allow ctime to differ.
  • --ignore-inode: require mtime to match, but allow inode number and ctime to differ.
5

Thanks GuitarBilly,

I did just read man restic-backup and restic backup --help.

  • –ignore-ctime[=false] ignore ctime changes when checking for modified files

  • –ignore-inode[=false] ignore inode number changes when checking for modified files

Just found this in html2text </usr/share/doc/restic/html/040_backup.html :wink: