Comprehensive data protection for all workloads
Post Reply
mauricio
Novice
Posts: 8
Liked: never
Joined: Aug 24, 2017 1:58 pm
Contact:

How-to rebalance data on a (dedupe) SOBR?

Post by mauricio »

Hello,

One of the nice perks as a VEEAM-admin, is that you get to build, play with and destroy VEEAM playground environments. This time I've being playing with v10' new feature "seal mode" in a simple environment with an imbalanced SOBR.

From what I've been reading, VEEAM's definition of this function is:
"Sealing up extents gives you the ability to gradually remove data located on these extents by applying a retention policy. You can use this feature to gracefully stop using some of your extents as backup repositories and exclude them from the scale-out backup repository configuration altogether.

When sealing up an extent, Veeam Backup & Replication restricts any further data saving to such a sealed extent and allows only read operations such as restore, merge and remove.

All backup jobs that are targeted to a scale-out backup repository with the sealed extents that store active backup chains will be forced to create a new active full backup on the next run. The new active full will be saved to another available extent in the scale-out backup repository scope, thereby forming a new active backup chain. The extent to which the new active full is going to be saved is chosen automatically by Veeam Backup & Replication, depending on the available resources."

After testing different scenarios (i.e. setups) for a period of time, I've found that the outcome of sealing an extent might not bring that much of a difference in comparison to putting an extent in maintenance mode when using:
  1. A dedupe appliance* with only share;
  2. The "Use per-VM backup files (recommended)" option selected.
* I'm deliberately stating "dedupe appliance", because some of them (e.g. Data Domain) use proprietary software where backup files (VBK/VIB/VBM/...) are being chopped up into smaller objects that can't be manually transferred to another appliance.


For instance, let's say you have the following simple setup.
  • One VBR with tens or hundreds of jobs pointing to the same SOBR;
  • 10 Dedupliances of 50TB each;
  • Each dedupe appliance compares to one extent;
  • One SOBR consisting of 10 extents;
  • SOBR configured with the "Use per-VM backup files (recommended)" and "Perform full backup when required extent is offline" options selected.

The setup above in combination with Luca's perfect explanation about SOBR:
"since Veeam keeps writing backups daily, and data will always have different sizes, even the same incremental in two different days, there's will never be a fixed state unless we stop writing new backups (and this could be solved by read-only mode for extents that was discussed elsewhere, this could lock the extents and never use them for new writes, only for reading existing data)"
Will in time result in possibly the following outcome:

Image

The first question an engineer would ask, is "how can SOBR be rebalanced , so that each extent has more or less the same usage / free space?". Normally, if we wouldn't use dedupe appliances, I would answer with something like "manually a certain amount of data to another extent, because you're using a single share extent". However, In the case of a dedupe appliances, a backup engineer cannot move data to another extent, because (i.e.) Data Domains don't save data as 'plain files'.


Coming back to the said functions earlier and their outcomes, I've noticed that:

When using "maintenance mode"
  • All data is being moved from that extent to all remaining extent within the same SOBR.
  • This results in 50TB (which takes a long time) being redistributed among the other extents, leaving you with 9 fuller extents and one completely empty.
In my opinion the perfect way for decommissioning extents instead of attempting to rebalance a SOBR.


When using "seal mode"
  • All data stays put on the extent, but new data needs to go elsewhere.
  • This results in a lot of new "full backups" of the VMs from the sealed extent, which (in my case) is a huge amount of 'new' data, leaving you in time with 9 fuller extents and one completely empty.
What I mean by "in time" is that if no new VMs present themselves and nobody resizes a VMDK, all data is kept on those nine extents. Even if we deactivate "seal mode" right after the first run of all the backup jobs.

If you're having a very dynamic environment, this feature might help you in the long run in getting a well balanced SOBR. However, if you're in dire need to rebalance your SOBR (look at the screenshot) and you use a dedupe appliance with a single share, it seems (imho) you're out of options.


My question to all the VEEAM-users/admins, how would you tackle this situation?
HannesK
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: How-to rebalance data on a (dedupe) SOBR?

Post by HannesK »

Hello,
with dedupe appliances you probably don't want to rebalance anything. You already mentioned it: it's slow. Reason: it requires de-hydration of the data. So DDboost / Catalyst efficiency cannot be used.

It depends how much time you have. If you have much time -> maintenance is fine. If you want to continue working with the backups during decommission -> sealed mode.

Best regards,
Hannes

PS: Actually I would avoid SOBR at all with dedupe appliances. Reason: imagine one of the boxes get's full for whatever reason. Now increments and fulls are on different boxes. Creation of synthetic fulls is slowed down massively (not a problem if you use active full).
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 241 guests