Slow RAID0 to RAID0 on 314s with bonded gigabit

1. If performance is key and you want to limit any performance degradation over time as much as possible create new shares with bit-rot protection disabled and snapshots disabled.

2. If you SSH in and run the 'top' command you get some good output on CPU utilisation.

I probably would have gone for the 516 for this use case. Furthermore with a single client you would like only saturate one link.

Thanks for that. I disabled both of those but I don't know if it will take effect while it's in the middle of a backup. I'll experiment with multiple client downloads/uploads later when it's finished.

At any rate, the sending NAS currently has over 70% CPU idle, while the receiving NAS has over 50% CPU idle, so I can probably rule that out as a problem.

Both generally have less than 100MB of RAM free, but I imagine that's not likely to be an issue unless most of that was already used up before I started the transfer. Once again, I'll check that later after this initial backup finishes.

Check if the memory is swapping. If it's not swapping then you have plenty of RAM. We use memory for caching to improve performance and free up the memory used by caching as needed.

Oh yeah, I forgot to mention that the swap space wasn't being touched, so all good.

Antivirus is disabled?

What protocol are you using the backup?

I turned off AV when I saw how slow the backup was going. I assume any improvement should have become apparent immediately, but there was none. That same backup is still going though. 3TB takes a while at this speed :p

The protocol is Windows/NAS, which may have higher overheads. I was keeping it simple while I worked out how set up backups. Do you recommend any protocol in particular?

On a side note: I know ReadyNAS can't be directly attached to a computer, but can you connect two of them together by USB? I'm just thinking about the fastest means of restoring up to 16TB of data in the event of a disk failure.

You can't connect ReadyNAS together with USB.

I think the fastest protocol for bulk copy between two linux boxes is NFS. For incremental backup, Rsync is fastest.

make sure the switch you have connected the nas's to supports etherchannel/lacp, configure the switch and nas to use a load balancing algorithm that is best for your destination...usually, if same source -> same destination, it will only go out one link...which means the max bandwidth will be about 80-85Mbps, and with a 316..75MBps would be rather close to that. If you have a managed switch, look at the port transfer stats to see if the traffic is being balanced evenly between the two links..I doubt it, I suspect that is your limiting factor here.

I'm using Adaptive Load Balancing on both NAS because it states that it doesn't need any special switch support. I'm not clear on whether LACP offers any significant advantages that I should be aware of. The Netgear Support page doesn't really go into much detail.

http://kb.netgear.com/app/answers/detail/a_id/23076/~/what-are-bonded-adapters-and-how-do-they-work-with-my-readynas-os-6-storage

Also, 75MBps is well short of 125MBps. I have had 100MBps to a desktop earlier. The 316 comes with two Gigabit ports, and if CPU and RAM aren't limiting factors then I'm not sure why I'm not at least maxing out a single connection.

At any rate, the backup finished last night so I'm hoping to carry out some tests today to see if I can find any improvements.

One challenge with NIC bonding is that the server also needs to communicate with clients that only have a single NIC. When you use two NICs for the same traffic flow, packets will arrive out-of-order at the receiver, and you can also end up with packet drops in the switch that serves the receiving device. The simplest way to avoid these issues is to send the entire flow for a connection out a single NIC. That's what LACP does (and most of the other non-standardized Linux bonding modes as well).

If you configure bonding to get > 1 gbit flow for a single connection, you will almost certainly see performance issues with your normal single nic clients.

Anyway, I suggest starting with link aggregation off and MTU=1500 in your testing to establish a baseline. Then explore the benefits of jumbo frames and aggregation separately. I think NFS is the best protocol to test with for NAS-to-NAS (why use a Windows file sharing protocol between two Linux machines???). But if the main goal is to optimize end-user experience, then use SMB, and include simultaneous tests between two Windows client machines and the NAS.

As a practical matter - if you had a NAS failure, wouldn't you immediately switch over to the backup NAS? Why is the speed of restoring the original NAS a major concern?

Also, if you have parallel work going on, you might consider using NAS A for half the users, and NAS B for the other half (each NAS backing up to the other). It seems to me that will optimize your user throughput.