Harry Mangalam writes: > >From the 'looking a gift horse in the mouth' department, I was chatting with > >a > local backup guru about the advantages of backuppc when he mentioned a > feature that I think backuppc lacks. If it is lacking, how does one best > address the deficit? > > The (possible) deficit relates to the way many mail and log spools are > treated - single large files that are continually appended to. Does backuppc > treat these files as completely new files or can it treat the appended info > as a diff and only backup the difference, appending it to the stored file on > the server? > > The campus backup server uses a technology that supports a very neat data > pooling approach (Data Domain?) that checksums 4K blocks of data, so that in > a large mail spool file for example, only the latest, new data would be > stored incrementally. I know that backuppc uses data pooling, but does it do > it on this level or on the file level only?
It pools at the file level only. > To be more simplistic, if my mail file spool folder was 200MBs, and adds 25K > in the course of a day, will the entire 200MB file get backed up afresh at > each backup? Or only the 25K that's new? I use kmail, which segments mail > into small files, so this isn't a problem for me, but it certainly is a > problem for many who use single mail spool files and the like. Only the differences will be sent over the network, but a complete new (compressed) file will be stored on the server each time it changes. A long time ago I ran some benchmarks looking at storing file deltas (ie: just the rsync changes) vs file-level pooling but concluded the extra benefit was only ~10-15%, at least for the data set I was using. Of course, the benefit depends on what portion of the files have changes that are localized. Craig _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
