I had an odd question recently from a customer – they wanted to know whether NetWorker could tell them what inode a file had when it was backed up. Thankfully, having previous experience with NetWorker and AdvFS, I knew that NetWorker did keep track of inode details during the backup.
The way to find this out is to use the nsrinfo command. Let’s say we’ve got a directory/mount-point, ‘/var’, and we want to see what inode it had during backup. In this case, the command that you would run would be:
# nsrinfo -N /var/ clientName
(Note the use of “/var/”, not “/var”.)
So if I want to find this information out for the client ‘nox’, I’d run:
[root@nox ~]# nsrinfo -vV -N /var/ nox
scanning client `nox' for all savetimes from the backup namespace
UNIX ASDF v2 file `/var/', size=660, off=3456572, app=backup(1),
date=1251459999 Fri 28 Aug 2009 09:46:39 PM EST, fid = 2304.2147905,
file size=4096
ndirentry->2639214 ftp/
(The rest of the output has been snipped.)
So where, you might wonder, is the inode detail stored in all of this? Look for the ‘fid = X.Y’ part of the output; the inode number is Y – in this case, 2147905. We can verify that by running stat against the directory:
[root@nox ~]# stat /var File: `/var' Size: 4096 Blocks: 16 IO Block: 4096 directory Device: 900h/2304d Inode: 2147905 Links: 25 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
As you can see, the inodes match.
So there you have it – you can use NetWorker to confirm/check what inode number a file or directory had when it was backed up.
Only guessing, but would this be useful for dealing with hard links that were assumed to be shared, or for recovering missing information from the filesystem?
I can’t think of any other uses for this information, but it’s nice to be able to get the info from networker.
The customer was non-specific on why they wanted this information; sometimes it can be as simple as “because someone asked for it”. I assume though yes, it could be used to say, evaluate the backups to determine what files shared the same inode and thus were hard-linked.