Right now, this backup/restore process isn't very slick or automated,
but it better than the old way.

What's the old way? From the FAQ: 
http://parlweb.parl.clemson.edu/pvfs/pvfs-faq.html#backup

--------- FAQ
The problem with backing up PVFS comes from a design decision made by
me (Rob) with respect to handing out unique handles (inode numbers)
for files. The manager has to pick these numbers, and at the time it
seemed like a good idea to just use the inode number from the actual
metadata file. This was convenient because the data was already stored
(as part of the file) and was guaranteed to be unique by the file
system.

This is great, but it becomes a real problem for backups -- if you go
to recreate the metadata directory it's next to impossible with
standard tools (eg. tar) to get the inode numbers back to the same,
especially since tools like tar don't save them anyway. This is all
that keeps one from just tar'ing up all the local directories that
make up PVFS and backing it up in that manner.
--------- FAQ

We have the technology.  We can make this better, stronger, faster...but
it will take several steps.  It might just be easier if you remake your
pvfs volume.  You didn't have important data on there, did you?  Of
course you did.  ok, here we go...

In short, the process looks like this:
. back up data and metadata, saving an inode-to-filename mapping
. restore from backups 
. make a new inode-to-filename mapping
. merge the old and new inode-to-filename mappings
. based on this merged mapping, move the pvfs data files from their old
  locations to their propper places in the filesystem heirarchy.
. fix up some of the data inside the metadata files

Step one: collect old mgr inode-to-filename mappings
. change to the pvfs metadata directory
. run 'gather-inodes' and direct the output to a file for later.

Now go ahead and tar up the metadata directory on the mgr and the data
directories on all the iods. 

[ After you have restored your metadata and data directories... ]

Step two: collect new mgr inode-to-filename mappings
. restore the mgr directory. 
. change to the pvfs metadata directory
. run 'gather-inodes' and direct the output to a file for later. 

Step three: merge the mappings
. run 'inode_merge old_inode_to_filename_map new_inode_to_filename_map'
  ( those files you saved for 'later'?  'now' is 'later' ).  redirect
  to a file for the next step

Step four: the real meat
on every io node perform the following:
. change to the pvfs data directory
. run 'update_datafile_names merged_inode_mapping_file'

Step five: beauty is only skin deep, but an inode is embedded in the file
. go back to the metadata server
. run fix_inodes over the metadata directory to update the inode in the
  metadata file:
	find /path/to/metadata/dir -type f -not -name .iodtab \
	      -not -name .pvfsdir -exec ./fix_inodes {} \;
. run fix_pvfsdir over the metadata directory to update the unique id 
  in the .pvfsdir files
	find /path/to/pvfs_metadata_dir -name .pvfsdir -exec fix_pvfsdir {} \;

There you go.  Fire up your iod and mgr daemons and pvfs is back in
action.
