Raid 5 write performance in proliant range

Associate
Joined
30 Jul 2007
Posts
1,281
i am looking to spec a server for reverse incremental backup jobs in veeam.
Currrently on a 5 year old server, the 2 TB daily backup job takes 10 hours to process the reverse incremental (storage subsystem limited)

am looking for next proliant server to be better specced.

in the proliant range, What sort of raid controller(s) do i need to be looking to buy to run some standard class 2TB sas drives (7,2k) at their max write rate for raid 5 over 4 disks (ie so the controller is not a bottleneck)..would sata be just as good for this application? What sort of write speed can i expect to get.

thanks for feedback / ideas.
 
Before we go any further, if you are doing this commercially what’s the logic behind R5 on mechanical disks when you’ve already stated it’s an IO limited scenario? R5 is the red headed step child of the family, it’s been shunned from the family photo’s for several years now.

thanks both for feedback,

is raid 5 not the most cost effective way of achieving the disk redundancy coupled with the write performance?
maybe if we went raid 0+1 ...could we save of the disk controller , put that into the disks and achieve better io for the same costs? and still have redundancy...that sounds like a good suggestion..

Would the standard raid controller with a write cache be as good as it needs to be for 0+1?

(ie no need to spend on a better controller)
 
for backing up and replicating and restore virtual environments nothing ive found comes close to veeam, a truly excellent bit of software.

we use reverse incremental so that, even though we have a massive 30 day chain of backup files, there is one file which represents the last backup, which we can copy offsite.
as you say it is very io intensive.

any gibberypokery would have to be in the os/hardware layer, veeam does have this type of capability. am hoping REFS and windows 2016 might introduce some performance gains, more like wishful thinking.

so it looks 7.2k RAID 10 is chepaer than 10K raid 5 disk space for disk space, and by all accounts 7.2K raid 10 will be significantly faster, so thanks for that suggestion..i am going with it...

can i just go with the cheapest raid controller with a write cache for raid 10? will that be as good as anything?
 
Last edited:
thanks again for feedback.

yes...was thinking that ....with enough disk space on the backup server, i would just do forward incremental for 30 points and a separate backup job that just did a separate full backup every day with 1 point.... the two jobs will probably be faster than reverse incremental as you say..
 
yes backup copy job is ideal, but the reason we discounted this, was after a conversation with Veeam, we came to the understanding that the gui was too restrictive on scheduling.

we wanted to create the backup copy job to run on tuesday, every 28 days,

we could perhaps create the copy job every day and only use it every 28 days...to save on read io on the production storage, but as production is all flash vsan its not really limited....in fact reading from production is probably faster than creating a backup copy job...

we could perhaps investigate using the command line to schedule the backup copy job..
 
thanks, we are considering changing our process to every x day of the month.

i understand the backup copy job repository needs to keep two points on top of the one we really want.. eg fourth tuesday of month
the reason we go to the trouble of reverse incremental is we have a single vbk to copy offsite - so thats not ideal.

and i wonder if the vbk we want inside the backup copy job is going to have a predictable name, so we can easily script its copy.

anyways have implemented suggestion in test and will see how it goes.

upon reflection, it maybe that a scripted and scheduled (via windows task scheduler) standalone full backup job may be offer the best of all worlds, albeit with greater load on production storage, in that it can be safely pointed at a removable disk (whereas i understand a repository wont like that so much) AND scheduled for every 28 days..will try that next..
 
thanks thats a good setting. so looks like i can force the full backup to a repository on a removable drive every 28 days via a powershell script and windows scheduler. and get rid of reverse incremental on the main job. best of all worlds. will try tomorrow.
 
thanks thats a good setting. so looks like i can force the full backup to a repository on a removable drive every 28 days via a powershell script and windows scheduler. and get rid of reverse incremental on the main job. best of all worlds. will try tomorrow.

this is working well, veeam automatically recreates repository folder structure on external drive, and i think it even has logic to guess the removable drive letter if it changes.

emc data domains..will take a look..although we need a full self contained backup (so no deduplication accross different media) and the limiting factor is the the single sata disk in a caddy.
were getting 200MB/s (400MB/s uncompressed), so thats pretty good.
annoys me that HP and DELL still dont provide an esata card in their range, have to hook up a cable/riser card to the motherboard to get esata support.
 
by switching my reverse incrementals to forward incrementals, and having a separate full backup job directed to external media (batch scheduled via windows task scheduler every 28 days), i am savings loads of time / load on the backup server.
creation of the single point on the external media is <6hrs vs 20 hours (to process the reverse incremental and copy the file). Now i dont need to worry about raid/controller spec, the limiting factor is the sata disk which 'is what it is'.

but have now gone full circle and am testing a backup copy job with an x day interval (backup copy jobs seem to support an x day interval) . Its is perhaps a moot point that backup copy jobs insist on maintaining a minimum of 2 restore points (i only want 1 point ie a full backup)....moot because the backup copy job is pointed directly at a repository on an external path that is wiped - as removable drives are formatted before use, so i always get just a full backup.
 
Yep - looks fine (Controller is Mini SAS HD, SFF-8644 cable is Mini SAS HD according to wiki)

thank you,
Do you have any experience with making the most our REFS on Windows 2016/2019?
I am keen to minimise storage space without massively affecting backup times.
I am assuming that REFS is the goto tech / design for Veeam now?
but i read there are some challenges and the software is still 'maturing'

https://forums.veeam.com/veeam-backup-replication-f2/refs-3-0-and-dedup-t56658.html
 
I'm fresh off a Veeam course, ReFS is best for Veeam Repositories

so refs it is.

so for 30 point forever forward incremental daily backup chain of ~2Tb of 30 windows servers.
on a raid 10 array with bbwc windows 2019 16 core 16gb dedicate 100% veean backup server .
what would peoples thoughts on the following be.

1. refs disk cluster size? 64kb?
2. any refs settings beyond cluster size?
3. veeam compression level
4. veeam storage setting ? local disk largest blocks?
5. corruption guard
6. maintenance tasks. create full restore point regularly?
7. dedupe settings/considerations.

i am major noob in terms of understanding the significance/value of these.
my goal is to minimise disk capacity use without significantly hindering backup times, whilst ensuring the integrity of backup points.

thanks
 
Always make sure you have plenty RAM for ReFS. I think Veeam reccomend 1GB per TB of storage up to a certain point - that's over and above any other memory usage on the box

more luck than judgement i have enough. 1GB per TB would get quite pricey for larger backups...my disk will only be 8TB and actual backup chain size closer to 2TB. 16GB RAM should be enough for 2019+VEEAM+REFS.

Customs made me pay £15 for the privilege of importing a 2M SAS to ESATA cable from the states..hope it works
 
Spoke too soon, REFS on RAID 10 is working well. Synthetic Full backups on forward incremental are using no extra space, and taking a 5 minutes to calculate (as opposed to reverse incremental taking closer to 10 hours) and Veeam is hitting 1GB/s . to the array.
 
Back
Top Bottom