On 04.01.2013 11:30, tonyalbers wrote:
> Ok, it seems to me that there is some confusion of which kind of dedupe I'm 
> referring to.
>
> What I'm talking about is variable-length block-based target dedupe, that is, 
> the DXi or DataDomain box receives all data from the client via the backup 
> server (bacula SD) and then handles the deduplication and compression of 
> these data. There is no dedupe or compression on the client or backup server 
> itself of any sort.
>
> This does not work in practice right now, since bacula does something to the 
> backup stream that makes most of the blocks or segments unique.
>
> I've tried this on a DXi and on a fileserver using SDFS, and both had only 5% 
> data reduction after running three 6GB backups of the same filesystem on a 
> client. In theory that should give us at least 66% data reduction ratio.
>
> Please bear in mind that target dedupe is pretty much the industry standard, 
> since RTO plays a huge role in deciding what type of backup and storage to 
> use.

Hi.

This kind of dedup will be possible on filesystem level once Bacula 
volume's format is changed to make it possible.

To me, doing dedup and compression on the client seems better anyway. Or 
what are the downsides of this (other than not being "the industry 
standard"(?))?

--
Silver

------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users