[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bacula-devel
Subject:    Re: [Bacula-devel] Block device backup and restore
From:       Bastian Friedrich <bastian.friedrich () collax ! com>
Date:       2011-05-18 14:09:01
Message-ID: 201105181609.01440.bastian.friedrich () collax ! com
[Download RAW message or body]

Hi developers,

I'm having some difficulties with block devie backup/restore. See my mail from 
March 2nd below (sorry for the full quote).

Any opinions? I'll be happy to implement the proposed flag (see option "b" 
below) myself if there is any hope for upstream approval.

Am Mittwoch, 2. März 2011, 17:40:30 schrieb Bastian Friedrich:
> Hi,
> 
> bacula is able to back up data from block devices by listing them as
> dedicated files in filesets. During restore, data is expected to be dumped
> back to these devices.
> 
> However, this results in ambiguities when restoring to a location ("where"
> statement) other than the system root. E.g., restoring to a temporary
> directory/location (I'm using /tmp in this example) results in the device
> file being created in the respective location, and the data being fed to
> that device -- possibly resulting the data being written to the "original"
> space. E.g., if a device /dev/sda1 was backed up, a device file
> /tmp/dev/sda1 will be created with the major/minor pair of /dev/sda1 --
> and data being written to that device file will overwrite the system's
> /dev/sda1 -- not in an alternative location, as the user might expect.
> 
> Interestingly, if a (file!) /tmp/dev/sda1 pre-exists, data is written into
> that file; the block device is not recreated. That file can e.g. be an
> empty file (touch /tmp/dev/sda1), or a loopback device (dd if=/dev/zero
> of=foo...; mknod /tmp/dev/sda1 b 7 1; losetup /tmp/dev/sda1 foo).
> 
> I am unhappy with that situation; restoring with a given "where" location
> should never ever write data into the system's devices. At the same time, I
> was only able to restore data that was originally stored in a device to a
> file by the "hack" described above.
> 
> As a side note, interestingly, the linux kernel happily accepted data for a
> block device that it did not have an appropriate module for during a
> restore. I was handling DRBD devices; after a backup of a DRBD device on
> one machine, I did not encounter any error messages on a machine that did
> not have an appropriate DRBD setup during restore. Data was never
> restored, however.
> 
> What do you think? Is the behavior as it is the way you'd expect it to be?
> Would you rather think that the current behavior should be changed and
> documented in a better way?
> 
> >From my point of view, it would be sensible to
> 
> a) _always_ create files (instead of block devices) for restored data when
> an alternative location is given during restore
> and/or
> b) having a separate restore flag ("dump to file" vs. "dump to device") for
>    block device restore behavior
> 
> 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

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

[prev in list] [next in list] [prev in thread] [next in thread]