NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Basics – What inode did that file have when it was backed up?

Posted by Preston on 2009-08-29

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/
[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.

Advertisements

2 Responses to “Basics – What inode did that file have when it was backed up?”

  1. 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.

    • Preston said

      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.

Sorry, the comment form is closed at this time.

 
%d bloggers like this: