2

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.

Improve this question

3 Answers 3

Reset to default
1

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?

Improve this answer
5
  • 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, 2010 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, 2010 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, 2010 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, 2010 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, 2010 at 23:26
2

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.

Improve this answer
0
1

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.

Improve this answer
2
  • Great response, bit worried this might take a while to run but thank you very much.
    – Chopper3
    Feb 16, 2010 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, 2010 at 22:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .