The optimal size of the log varies widely per environment, workload, and how much write IO your workload performs.
A larger or smaller log doesn't make you any faster or slower
A larger or smaller log doesn't have any bearing on a 10GB data volume versus a 10TB data volume, for instance
A larger log simply collects and retains more write IOs before they're wrapped out. A larger log allows an interruption in service between the source and destination computer – such as a network outage or the destination being offline - to go longer. For example, your log is configured to hold up to 10 hours of writes and the network goes down for 2 hours. When the network returns, the source can play back only the delta of unsynced changes back to the destination. If the log holds 10 hours and the outage is two days, the source now has to play back from a different log called the bitmap – and is typically slower to get back into sync. Once in sync it returns to using the log.
Storage Replica relies on the log for all write performance. Log performance critical to replication performance. You must ensure that the log volume performs better than the data volume, as the log serializes and sequentializes all write IO. You should always use flash media like SSD on log volumes. You must never allow any other workloads to run on the log volume, the same way you would never allow other workloads to run on SQL database log volumes.
Important
Microsoft recommends that the log storage is faster than the data storage and that log volumes must never be used for other workloads.
You can get log sizing recommendations by running the Test-SRTopology tool. Alternatively, you can use performance counters on existing servers to make a log size judgment. The formula is simple: monitor the data disk throughput (Avg Write Bytes/Sec) under the workload and use it to calculate the amount of time it takes to fill up the log of different sizes. For example, data disk throughput of 50 MB/s causes the log of 120GB to wrap in 120GB/50MB seconds or 2400 seconds or 40 minutes. So the amount of time that the destination server could be unreachable before the log wrapped is 40 minutes. If the log wraps but the destination becomes reachable again, the source would replay blocks via the bit map log instead of the main log. The size of the log doesn't have an effect on performance.
ONLY the Data disk from the Source cluster should be backed-up. The Storage Replica Log disks should NOT be backed-up since a backup can conflict with Storage Replica operations.