Netbackup 7.5 Accelerator and Client-side Deduplication

Hi vholmes,

Thanks for keeping this thread alive :)

Good point about not being able to select "Synthetic Backup" in a schedule when Accelerator is enabled; didn't know about that.
As you said, it is probably because Accelerator itself uses it as part of its "Optimized Synthethic Backup" routine.

As for the errors, are you using iScsi connections for your deduplication storage?
This configuration isn't supported until Netbackup 7.5, and even then, only 10Gb iScsi is officially supported for the deduplication storage.

RLeon

 

Accelerator IS optimized Synthetic Backup.

What I find worrying is the large track/journal log on the client with apparently no solution (yet).

See this discussion: https://www-secure.symantec.com/connect/forums/accelerator-caused-journal-log-80-gb

 

So apparently the large track log problem is still present in 7.5.0.3... Interesting.

As I have said earlier in this thread, although this is a reason to NOT use Accelerator, this is not an official reason.
I'm still waiting for the official word - from a kind of Best Practice perspective - that in what situations Accelerator should not be used together with Client Side Deduplicatoin.

Note that I'm not referring to situations where Accelerator could not be used;
such as when you want to manually use the traditional Synthetic Backups (non-Optimized),
or when you simply do not have a deduplication storage unit,
or when you want to use other policy types such as flashbackup,
etc.

I'm referring to situations where Accelerator could be enabled, but should not.
Any if such situations exist, I would like to know the reason.

RLeon

Accelerator does not require source dedupe or force it on when enabled.  You can still dedupe on the media server instead of at the client when you use accelerator.

 

When you run the backup does the track log clear out or does it remain very large?  

 

One of the things we'll have to get used to with accelerator is the paradigm shift it may be causing.  What you might want to try is scheduling backups to run more often on these servers where the track log is filling up because of a high change rate.  You can setup backups for every 4 hours that expire after 24 or 48, and then keep your normal daily backups at the retention you currently have.  Might be worth a test if nothing else.  Could also give you some pretty good RPO.

Hi Jed,

Thank you for your input.

I understand how Accelerator could be used together with client-side deduplication, and that they do not necessarily have to be used together.
It is also clear that when Accelerator is enabled, it does not force client-side deduplication. (Like what I was suggesting previously; which was wrong.)

You are suggesting that if data change rate is high, then the track log could be large. That makes technical sense.
You also suggested that this problem could be remedied by running backups more often. That is fair enough.
(Even though apparently the track log is only supposed to be around 30MB according to the thread linked to by Marianne)

Can you also shed some light on my query from the post that is directly above yours? That one about when-not-to-use Accelerator.

I understand that Accelerator is not really for clients with a very high change rate, and I consider that a valid reason for not using Accelerator.
But then, the same reason also applies to deduplication backups without Accelerator (client or server side).
Actually, one could argue that it also applies to the traditional file level incremental backups: The higher the change rate, the less useful the incremental backup method becomes.

In short, while a valid reason, the high-change-rate-makes-it-less-useful reasoning is not unique to Accelerator.
I know I've repeated this many times already, but is there a reason, unique to Accelerator, that one should not use it even when it could be used?

Thanks,

RLeon

A few things: 

• Although there are real reasons for the track log to get larger than normal, the size cited is unusual and should be investigated by support.  
• Normal is relative and dependent on the number of files on the file system.  
• Change rate in this case means how many files have changed since the last backup, not how much raw data has been churned.

To answer your question about when not to use accelerator.  I would say there are less times to describe when accelerator is not good and more to describe when something else is better.  

• Hugely overburdened file systems that are highly fragmented with millions and millions of files... that's still probably a pretty good time to use flashbackup instead of accelerator.  Accelerator is not intended to be a repalcement for this functionality.
• Backing up a VM... I'd still use VADP integration (for the most part) rather than an agent with accelerator backups inside the VM. 

That's a couple of examples.  Do you get my point though?

Also, let me correct my previous statement.  The track log is a function of the number of files and should only significantly change when the number of files on the file system significantly changes.  Apologies for the incorrect info.

Anyone who has a track log growing to the size mentioned in some of these posts (80gb, etc) should contact support and have them investigate.

Jed and Abdul,

Thank you both for jumping in with the new info.

From the blog:

Are there any design considerations when not to use NetBackup Accelerator when NetBackup Client Side Deduplication is used?
No! NetBackup Accelerator does not have any negative effects on NetBackup Client Side Deduplication.

I like that exclamation mark, a lot.
I can get some sleep now.

Thanks all!

RLeon