Solaris

I did some more testing. "find / -inum <INODE> -print" command is finding actual file names that are not showing up in 'lsof' output sometimes, still for many indoes its returning empty output [ 100% of time still shows a entry under /proc/<PID>/fd/<FD> ].

Whatever the intent and concept may be for this hiding,, I am getting headache.

There is no intent or concept. "lsof", at least on Solaris, is an unsupported third party hack. As far as I know, it directly accesses undocumented kernel structures from /dev/kmem.

What is the problem you are trying to solve by investigating your processes open files ?

For a manual disaster recovery project[to a different data center], we are trying to understand the scope. \\
What if we take a full backup of disk used by running apps, while they are still running. \\
What are all the runtime files that might get affected. Just to have an idea, in case if stopping all apps \\
is not feasible due to downtime and other ill effects..

That seems quite risky depending on the application, especially if the backup of evolving files isn't strictly synchronous.

Quite the understatement.

If the plan is to take some sort of snapshot of the raw disk underlying an active and mounted file system, there's no guarantee at all the the snapshot would be consistent or even mountable.

If the plan is to use something like ZFS snapshots, that would at least produce a consistent file system on the remote system(s). Then there would "only" be problems at the application level.

The files under /proc are imaginary, but the flat files have names that disclose their inode and device. If you cannot "find" a path name (there may be several links), then there are no links, which is to say it has been removed but is still open on one or more processes. For instance, tmpfile() does this so if your proc crashes, the file space is released. Then, your only clue to the original path is the inode contents or the fd # implying an order of opening.