Hello Bastian, On the documentation issue, the best would be for you to submit a bug report marked [DOC] in the subject line, with perhaps some sample text that you would propose, otherwise your request is likely to be lost.
Also, for this patch, you should do the same: submit it as a bug report with [PATCH] in the subject. I am not really sure we want to do this, at least under the "sparse" key word as it would mean that certain devices that may have holes in them will actually consume much more space -- this would apply particularly to VMs where they tend to use sparse allocation techniques. The sparse option is intended to work only for *real* sparse files, and you are trying to apply it to reduce or compress zeros in certain images. This could probably be better done through a plugin where one could tune it to do exactly what you want. If you do want to submit the patch, we will consider it, but please if you have not already done so, fill out an FLA and send it in. You can find it at www.bacula.org -> FLA License. Thanks for your interest in this feature ... Best regards, Kern On 07/27/2012 02:33 AM, Bastian Friedrich wrote:
Hi, Am Dienstag, 24. Juli 2012, 15:28:54 schrieb Bastian Friedrich:we are using Bacula's raw block device backup features for backing up virtual machines that use raw devices (logical volumes, or DRBD) as their storage. As advised by the bacula documentation (obviously, for the purpose of sparing storage space), we set "sparse = yes" for the respective file sets. Recently, we discovered a problem with systems backed up in this way. Bacula does not only back up sparse data; it also restores the data in such a way, which can result in problems. Imagine a virtual machine that has a (non- sparse!) file with large chunks of zero data in its file system. When these data are backed up, these null data are stored as a sparse stream. During restore, however, this can result in a problem: The sparse data (all zeros) are not written to the disk; instead, the respective chunk is just skipped (via seek). As a result, the virtual machine now has random data in its (formerly all-zero) file.the attached patch modifies Bacula's behavior during restore of data that originates from a block device with the "sparse" option set. Instead of simply seeking to the requested file position, zero bytes are written to the file/device in chunks of 64k. This results in sparse blocks (i.e., blocks that only contain zeros) on the original disk being reproduced identically to the original data during restore to a new block device (of identical size). Restoring to a file ("image") results in it having the correct size, and of course identical data (e.g., identical md5sums). On the downside, restored data of block devices always require the full amount of space on disk, even if they contain sparse blocks. Comments welcome. The patch has NOT yet been tested to full extend; I'd welcome any feedback. Thx Bastian ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
