Re: [Burp-users] Incremental backup, Deduplication and other questions
Brought to you by:
grke
|
From: Graham K. <ke...@sp...> - 2012-05-18 08:05:30
|
On Fri, May 18, 2012 at 03:12:04AM +0200, Saint Germain wrote: > Hello, > > I just discovered Burp on my Debian and I wanted to test it. > Here are a few general questions about this neat software: > > 1) I saw that some directory are created with each backup (001, 002, > etc.). However I don't really understand the strategy for differential > backup. How can I know which one contain all the data (and not only the > delta) ? Hello, The one that always contains all of the data is the one that the 'current' symlink points to. By default, deltas need to be applied to go back to older backups. Setting 'hardlinked_archive = 1' means that all files get hardlinked into place so that all backups contain all the files without needing to apply deltas. Also, if you set multiple 'keep' values, the backups that land on the multiples of the 'keep' values get hardlinked, ie: keep = 7 keep = 4 Backup numbers 7,14,21,28 get hardlinked. Hardlinked backups have a file in the top level called 'hardlinked'. > Basically I wanted from times to times to save on DVD a full backup. The simplest thing to do at the moment is to copy the 'current' backup. There is a feature request that may help with exporting in general when it is implemented: https://github.com/grke/burp/issues/60 > 2) I tried using bedup and it correctly identified duplicates in my > backup (a file which I have moved). However I didn't see a change in > size in the backup directory (using "du" which is supposed to count > only once the hardlinks). How can I check that this is really working ? You need to use the '-l' option in bedup in order to hard link duplicate files. "du" should show the changes. > 3) I intend to use it from a remove server. In case the link is broken > during a backup, how reliable is the resume operation > (working_dir_recovery_method) ? I find it very reliable. > 4) How stable is the data format of the backups ? Is this a standard > format or can we have some future changes in the format which renders > old backup impossible to restore ? I find it very stable, but I cannot predict the future. The only time it changed and broke forward compatibility was version 1.1.10, one month after the first release of burp. Since then, I have been able to add to it rather than change it. > 5) I previously used DAR (Disk ARchiver), mainly because it has > protection against corrupt archives using Parchive. Would it be a good > idea to include this in Burp ? I don't understand the usage that you have in mind. >From a quick read of the DAR homepage, I think it is a tool that splits a hard drive into small chunks for backup. Possibly, it could be run in a burp pre script so that burp backs up the chunks. That could be quite effective, but possibly not what you have in mind. > 6) One typical usage of restoring is to identify the last time a file > has changed and restore the version before that. > For instance, a file is corrupt but I don't notice it immediately but > after 10 backups. Is it possible to have that information instead of > going backup after backups ? > Currently I think the only way is to list the file for each backup and > check the modification date. I don't think a simple way of doing that is currently possible. > It seems a very promising software, many thanks to the author ! Thank you for your nice words. :) > P.S. : I found this software with this page: > http://stromberg.dnsalias.org/~strombrg/backshift/documentation/comparison/index.html It looks like that page got some facts wrong about burp, so I'll see about contacting the author. > It seems that Burp, Backshift, Bup and Obnam are all new backup > softwares trying to solve the deduplication problem. Burp's purpose is backups. I think deduplication is best left to the filesystem, but I ended up writing the bedup file deduplicator because people kept asking whether burp did deduplication, and the open source 'fdupes' tool that I found was quite inefficient. And still is. Maybe there are better ones though. |