Host-based backup of VMware vSphere VMs.
Post Reply
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Forever Forward merge compared to Backup copy Merge

Post by pkelly_sts »

I've tried searching for my specific question but merge (and performance) is quite a common subject so can't quite nail what I'm after but please feel free to point me to the info as it will definitely have been discussed somewhere.

With a 1.6Tb full, 25Gb avg. incremental, local backup job configured to Forever Forward on a SOBR with two simple repos but on decent RAID-10 storage I get a merge time of around 12 mins or so which is fantastic.

However, the GFS backup copy to remote site SOBR has a typical merge time of around 3.5hrs although admittedly to slightly slower storage (RAID-5).

I've seen discussions/documentation referring to "backup copy with transform to reverse incremental" which I definitely don't do, I only have .vib files in the backup copy chain, so, my question is, why are the merge times /so/ different? Are 12 (SATA) spindles in RAID-10 really that much (17x) quicker than 6 (SATA) spindles in RAID-5, for merge operations, all else being equal? Or, is the backup copy merge process very different to a FF merge process?
PTide
Product Manager
Posts: 6408
Liked: 724 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by PTide » 1 person likes this post

Hi,
Are 12 (SATA) spindles in RAID-10 really that much (17x) quicker than 6 (SATA) spindles in RAID-5, for merge operations, all else being equal?
Yes, they are. Write speed of a RAID5 is affected by the parity updates. For each written block the corresponding parity block has to be read, updated, and then written back, so RAID5 gives you almost no write speed gain, no matter how many spindles it has. RAID10 of 4 spindles provides 2x write and 4x read speed gain (12 disks = x6 write speed and 12x read). Though I admit it's not x17 times, but merging process produces quite intensive random I/O load on the storage, so the performance may vary. Also may I ask you what method do you use for full backups - synthetic or active?

Thanks
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by pkelly_sts »

Hmm, interesting, thanks for the info. Can I also just confirm that the merge process for Backup Copy is the same as for Forever Forward incremental?

Our full backups are weekly Active Full because:
1) They're significantly quicker than synthetic full backups (at the moment)
2) We're pretty much an 0800 - 1800 office so additional load on original VMDKs is out-of-hours is of no real concern

I might see if I can juggle storage usage around a bit to test a change of 6 disks in RAID-5 to 6 disks in RAID-10 (on the same HP P2000 storage array)
PTide
Product Manager
Posts: 6408
Liked: 724 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by PTide »

If you have Active full enabled in your backup copy job then there should be no merging activity on Backup Copy job target repository. However I'm not sure that we are on the same page here because apparently you are talking about Active full in you source backup job:
We're pretty much an 0800 - 1800 office so additional load on original VMDKs is out-of-hours is of no real concern
, please clarify.

Thanks
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by foggy »

pkelly_sts wrote:Can I also just confirm that the merge process for Backup Copy is the same as for Forever Forward incremental?
Regular chain merge is completely the same, however GFS transform is a bit different (more blocks need to be read and written, hence more I/O).
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by pkelly_sts »

Oh, sorry, I currently have it configured to 36 restore points with 0 weekly, 1 monthly & 0 qrtly/yrly archives. Definitely don't have the bandwidth for remote active fulls!
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by pkelly_sts »

foggy wrote:Regular chain merge is completely the same, however GFS transform is a bit different (more blocks need to be read and written, hence more I/O).
OK, that makes sense, but this job only has 1 monthly retention configured, but seems to complete a (3.5hr) merge every day? I could understand it if it was just at the weekly/monthly RPs of course. Thinking about it I probably should have mentioned this point earlier but it's only just occurred to me as being relevant...
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by foggy »

Than GFS itself doesn't play here. Should be just RAID impact.
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by pkelly_sts »

OK, thanks for the clarification. I'm working on emptying one of my LUNs to reconfigure it as 6-disk RAID-10 - handily I had only provisioned 10Tb of it as RAID-5 anyway, with 5TB spare so we're not really losing much capacity at the end of the day ;-)
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by pkelly_sts »

Actually, one last thing I forgot about is that the destination for the backup copy is a SOBR with full backups on one repos & incrementals on another (each is 6-disk RAID-5) which I hoped would mitigate I/O overhead to a larger extent than it currently does. Should it make that much of a difference?
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by foggy »

Is the network connection between extents good enough?
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by pkelly_sts »

Both extents are connected to same host via 8Gb FC, they're also on the same P2000 SAN but each is "owned" by a different SAN controller (A/B) as well to maximise throughput.
alanbolte
Veteran
Posts: 635
Liked: 174 times
Joined: Jun 18, 2012 8:58 pm
Full Name: Alan Bolte
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by alanbolte »

Paul, please open a support case and post your case number here. You may be experiencing a known issue.
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by pkelly_sts »

Thanks Alan, am trying to log one now but the my.veeam.com page is throwing some weird issues right now... :-/
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Forever Forward merge compared to Backup copy Merge

Post by pkelly_sts »

Now logged as #01821733
Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 86 guests