From: Bastian F. <bas...@co...> - 2012-07-30 10:38:39
|
Am Montag, 30. Juli 2012, 11:31:32 schrieb Martin Simmons: > Writing zeros when the restore target is a block device might be a better > approach, rather than doing it based on the type of the backup. That would still result in broken file images when restoring a raw device backup to an image. Restoring a "hole" at the end of such image files would solve the problem as well; I don't know how to do that, however. Additionally, knowing the restore target type is not as simple as requesting the stream type (and, thus, the backup type). > >>>>> On Sat, 28 Jul 2012 08:50:53 -0700, Kern Sibbald said: > > 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 -- Collax GmbH . Basler Str. 115a . 79115 Freiburg . Germany p: +49 (0) 89-990 157-28 www.collax.com Geschäftsführer: Bernd Bönte, Boris Nalbach AG München HRB 173695. Ust.-IdNr: DE270819312 |