Forever Forward merge compared to Backup copy Merge

[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]

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]

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]

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]

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]

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]

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]

Than GFS itself doesn't play here. Should be just RAID impact.

[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]

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]

Is the network connection between extents good enough?

[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]

Paul, please open a support case and post your case number here. You may be experiencing a known issue.

[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]

Now logged as #01821733