On 11/14/2014 03:40 PM, Kern Sibbald wrote:
> You are getting confused.
Not really, no.
> For Bacula, the /dev/mt0 is not at all equivalent to
> a directory. It is much more like a file within a directory because it is
> opened directly then read and written like a file. A directory is neve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/12/2014 09:10 PM, Dimitri Maziuk wrote:
> On 11/12/2014 01:11 PM, Josh
Fisher wrote:
>> On 11/8/2014 1:35 PM, Dmitri Maziuk wrote:
>
>> I think there is some confusion about this due to
On 11/12/2014 3:10 PM, Dimitri Maziuk wrote:
> On 11/12/2014 01:11 PM, Josh Fisher wrote:
>> On 11/8/2014 1:35 PM, Dmitri Maziuk wrote:
>> The other issue, using multiple simultaneously mounted filesystems, is
>> not so clear. Each Device resource associated with an autochanger can
>> specify a dif
On 11/12/2014 01:11 PM, Josh Fisher wrote:
> On 11/8/2014 1:35 PM, Dmitri Maziuk wrote:
> I think there is some confusion about this due to "multiple devices"
> being an ambiguous term. There is a difference between "multiple devices
> that are only attached one at a time" and "multiple devices th
On 11/8/2014 1:35 PM, Dmitri Maziuk wrote:
> On 11/8/2014 5:36 AM, Kern Sibbald wrote:
>
>
>> By the way, in case you have not noticed, there are three white
>> papers posted on the bacula.org web site, two of them, if I am not
>> mistaken, document Virtual Autochangers as implemented in the
>> com
On 11/9/2014 6:53 AM, Kern Sibbald wrote:
> On 11/08/2014 07:35 PM, Dmitri Maziuk wrote:
>> On 11/8/2014 5:36 AM, Kern Sibbald wrote:
>>
>> By the way, in case you have not noticed, there are three white
>> papers posted on the bacula.org web site, two of them, if I am not
>> mistaken, document Vir
In the message dated: Mon, 10 Nov 2014 09:31:41 -0300,
The pithy ruminations from =?UTF-8?Q?Ana_Em=C3=ADlia_M=2E_Arruda?= on
were:
=>
--
=> Kern,
=>
=> In spite of Bacula do not need different Media Types when using d
Hi Kern,
In spite of Bacula do not need different Media Types when using different
LTO generations in tape libraries, I really think that it could be a best
practice for working with LTO tapes to have the LTO tape generation
specified in storage device definition. Just because of compatibility
b
On 11/9/2014 5:53 AM, Kern Sibbald wrote:
> Bacula can only mount one device in any given Device section at a time,
> but in an Autochanger (virtual or not) there are multiple Devices and
> each can have its own directory. However, if you use different
> directories, you must use different Media
On 11/08/2014 09:20 PM, Dmitri Maziuk wrote:
> PS. I should probably clarify that bacula has very convenient
> automatic volume management features that work perfectly well with
> single-filesystem disk backup. It's a pity bacula's disk backup
> mechnism is apparently designed so you can have eith
On 11/08/2014 07:35 PM, Dmitri Maziuk wrote:
> On 11/8/2014 5:36 AM, Kern Sibbald wrote:
>
>> I think so. If I understand correctly, you want disk mount points or
>> directories to be treated much like a tape drive, so that you can
>> mount multiple "disks".
>>
>> I think this feature is already i
PS. I should probably clarify that bacula has very convenient automatic
volume management features that work perfectly well with
single-filesystem disk backup. It's a pity bacula's disk backup
mechnism is apparently designed so you can have either automatic volume
management or multiple disks,
On 11/8/2014 5:36 AM, Kern Sibbald wrote:
> I think so. If I understand correctly, you want disk mount points or
> directories to be treated much like a tape drive, so that you can
> mount multiple "disks".
>
> I think this feature is already implemented, with one difference ...
> that when the d
On 11/07/2014 04:48 PM, Dmitri Maziuk wrote:
> On 11/7/2014 7:10 AM, Kern Sibbald wrote:
>> Hello,
>>
>> I am not sure, but it sounds like you are proposing that Bacula use a
>> raw device for storing a Volume. This is possible. There might be a
>> trivial advantage in terms of performance, but th
On 11/7/2014 7:10 AM, Kern Sibbald wrote:
> Hello,
>
> I am not sure, but it sounds like you are proposing that Bacula use a
> raw device for storing a Volume. This is possible. There might be a
> trivial advantage in terms of performance, but there is no real
> advantage or demand to do it.
The
Hello,
I am not sure, but it sounds like you are proposing that Bacula use a
raw device for storing a Volume. This is possible. There might be a
trivial advantage in terms of performance, but there is no real
advantage or demand to do it. It is, in general, far better to store
Volumes in a filesy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2014 08:23 PM, Dimitri Maziuk wrote:
> On 10/28/2014 01:46 PM, Alan
Brown wrote:
>> On 28/10/14 18:39, Dimitri Maziuk wrote:
>
>>> (As an aside, bacula, specifically, seems to force
On 10/28/2014 07:46 PM, Alan Brown wrote:
> On 28/10/14 18:39, Dimitri Maziuk wrote:
>
>> There is no reason to see file volumes as dedicated to a client AFAICT;
> Habit, I suspect. It's a bad one, given there's a database driving
> everything to tell you what is where.
>
>> (As an aside, bacula,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2014 07:39 PM, Dimitri Maziuk wrote:
> On 10/28/2014 01:04 PM, Alan
Brown wrote:
>>
>> Block devices may be block devices, but a tape drive is a
character device.
>
> Oops. Wo
On 10/28/2014 02:24 PM, Alan Brown wrote:
> On 28/10/14 12:46, Ana Emília M. Arruda wrote:
>
>> You have autochangers resources (fisical for tape librareis and virtual
>> for disks) in Bacula. They are a "pool of drives" to be used by your
>> jobs. I still think about having jobs and pools associa
On 10/28/2014 01:46 PM, Alan Brown wrote:
> On 28/10/14 18:39, Dimitri Maziuk wrote:
>> (As an aside, bacula, specifically, seems to force you to use different
>> Media Type for each physical device so I don't get how it would work
>> with multiple drives in the same jukebox, either -- thankfully
On Tue, Oct 28, 2014 at 3:46 PM, Alan Brown wrote:
> On 28/10/14 18:39, Dimitri Maziuk wrote:
>
> What it can't handle is that you can load media types LTO4 RW in the
> LTO5 drives and also LTO3 RO, which would be extremely handy.
>
>
You can get this just defining two device that references the
On 28/10/14 18:39, Dimitri Maziuk wrote:
> There is no reason to see file volumes as dedicated to a client AFAICT;
Habit, I suspect. It's a bad one, given there's a database driving
everything to tell you what is where.
> (As an aside, bacula, specifically, seems to force you to use different
>
On 10/28/2014 01:04 PM, Alan Brown wrote:
>
> Block devices may be block devices, but a tape drive is a character device.
Oops. Works either way, disks are char aka "raw" devices too.
> People coming from a tape environment tend to see tapes (volumes) as
> something you use for a pool of clients
On 28/10/14 14:59, Dmitri Maziuk wrote:
> OT comment: I'll probably never understand that, I always thought a
> block device is a block device and one of the unix's strong points was
> to abstract away the physical differences and let the same code work
> with either.
Block devices may be block d
I´m very very sorry. I´m not presuming to lecture you about what you
should do or should not be doing in your enterprise environment. Maybe my
english was too bad to lead to this embarrassment situation. I was just
trying to find, colaboring with all the others here, a solution for your
case, with
On 10/28/2014 9:24 AM, Alan Brown wrote:
> On 28/10/14 12:46, Ana Emília M. Arruda wrote:
>
>
>> , maybe
>> a second device definition for a job or pool could be more helpful than
>> a bacula-sd.conf reload on-the-fly or the enable/disable commands.
> This does not work. I've tried it.
>
> If an a
On 10/28/2014 8:24 AM, Alan Brown wrote:
...
> Tape and disk are different animals and need to be approached differently.
>
> Virtual autochangers are a kludge to allow for removable disks but in
> most configured installations they do _not_ treat those disks in the
> same way as real tape drives.
On 28/10/14 12:46, Ana Emília M. Arruda wrote:
> You have autochangers resources (fisical for tape librareis and virtual
> for disks) in Bacula. They are a "pool of drives" to be used by your
> jobs. I still think about having jobs and pools associated with clients
> instead of devices associated
On Mon, Oct 27, 2014 at 7:25 AM, Alan Brown wrote:
> On 24/10/14 23:27, Ana Emília M. Arruda wrote:
>
>> Maybe this could be usefull. But I'm still trying to understand why are
>> you using disk drives directly in archive device configuration.
>>
>
> We don't. We use tape drives.
IMHO.
You h
On 24/10/14 23:27, Ana Emília M. Arruda wrote:
> Maybe this could be usefull. But I'm still trying to understand why are
> you using disk drives directly in archive device configuration.
We don't. We use tape drives.
> I also think that backup software cannot be aware of hardware faliures.
I _st
I am not sure a disable drive command is *exactly* what he needs, but
that feature is already planned for the not too distant future.
ISP do typically want physical separation of data, which is possible
with pools and pool naming conventions rather than drives
(directories). The simplest appro
Very well said, thanks.
Kern
On 14-10-24 09:55 AM, Bryn Hughes wrote:
On 14-10-24 05:28 AM, Andrea Carpani wrote:
On 24/10/2014 12:47, Kern Sibbald wrote:
No, the SD and the FD cannot be reloaded. On the FD in principle it
would be easy, but on the SD, it would be complicated if drives
chang
Yes, your definition is clear, and it is what the Director does.
However, programming it is much more difficult, especially for the SD
where you are dealing with physical devices that are locked. In Apache,
the Bacula Director, and elsewhere there are not physical devices that
have to be lock
Maybe this could be usefull. But I'm still trying to understand why are you
using disk drives directly in archive device configuration. You have PB
backups. I suppose you have storage arrays with other fault tolerance
levels like raid, multipath, etc.. This way, until you have a disk failure
that m
On 24/10/14 18:02, Bryn Hughes wrote:
> On 14-10-24 09:32 AM, Alan Brown wrote:
>> (Why would you want to disable a drive? If it's offline because it
>> failed its cleaning cycle, as a f'instance)
> So what you need is a feature request to be able to disable a drive via
> bconsole Not to be ab
On 14-10-24 09:32 AM, Alan Brown wrote:
> (Why would you want to disable a drive? If it's offline because it
> failed its cleaning cycle, as a f'instance)
So what you need is a feature request to be able to disable a drive via
bconsole Not to be able to dynamically reload the SD configuration
On 24/10/14 13:55, Bryn Hughes wrote:
>
> Things would get really messy really fast, with practically no benefit.
> Your SD config likely changes what, once or twice per year? If that?
If you have a large setup like ours, it changes regularly.
Simply enabling/disabling individual drives within a
On 14-10-24 06:26 AM, Andrea Carpani wrote:
On 24/10/2014 14:55, Bryn Hughes wrote:
On 14-10-24 05:28 AM, Andrea Carpani wrote:
On 24/10/2014 12:47, Kern Sibbald wrote:
No, the SD and the FD cannot be reloaded. On the FD in principle it
would be easy, but on the SD, it would be complicated if
You´re welcome Andrea.
Regards,
Ana
On Fri, Oct 24, 2014 at 11:59 AM, Andrea Carpani <
andrea.carp...@dnshosting.it> wrote:
>
> On 24/10/2014 15:55, Ana Emília M. Arruda wrote:
>
> Hi Andrea,
>
> Have you heard about Virtual Autochanger? There is a very good white
> paper about at: http://blog
On 24/10/2014 15:55, Ana Emília M. Arruda wrote:
Hi Andrea,
Have you heard about Virtual Autochanger? There is a very good white
paper about at:
http://blog.bacula.org/whitepapers/CommunityDiskBackup.pdf.
Thanks Ana,
I'll take a look at this paper.
Regards,
.a.c.
-
liaarr...@gmail.com>>
Date: Friday, October 24, 2014 at 9:20 AM
Cc:
"Bacula-users@lists.sourceforge.net<mailto:Bacula-users@lists.sourceforge.net>"
mailto:bacula-users@lists.sourceforge.net>>
Subject: Re: [Bacula-users] Configuration reload for bacula-sd
Hi all,
>
>We also keep separate devices for every backup client so a restart is
>required quite frequently (whenever a client is added or is taken
>offline).
>
>Cheers, Uwe
I think there is no advantage on this aproach. But since you are going that way
maybe you could use also one storage darmon per
On Fri, Oct 24, 2014 at 03:26:59PM +0200, Andrea Carpani wrote:
> Ok, so I guess my need to reload it's conf often might come from the
> fact that I'm using it in a wrong way: I have no tape whatsoever, but a
> 40TB disk array I want to use to backup ~100 hosts.
> My plan was to use a separate d
Hi Andrea,
Have you heard about Virtual Autochanger? There is a very good white paper
about at: http://blog.bacula.org/whitepapers/CommunityDiskBackup.pdf.
Better than thinking about one storage device per host, I recommend you
having a virtual autochanger with all your devices defined (it could
On 24/10/2014 14:55, Bryn Hughes wrote:
On 14-10-24 05:28 AM, Andrea Carpani wrote:
On 24/10/2014 12:47, Kern Sibbald wrote:
No, the SD and the FD cannot be reloaded. On the FD in principle it
would be easy, but on the SD, it would be complicated if drives
changed. What would you do with Jobs
Hi all,
I totally agree with Bryn. Even more when you think about your volumes.
Bacula links volumes to devices and it is not a really good idea so
frequent changes (deleting devices from bacula-sd.cionf) in your devices.
This way you will have lots of trouble with volumes that does not have its
d
On 14-10-24 05:28 AM, Andrea Carpani wrote:
On 24/10/2014 12:47, Kern Sibbald wrote:
No, the SD and the FD cannot be reloaded. On the FD in principle it
would be easy, but on the SD, it would be complicated if drives
changed. What would you do with Jobs that are using a drive that
would be rem
On 24/10/2014 12:47, Kern Sibbald wrote:
> No, the SD and the FD cannot be reloaded. On the FD in principle it
> would be easy, but on the SD, it would be complicated if drives
> changed. What would you do with Jobs that are using a drive that
> would be removed from the reload?
I'm not that
No, the SD and the FD cannot be reloaded. On the FD in principle it
would be easy, but on the SD, it would be complicated if drives
changed. What would you do with Jobs that are using a drive that would
be removed from the reload?
Kern
On 14-10-24 04:48 AM, Andrea Carpani wrote:
> Hi all,
>
> Hi all,
>
> I'm still new to the product and I was playing around with Bacula 5.2.6
> (latest packages that come with CentOS 6.5). I added a new storage
> device to the Storage Daemon. I tried to run a job that used this
> device, but the backup failed apparently because bacula-sd wan't aware
>
: [Bacula-users] Configuration reload for bacula-sd
Hi all,
I'm still new to the product and I was playing around with Bacula 5.2.6
(latest packages that come with CentOS 6.5). I added a new storage
device to the Storage Daemon. I tried to run a job that used this
device, but the backup faile
+1
Sent while mobile.
> Am 24.10.2014 um 10:11 schrieb Uwe Schuerkamp :
>
>> On Fri, Oct 24, 2014 at 09:48:25AM +0200, Andrea Carpani wrote:
>> Hi all,
>>
>> I'm still new to the product and I was playing around with Bacula 5.2.6
>> (latest packages that come with CentOS 6.5). I added a new st
On Fri, Oct 24, 2014 at 09:48:25AM +0200, Andrea Carpani wrote:
> Hi all,
>
> I'm still new to the product and I was playing around with Bacula 5.2.6
> (latest packages that come with CentOS 6.5). I added a new storage
> device to the Storage Daemon. I tried to run a job that used this
> device
Hi all,
I'm still new to the product and I was playing around with Bacula 5.2.6
(latest packages that come with CentOS 6.5). I added a new storage
device to the Storage Daemon. I tried to run a job that used this
device, but the backup failed apparently because bacula-sd wan't aware
of this ne
55 matches
Mail list logo
