On 30/11/12 08:21, Wayne Stallwood wrote:
I think if you really really don't care about speed then it'll be ok.
Well the backups will be going to the USB drives regardless, so it's going to be relatively slow whatever I do. How much slower is putting RAID5 on it going to make it?
20 hours sounds about right to me considering the USB interface is CPU bound and everything is having to go through the USB Mass Storage subsystem. On a direct interface like SATA/SAS I have seen arrays of this size rebuild in a lot less time but that is to be expected.
It's a pretty old 3GHz Pentium D. It's already a file server (software RAID5 across 4 SATA internal disks), and the only other thing it's going to be doing is the backups.
It's old and slow in modern CPU terms but I'm assuming its still way more powerful that whatever CPU I'd find in a dedicated RAID NAS box?
The only other thing you might see is performance problems across the system when working this array hard, really depends on the spec of the machine it is attached to but it's going to get fairly tied up with stuff sitting in IO wait and depending on what processes that happens to it can block other things. You might be able to fix a bit of that by making sure write caching is enabled on the array.
Assuming backups run at night, there won't be anything else going on when this happens. Backups will be mostly from local data (the RAID5 array on internal disks) to the USB array, but will also include some data pulled across the LAN from other machines, where the LAN will probably be a bigger bottleneck than the USB interface.
With caching: I would have assumed that the worst case in the event of power loss would be loss of the backup that was still cached, but a quick Google suggests that the whole array could be corrupted? That would kinda defeat the point of using it for backups, so I'd appreciate advice on that.
RAID10 would be substantially faster but obviously I'd lose a third of my array capacity. I think I'm going to have to just see how bad it is and make a judgement after that.
Mark