Comprehensive data protection for all workloads
Post Reply
ejenner
Expert
Posts: 435
Liked: 69 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

converting to scale out backup repositrory

Post by ejenner » Jun 28, 2019 10:09 am

Hi guys,

I've found that my repositories I'm using for Copy Jobs aren't saving any space with REFS... probably because they're already deduped and compressed as original backups on the original repositories. So the Copy Job is copying data which has already been optimized and can't be optimized any further?

With this in mind I've decided to give scale-out repository a try so I can eek out every bit of space from 4 disk systems covered by a SOBO.

I had a couple of things I was thinking about and wondered if anybody knew the answers.

My repositories for the copy jobs are HPE DS3600 direct attached disk boxes. First of all I'm wondering if (unrelated to Veeam) whether one logical volume could be setup to spread across all the boxes and thereby negating the requirement for a SOBR at Veeam level.

Separately I was wondering if converting to SOBR wipes all the data currently on the repositories? Not the end of the world... but not ideal if it does.

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

Re: converting to scale out backup repositrory

Post by foggy » Jun 28, 2019 11:49 am

Hi EJ, compression doesn't affect block clone ReFS capabilities, so it should be something else. Btw, how do you tell it doesn't provide any savings?

As to your questions, then I believe you can use spanned disks to consolidate space. And switching to SOBR doesn't affect existing backups, your existing backup chains will continue normally.

ejenner
Expert
Posts: 435
Liked: 69 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Re: converting to scale out backup repositrory

Post by ejenner » Jul 03, 2019 8:32 am

thanks foggy.

You can check REFS effectiveness on a volume using 'select all' and 'properties' within the volume. Compare that with the size of the logical volume in disk manager or just the size shown in Explorer.

So on one of my volumes where I know it's working well I have a 54TB formatted volume. But open it up and check the properties of the files and folders inside and it'll report as 135TB.

Now I may be wrong as it's just an initial impression. But if you try to run BACKUP COPY jobs of the backup data stored on that repository you require 135TB of uncompressed disk to back it up as a copy. Same as if you wanted to take the data out of that volume using Windows explorer and copy it onto a normal NTFS volume. i.e. it appears the REFS magic only applies to fresh data stored within that REFS volume.

Furthermore, as Veeam has already optimised the data when it was being added to the original repository there is nothing more it can do during the BACKUP COPY job. It seems to make sense to me that if more processing was possible it would be done during the original backup rather than being reserved for use during the BACKUP COPY operation.

ejenner
Expert
Posts: 435
Liked: 69 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Re: converting to scale out backup repositrory

Post by ejenner » Jul 05, 2019 2:41 pm

I've completed this now.

I decided to go with the following:

I found when I looked at what kit was available that two of my disk boxes had smaller 4TB disks. So I bundled those together into one logical drive. Then the 3rd box with 6TB drives I created another logical drive. Both of those were created with a 64 KiB / 1472 KiB Strip/Stripe size. RAID 5. In Windows 2016 I created a spanned drive which joins the two together. Formatted as ReFS with 64kb allocation size.

I'm not sure how successful all of that will be... but it produced a single 143TB volume which takes away the problem of running out of space which I was having with a couple of large jobs.

As before with the old volume for backup copies, when looking for ReFS magic I'm not finding any. The size of the space used is the same if you check it both ways.

Post Reply

Who is online

Users browsing this forum: No registered users and 25 guests