BE Exec 2012 - Deduplication: Full/Incremental/Differential Backups

[cord]

I am a little confused on this...

We purchased 1 Backup Exec 2012 Media Server with Deduplication along with 11 Agents.

I was under the impression that we could create Full Backups of all of our servers using Client Side Deduplication on a daily basis so that after the first full backups ran, only the BITS that changed would be backedup on the proceeding days.

However, when I went to create my first few jobs, it appears as though the standard method was to use Full Backups once per week with Incremental Backups daily.

With Deduplication, which my understand is that it is only going to backup the BITS that change in a file, why would you want to use Incremental and Differential backup methods? This seems a little redundant.

So I proceeded with creating backup Full daily backups jobs using Client Side Deduplication, and over the past few days, it appears as though each day, I am getting a full backup set of data and not just the BITS that are changing.

Can someone elaborate on this for me?

[dedupe-works]

The purpose of using incrementals is to offload the "Which files changed" processing to the Agent for Windows.

Once the subset of data is determined by the Agent for Windows, then the client side process can focus on the changed files only in order to locate the changed data within the files.

[cord]

I am still not fully understanding.

Does it hurt to just use Full Daily Backups with Client Side Deduplicaiton?

What advantage would I get if I were to use Daily Incremental Backups vs Daily Full Backups?

[dedupe-works · Accepted solution]

Daily full:

Pro - short restore time; less sets to restore.

Con - Lengthy backup windows

Daily Inc:

Pro - short backup windows; only process changed files.

Con - Possibility of more sets to restore vs a full backup.

Less data to process = shorter backup windows.

Coupled with Client-side, you should have a small backup window and a smaller disk cost to store the data.

[teiva-boy]

Remember all backups must traverse the file system.  That takes time.  Deduplication will not solve that.

Addtionally, all BITS as you refer to it (Though I believe it's actually a segment), is a catalog entry in the dedupe database.  The more BITS you have, the larger the database will grow..  Unecessarily.  Thus leading to possible performance issues over time.  Even if a BIT doesn't change, that is still an updated record in the Db.

A full incr/diff schedule is still recommended over all.  Dedupe doesn't save time on the backup, only saving space on the backend storage, but also improving restore times.

At the end of the day, all settings are a trade off to backup windows, disk usage, client time, and restore RTO.  The question is what are your business requirements in backing up data, and how fast does it need to be restored.  Those questions will dictate what you need to have setup within BE.

[RLeon]

Hi cord,

The "Backup Size" graph only shows what Backup Exec "thinks" has been backed up. In your case, the "thinking" is correct because from BUExec's point of view, full-size full backups have indeed been done.

However, if your client side deduplication is truely working, you should see that the second and third backup elapse times were lowered. Check in your job history for the backup elapse times.

There should be a report for deduplication somewhere in one of the buttons. From there you can see the dedup ratio, which tells you the actual space savings.

RLeon