From: Bastian F. <bas...@co...> - 2012-07-27 09:32:06
|
Hi, Am Dienstag, 24. Juli 2012, 17:53:02 schrieb Eric Bollengier: > >> What you describe is exactly what the code is supposed to do, but it > >> works well only if you restore to a filesystem that supports "sparse > >> blocks", and a raw device doesn't support it. > > > > ACK. I haven't found any hints in that sense in the documentation. > > > > As said, not only the restore device needs to support sparse blocks, but > > also the backup device ... > > No, the backup device doesn't need to support the sparse block > interface OK, let me put it in other words: if the backup device was a raw device, the restore to a file (non-raw-device) will not result in an exact copy of the original data. > >> If you restore the device image to the filesystem then you copy it with > >> dd to your device, it will work. > > > > As long as said device has been nulled before. > > Not in this case (not easy to implement that saids), when restoring to > the filesystem, empty blocks will contains zeros, then when you copy the > result file to the raw device, dd will copy zero as well. Incorrect. When I back up a device that ends in zeros (a "hole"), and restore the data to a file, the trailing zeros are not written, as the final seek will not extend the file size appropriately. Due to that, dd'ing these data back to the/a device will only result in correct data if that device was nulled before. > I think that if Bacula was able to write zeros on sparse blocks when > restoring to a raw device, it would be nice, however, it might be a bit > tricky to implement, because you can write to the empty area only after > you received a new sparse stream and you detected a sparse area. See one of the next mails for a patch that implements that. Thx again 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 |