Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a single OEL/RHEL 5.3 server with a 'source' mount to a 16TB 10Gbps NFS share and a 'destination' mount to a 16TB FC LUN formatted with OCFS2.

I need to ensure that the destination matches the source and I'm happy that they're out of sync by even as long as an hour or two - that bit is easy using rsync.

But it would be nice to know that in the event of someone deleting every file on the source that it's not deleted by rsync at the next scheduled period - that it detects that it's about to remove say >20% of the source from the destination and chooses to halt.

Is that sort of thing possible or would a different tool be more appropriate for this problem? I have flexibility with this machine's OS and file system but not the actual connection type to both storage boxes.

Thank you.

share|improve this question

3 Answers 3

up vote 1 down vote accepted

In the case of any NFS errors you should in theory be protected (man rsync):

If the sending side detects any I/O errors, then the deletion of any files at the destination will be automatically disabled. This is to prevent temporary filesystem failures (such as NFS errors) on the sending side causing a massive deletion of files on the destination.

You could also limit the damage with --max-delete=NUM so only so much gets deleted. You could then restore that part from tape or whatever you use.

Really though, might the actual problem be that someone can delete all of the files in the source? and shouldn't you just stop that with permissions?

share|improve this answer
    
Thanks for the max delete tip, I'm no rsync expert so I'm really grateful. It's actually a series of automated scripts that create and delete files so I'm always wary of something going haywire, permissions or not. Thank you. –  Chopper3 Feb 16 '10 at 20:11
    
Chopper3: Ya, that makes sense. To have permissions help with that though you might be able to have the script run as a user that doesn't own the directories (Emphasis because permissions for deleting are on the directory the files are in, not the files themselves). This user could be a member of the group for all the directories. Then that group would only have read permissions and execute permissions on the directory. To ensure they permissions stay correct, you could have a find script that runs and chmods accordingly. –  Kyle Brandt Feb 16 '10 at 20:34
    
Setting the sticky bit on directories so only the owner can delete the files (and su of course) might help as well. –  Kyle Brandt Feb 16 '10 at 20:44
    
Oh if it were only that simple :( it's perfectly acceptable for one machine to delete another's files. Thanks again. –  Chopper3 Feb 16 '10 at 21:50
    
Figured you had probably thought it through, permissions might end up being the answer for someone else though. –  Kyle Brandt Feb 16 '10 at 23:26

You could use rsync's --max-delete=NUM to tell rsync not to delete a specified number of files, where NUM is some number less than approx 20% of your files, and the --backup/--suffix options to rename files on the target rather than delete.

share|improve this answer
    
Thanks for the tips, good work :) –  Chopper3 Feb 16 '10 at 20:12

You could hack something together to just count the files. Actually, something like:

(cd /source && ls -FalR . ) | sort > /root/sourcelist.$$
(cd /dest && ls -FalR . ) | sort > /root/destlist.$$
diff -u /root/sourcelist.$$ /root/destlist.$$ | egrep '^-' | wc -l

Will give you how many files you're about to remove. Whack something around that that knows how many is too many, and run that before your sync.

share|improve this answer
    
Great response, bit worried this might take a while to run but thank you very much. –  Chopper3 Feb 16 '10 at 20:12
    
It's quick enough. Rsync has to talk through a list of files anyway, so it's not like it will be much faster :) You could gain a bit of speed by using find . in the place of ls -FalR, I guess. –  Bill Weiss Feb 16 '10 at 22:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.