For backup, I'd be worried about:
- what kind of network connection you have between the production workload and the backup set, which will dominate the performance more than the drive buffer
- what happens when one of the drives fails in the backup array (are you onsite to swap a drive?)
- what kind of SLA you have on your dataset/how quickly you need to be able to recover; are you live replicating the DB elsewhere or is this your primary backup? Or is this a lagged/offsite copy that will be infrequently used?
- idle power usage of your drives
If you have multiple 10Gbps links between the servers, then the number of spindles and/or buffer might actually start playing into things.
What OS are you running though? Is it in a VM/virtualization? For ECC/bitrot, using ZFS or ReFS (if using hardware RAID) might be good options. I'd personally use ZFS here, but it depends what your DB is running on, and if you're using NFS, SMB, etc. between your servers. Is that what you're doing, by the way? Transferring data across the network to another server in the same room?
I don't think the buffer or AF plays into this at all. I think the question really is size of drive/number of spindles in your case. And this is generally a question/balance of power, performance, and recoverability when a drive fails. And possibly the number of drive bays in your enclosure. If you're using hardware RAID 5 I wouldn't go more than 6 drives, for example. If you're in an enclosure, I try not to fill all the bays, and give myself some headroom for new/replacement drives when this set needs to be decommissioned/needs drives replaced.
If you're going hardware RAID, then I'd try not to exceed 6 drives per set. Buy whatever size drives needed.
If you're doing ZFS RAIDZ2, then 6 drives is where you start. But then I question why you're doing RAIDZ2 for a backup.
Personally, I'd do more copies of your data (i.e. 2 or 3 separate snapshots of the data, taken at different times, etc.) rather than building in more redundancy for your single backup snapshot.
How often do you think you'll need this backup? What do you do most frequently with the backup? Rollback transaction logs?
If you want more guidance, then you should reframe your questions/provide more information:
- What OS are you running on the production workload? Is it in a VM that you can replicate/snapshot?
- What enclosure would these drives sit in?
- What network connection will be running between the servers/In case of failure, how quickly do you need to recover the data?/How quickly do you need backups to complete? How often will you be backing up?
- What's your ideal recovery timeline/timeframe/scenario? How often do you expect to do that?
- Is this your primary/only onsite copy of the database? Or how many copies will there be? Do you need multiple in-time snapshots/lagged copies?
- Would this be running on the same server as production (ugh) or a separate box?
- How much growth of data are you anticipating and how much headroom do you need on your backup array?
