Availability for the Always-On Enterprise
Post Reply
doug_fergusson
Lurker
Posts: 1
Liked: never
Joined: Aug 21, 2017 4:56 am
Full Name: Doug Fergusson
Contact:

1 full 14 increment on dedupe appliance. Yes or No?

Post by doug_fergusson » Mar 29, 2018 5:52 am

Hi All, (escpecially foggy *cough*)

Trying to spec out backing up 5.7TB of data and what the best fit for storage is.

Looking at keeping 5.7TB of raw data, with 14 days incremental, on either
a) HP Storeonce 3100 appliance (5.5TB useable) with a 1GB link
b) Rented SMB Storage (Isilon) also over a 1GB link

Also looking at keeping additional backup with 4 incremental copies + 1 full in the cloud on a storeonce virtual appliance. Backed up once weekly

Cost of storage is a major factor so considering the above:

1.Am I spreading my resources too thin only keeping 1 full HA backup and is it manageable to keep 14 increments? If so would this work better with a straight SMB share because Dedupe appliances like to have a full backup due to the overheard of hydrating the data. Does this negate the benefits of using a dedupe appliance if I can get away with 1 full backup vs synthetic full backups over SMB?

2. I calculated 4.8TB of data needed using Backup size = C * (F*Data + R*D*Data) or Backup size = 50%* (1*5700 + 14*5%*5700). 2 full copies of the data will push this to 7.7TB. When I run a calculation at "http://rps.dewin.me/" they always have a full backup weekly and I can't seem to remove it. I need to validate the additional $4K for the larger storeonce appliance and even then it only has 7.5TB useable so I'm pushing\over capacity. Are my calculations making logical sense or are they off? Is the recovery options being spread too thin?

3. Looking for input on using the HPE Virtual Storeonce in the Cloud for backups. My guts are saying, not a good idea considering the overhead or running full backups and hydration overheads in remote enviroment. That said we also have weekends for them to complete, and they are intended as a cold, failsafe backup. If it isn't a good option, is there suggestions for better options in Azure? Azure file share for example? Or a microsoft VM with some managed disks? Options must stay in Azure cloud). Should I be focusing on deliverting synthetic full backups and using compute to merge them in the cloud instead?

Thankyou for your input!

SBarrett847
Service Provider
Posts: 271
Liked: 39 times
Joined: Feb 02, 2016 5:02 pm
Full Name: Stephen Barrett
Contact:

Re: 1 full 14 increment on dedupe appliance. Yes or No?

Post by SBarrett847 » Mar 29, 2018 11:54 am

You could consider Veeam Cloud Connect Providers for Off-site?

Note Dedupe Appliances are great for saving space, especially with repeated full backups - however they are slow to process jobs and restores if not setup correctly. If you can get a catalyst licence for the Storeonce, do so. It will allow Fast Cloning ala ReFS, reducing merge and GFS creation times.

I have ReFS and Storeonce implemented for different scenarios. Each has its pros and cons. Both give great space savings where GFS is employed. Your Incrementals wont benefit so much as Full backups.

My Cloud Connect customers benefit from the ReFS Block Cloning I've implemented, it allows them to have GFS points, and insider protection, with very little extra space taken on their Cloud repo. I have one Customer with 20TB in a 2TB repository for example.

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

Re: 1 full 14 increment on dedupe appliance. Yes or No?

Post by foggy » Mar 29, 2018 12:27 pm 1 person likes this post

Hi Doug, the first recommendation is to avoid using deduplication appliances as the primary backup destination. This is mentioned in our reference architecture and best practices document, that it is recommended to write to a standard storage system first, and then to a deduplication appliance for secondary backup. This way, having a primary backup set of 1 full and 14 increments is totally fine for operational restores, while longer-term GFS retention should be available on the secondary storage (and here dedupe device is good for storing full GFS restore points that dedupe well).

Your calculations seem correct for the forever forward incremental, where the constant number of restore points is maintained. For simple forward incremental you will have to allocate space for the second full anyway.

Post Reply

Who is online

Users browsing this forum: No registered users and 18 guests