1

background: Being somewhat of a coward I have up to now dd whole filesystems for backup. Major drawback has become the excessive use of memory for those complete backups (which unfortunatelly also included free blocks)

question I would like to backup now only the files inside the filesystem, but yet be able to recreate the filesystem if need be. While the data can be easily extracted (i.e. via rsync -a),
I wonder, if there are some cases I overlook where for instance the inode number assigned to the file would matter?

This is especcially with the background of backing up the / root filesystem with the system on it. I am not so much worried about the /home/ filesystem but would be imaginative enough to expect that some strange thing might be when restoring the / root filesystem and suddenly the inodes have changed?

A good answer would include a most comprising list of cases in which the inode number might matter and cause eventually trouble.

update Some experimenting reveals that for instance the hard links (naturally referencing the same inode) might need some attantion. Unsure if they need to have to be reassigned necessarily the same inode.

Luckily the number of hardlinks on a plain ubuntu 12.04 here is only about 10 files (so that I can script-record them and repair if needed and rsync -a would not care about the inode number)

Example one case I think important is the case of selinux security module as it bassically uses inode numbers. So this is already one case, but maybe there are others.

Update2 I just run a test backing up and restoring a dummy 12.04 Ubuntu system using rsync -aH while reformating the partition in between to setup a new ext4 by mkfs.ext4 /dev/sdX -U oldfsUUID. Essentially when the files where restored all the inodes used most often where not anymore related to the original ones. Luckily hence it seems that for this one case of my Ubuntu 12.04 setup the inodes did not seem to matter. I am aware that this does not prove much. I still would appreciate an answer with a list of problematic cases. The one selinux I already mentioned, but I think there might be more and hence the chance for a good answer from somebody who knows.

  • Have you considered compressing the dd output after doing a free block wipe to a single byte value before doing the backup? That would make the free space very compressible and the resulting overhead probably negligible. – Anthon Oct 12 '14 at 7:53
  • @Anthon Thanks, bright though! I did this indeed,yet had the trouble that besides empty space I also have much of the very same files with same data backuped. So while I want to be able to go back in time to any of the backup points I do not want to waste space double storing equal files. So eventually I would use some database driven accounting. Still the question here is if I need to care about inode numbers if I want to go back in time backupwise. – humanityANDpeace Oct 12 '14 at 7:59
  • 1
    regarding hardlinks rsync has -H / --hard-links switch to preserve them. – artm Oct 12 '14 at 8:11
  • Ok that makes sense. I had focused on your comment about the complete backups including free blocks. – Anthon Oct 12 '14 at 8:52
  • 1
    I don't know of any filesystems that allow you to create an inode with an arbitrary user-supplied number, and there are few extant backup programs that bother recording the inode number in the dump. When they did, the main use was when you had a damaged filesystem and fsck placed unattached inodes into files named /lost+found/#nnnn and you wanted to look up where those files really belonged. – Mark Plotnick Oct 12 '14 at 20:52
1

Inode numbers don't matter to normal applications. This is partly because there's little use for inode numbers, and partly because if an application depended on inode numbers, it would stop working after a backup-and-restore cycle. So backup systems don't restore the inode numbers, so applications don't depend on them, so backup systems don't need to restore the inode numbers.

Most approaches to backups wouldn't even be able to restore inode numbers. The filesystem driver in the kernel uses whatever inode is free when creating a file, there's no way to constrain that from applications.

Some filesystems don't even have inode numbers.

The one thing applications use inode numbers for is to test whether two paths designate the same file: compare the device number and inode number, at specific point in time. The device number and inode number don't have to remain constant over time for this. Backup programs themselves do this to detect hard links.

There's no way to open a file given its inode number, or get at a file to a path given its inode number (excluding debugging tools requiring access to the underlying block device). On most filesystems, the path points to the inode, but the inode doesn't contain a pointer to the directory containing the file, so this couldn't be implemented without traversing the whole filesystem. Besides the file could even be deleted (as in, might have a hard link count of 0, waiting to be closed before its contents gets deleted and its inode freed).

SELinux uses inodes to track contexts, not inode numbers. SELinux contexts are stored using paths, like everything else.

rsync -AHX is a safe and common way of making backups.

I can think of one application that uses inode numbers: some versions of Rogue, one of the first full-screen terminal-based games, which motivated the Curses library still used today. It stores the inode number in a save file, to prevent casual copying of save files. I've never seen that done in a “serious” application.

  • Ugh. There's always a complication trying to do something clever. Namely, I have a database of metadata for all my files including hash, inode number, etc. for de-duplication and other purposes. If a backup would have the same inode number for each file my work would be easy and quick - otherwise, having to hash every file in the filesystem does not seem like a good or efficient way to do things. However, having to dd the entire filesystem every night also does not seem workable. – Michael Mar 25 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.