Tillman Hodgson wrote:
Could you use something like ssh to transfer the files rather than
needing NFS? (I don't know if you mentioned what the NFS-end box was...).
That's a good idea. In this case the NFS-end box is an Infrant appliance
so I don't think I can use scp. I'll check deeper into it -- if it can
do scp, that gives me more options.
No idea what an Infrant appliance is, but makes ssh less likely.
Yes, that's certainly an issue. Presumably you can lock down the
directory perms to be root only or root/operator though. Depending on
setup and money, backing up the backups to tape would give more safeguards.
I'm also not clear why you think that keeping the NFS partition mounted
all the time is so bad. If there is no access then surely the overhead
That's true, there's no real performance hit. It's not the overhead I'm
worried about, it's minimizing the exposure of the backups volume to
problems. A network filesystem that isn't mounted is one that's much
harder to accidently rm files from and such :-)
Can you mount sub-directories from the share as separate mounts? E.g.
create simple directories called daily, weekly and monthly on the share,
and mount each separately? Then you'd just have to move some files
around rather than re-create the share. Plus with a single share you
don't have to decide in advance how much space each specific directory
Your other alternative is to use lockfiles to control when things get
mounted/unmounted. If the control file is locked, you wait until it's
unlocked (or bomb with an error, whatever). Trivial in perl, and
lockf(1) looks like the way to go with shell.
That's the scripting magic that I mentioned. It looks like this is
likely the best solution with my current volume arrangement. In
hindsight, I think should've used three shares instead of one and then
the daily, weekly and monthly mounts wouldn't conflict with each other.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"