When to run anti-entropy repair

For most use cases, run anti-entropy repair in the following situations:

Routinely to maintain node health and consistency, regardless of the type or frequency of writes.
When recovering a node after a failure while bringing it back into the cluster.
To update data on a node containing infrequently read data, and subsequently does not get read repair.
To update data on a downed node.
When recovering missing data or corrupted SSTables, you must run non-incremental repair.

Guidelines for running routine node repair

Run full repairs weekly, biweekly, or monthly. Monthly is generally sufficient, but run more frequently if warranted.
Use the parallel and partitioner range options, unless precluded by the scope of the repair.
Migrate off incremental repairs and then run a full repair to eliminate anti-compaction. Anti-compaction is the process of splitting an SSTable into two SSTables, one with repaired data and one with non-repaired data. This has compaction strategy implications.
Run repair frequently enough that every node is repaired before reaching the time specified in the gc_grace_seconds setting. If this requirement is met, deleted data is properly handled in the cluster.
Schedule routine node repair operations to minimize cluster disruption during low-usage hours and on one node at a time:
Increase the time value setting of gc_grace_seconds if data is seldom deleted or overwritten. For these tables, changing the setting minimizes impact to disk space and provides a longer interval between repair operations.
Mitigate heavy disk usage by configuring nodetool compaction throttling options (setcompactionthroughput and setcompactionthreshold) before running a repair.