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.

/tony

+----------------------------------------------------------------------
|This was sent by tony.albers AT gmail DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------



------------------------------------------------------------------------------
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