On 1/26/2011 4:55 PM, Dr. Ed Morbius wrote: > > The specific solution is 'umount -fl<dir|device>'. > > The general solution's a little stickier. > > I'd suggest the automount route as well (you're only open to NFS issues > while the filesystem is mounted), but you then have to maintain > automount maps and run the risk of issues with the automounter (I've > seen large production environments in which the OOM killer would > arbitrarily select processes to kill ....). > > Monitoring of client and server NFS processes helps. If it's the filer > heads which are failing, and need warrants it, look into HA failover > options. > > Soft mounts as mentioned won't hange processes, but may result in data > loss. This is most critical in database operations (where atomicity is > assumed and generally assured by the DBMS). If the issue is one of > re-running a backup job, and you can get a clear failure, risk would be > generally mitigated.
Actually, since the original question involved access to backups, I should have given my usual answer which is that backuppc is the thing to use for backups and it provides a web interface for restores (you pick the historical version you want and either tell it to put it back to the original host or you can download a tarball through the browser). Very nice for self-serve access. It does want to map complete hosts to owners that have permission to access them but with a little work you make different areas of a shared system look like separate hosts. -- Les Mikesell lesmikes...@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos