[Bacula-users] Configuration reload for bacula-sd

Post by Andrea Carpani
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 new device.
I tried to use
service bacula-sd reload
but this didn't work, so I had to restart bacula-sd, but this broke my
running backups. So my question is: is there a way to reload bacula-sd
configuration on the fly?
regards,
Andrea
.a.c.

--
NIONEX --- Ein Unternehmen der Bertelsmann SE & Co. KGaA

------------------------------------------------------------------------------

Robert Oschwald

2014-10-24 08:20:26 UTC

+1

Sent while mobile.

Post by Uwe Schuerkamp

This would indeed be a great feature to have. We use separate devices
for each client (on-disk volumes for full and incr. jobs), and
currently we have to wait for all jobs to complete before reloading
the sd in order to configure the new devices. A reload triggered by
sending the sd a signal would be very cool.
Uwe
--
NIONEX --- Ein Unternehmen der Bertelsmann SE & Co. KGaA
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

------------------------------------------------------------------------------

Luc Van der Veken

2014-10-24 08:24:22 UTC

I've noticed this under Ubuntu (Server 12.04) too.
It looks like reload doesn't have any effect for bacula-sd 5.2.x, so you have to wait until no jobs are running and then restart it.

I haven't tried to figure out if it is a limitation in bacula-sd or a configuration error in the service commands that control it, because my backups run at night and I only make configuration changes during daytime anyhow.

-----Original Message-----
From: Andrea Carpani [mailto:***@dnshosting.it]
Sent: 24 October 2014 9:48
To: bacula-***@lists.sourceforge.net
Subject: [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 failed apparently because bacula-sd wan't aware
of this new device.

I tried to use

service bacula-sd reload

but this didn't work, so I had to restart bacula-sd, but this broke my
running backups. So my question is: is there a way to reload bacula-sd
configuration on the fly?

regards,

Andrea
.a.c.

Davide Giunchi

2014-10-24 08:43:32 UTC

No, you can reload the bacula-dir daemon with the "reload" bconsole's command, but you can't reload the bacula-sd daemon.

Regards

--
Certificazioni: RHCVA, LPI 1
SOASI - www.soasi.com
Sviluppo Software e Sistemi Open Source
Sede: Via Gandhi 28, 47121 Forlì (FC)
Tel.: +39 0543 090053 - Fax: +39 0543 579928

------------------------------------------------------------------------------

Kern Sibbald

2014-10-24 10:47:16 UTC

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

------------------------------------------------------------------------------

Andrea Carpani

2014-10-24 12:28:38 UTC

I'm not that deep into backup software, so maybe I'm saying something
stupid, but a config reload could do the same thing that other software
do, that is:
- continue servicing current requests with the previous conf and
- use the new conf for new requests.

Something like a graceful restart apache does.

Does this make sense?

.a.c.

------------------------------------------------------------------------------

Bryn Hughes

2014-10-24 12:55:19 UTC

I'm not that deep into backup software, so maybe I'm saying something
stupid, but a config reload could do the same thing that other software
- continue servicing current requests with the previous conf and
- use the new conf for new requests.
Something like a graceful restart apache does.
Does this make sense?
.a.c.

Sense to humans yes, sense to program code not so much.

The nature of the SD is that its configuration should almost never
change - all it has for config is an inventory of hardware devices.
There's a certain elegance in simplicity that would be lost trying to
cover what should be a fairly narrow use case.

Imagine all the debugging you have to do - is this job failing because
it is trying to use the config as it appears in the config file, or some
other config in memory from some time in the past? What happens if we
now have different device names referring to the same physical device,
we now need a whole locking mechanism that can cover the use case of
multiple versions of the SD config accessing the same physical device,
possibly with different parameters and names. How would you be able to
tell which version of the config a given job is using? Remember it is
easy to start a backup job that can last a couple of days - a full
backup of a huge fileserver for instance.

Things would get really messy really fast, with practically no benefit.
Your SD config likely changes what, once or twice per year? If that?
It is much safer to just restart the SD when you have an idle period
between backups.

Bryn

Ana Emília M. Arruda

2014-10-24 13:20:54 UTC

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
device anymore. You should be aware of migrating these jobs before deleting
devices from your bacula-sd.conf all the time.

Best regards,
Ana

Post by Kern Sibbald
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 deep into backup software, so maybe I'm saying something
stupid, but a config reload could do the same thing that other software
- continue servicing current requests with the previous conf and
- use the new conf for new requests.
Something like a graceful restart apache does.
Does this make sense?
.a.c.
Sense to humans yes, sense to program code not so much.
The nature of the SD is that its configuration should almost never change
- all it has for config is an inventory of hardware devices. There's a
certain elegance in simplicity that would be lost trying to cover what
should be a fairly narrow use case.
Imagine all the debugging you have to do - is this job failing because it
is trying to use the config as it appears in the config file, or some other
config in memory from some time in the past? What happens if we now have
different device names referring to the same physical device, we now need a
whole locking mechanism that can cover the use case of multiple versions of
the SD config accessing the same physical device, possibly with different
parameters and names. How would you be able to tell which version of the
config a given job is using? Remember it is easy to start a backup job
that can last a couple of days - a full backup of a huge fileserver for
instance.
Things would get really messy really fast, with practically no benefit.
Your SD config likely changes what, once or twice per year? If that? It
is much safer to just restart the SD when you have an idle period between
backups.
Bryn
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

Clark, Patricia A.

2014-10-24 14:46:30 UTC

I am going to disagree with Bryn and Ana. The only reason to agree is human error and how the current SD configuration is implemented. Based on the number of queries on this list for managing devices, human error is prone to be high, and as for the SD configuration it is a static manual configuration file. I'd prefer a dynamic interactive SD interface that permits adding/removing devices on-the-fly. It's a harder implementation and a total rewrite. So, reloading the config file, once due diligence has been done on the OS level, should be permitted and it should replace what is currently in memory. Displaying a before/after config and requiring confirmation on the reload would "save" some folks.

Patti Clark
Linux System Administrator
R&D Systems Support Oak Ridge National Laboratory
865-576-7718

From: "Ana Emília M. Arruda" <***@gmail.com<mailto:***@gmail.com>>
Date: Friday, October 24, 2014 at 9:20 AM
Cc: "Bacula-***@lists.sourceforge.net<mailto:Bacula-***@lists.sourceforge.net>" <bacula-***@lists.sourceforge.net<mailto:bacula-***@lists.sourceforge.net>>
Subject: Re: [Bacula-users] Configuration reload for bacula-sd

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 device anymore. You should be aware of migrating these jobs before deleting devices from your bacula-sd.conf all the time.

Best regards,
Ana

On Fri, Oct 24, 2014 at 9:55 AM, Bryn Hughes <***@nashira.ca<mailto:***@nashira.ca>> 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 that are using a drive that
would be removed from the reload?
I'm not that deep into backup software, so maybe I'm saying something
stupid, but a config reload could do the same thing that other software
do, that is:
- continue servicing current requests with the previous conf and
- use the new conf for new requests.

Something like a graceful restart apache does.

Does this make sense?

.a.c.
Sense to humans yes, sense to program code not so much.

The nature of the SD is that its configuration should almost never change - all it has for config is an inventory of hardware devices. There's a certain elegance in simplicity that would be lost trying to cover what should be a fairly narrow use case.

Imagine all the debugging you have to do - is this job failing because it is trying to use the config as it appears in the config file, or some other config in memory from some time in the past? What happens if we now have different device names referring to the same physical device, we now need a whole locking mechanism that can cover the use case of multiple versions of the SD config accessing the same physical device, possibly with different parameters and names. How would you be able to tell which version of the config a given job is using? Remember it is easy to start a backup job that can last a couple of days - a full backup of a huge fileserver for instance.

Things would get really messy really fast, with practically no benefit. Your SD config likely changes what, once or twice per year? If that? It is much safer to just restart the SD when you have an idle period between backups.

Bryn

Andrea Carpani

2014-10-24 13:26:59 UTC

Sense to humans yes, sense to program code not so much.
The nature of the SD is that its configuration should almost never
change - all it has for config is an inventory of hardware devices.
There's a certain elegance in simplicity that would be lost trying to
cover what should be a fairly narrow use case.
Imagine all the debugging you have to do - is this job failing because
it is trying to use the config as it appears in the config file, or
some other config in memory from some time in the past? What happens
if we now have different device names referring to the same physical
device, we now need a whole locking mechanism that can cover the use
case of multiple versions of the SD config accessing the same physical
device, possibly with different parameters and names. How would you
be able to tell which version of the config a given job is using?
Remember it is easy to start a backup job that can last a couple of
days - a full backup of a huge fileserver for instance.
Things would get really messy really fast, with practically no
benefit. Your SD config likely changes what, once or twice per year?
If that? It is much safer to just restart the SD when you have an
idle period between backups.
Bryn

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 directory (i.e.: storage device) to keep
backups for each server. Each "storage device" would contain backup
files (volumes) grouped in a "Volume pool" (one for each host). Ideally
each volume includes data for a single job, but we can skip this for now.

I want such setup because hosts come and go and I want to be able to
easily delete backup files and reclaim disk space if a host is dismissed.

Can someone suggest me a better way to manage this?

Regards

Andrea
.a.c.

Ana Emília M. Arruda

2014-10-24 13:55:44 UTC

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 be
about 200 devices, maybe more than the number of hosts you expect to have).
This way, you will always have a device available for a host backup job.
And then you think about having "pools per hosts" (Host1FullPool,
Host1DiffPool, Host2FullPoll, etc.), instead of having storages devices per
hosts. This way, when your host goes away, you can just delete the pool
that contains its volumes.

Regards,
Ana

On Fri, Oct 24, 2014 at 10:26 AM, Andrea Carpani <

Post by Kern Sibbald
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 deep into backup software, so maybe I'm saying something
stupid, but a config reload could do the same thing that other software
- continue servicing current requests with the previous conf and
- use the new conf for new requests.
Something like a graceful restart apache does.
Does this make sense?
.a.c.
Sense to humans yes, sense to program code not so much.
The nature of the SD is that its configuration should almost never change
- all it has for config is an inventory of hardware devices. There's a
certain elegance in simplicity that would be lost trying to cover what
should be a fairly narrow use case.
Imagine all the debugging you have to do - is this job failing because it
is trying to use the config as it appears in the config file, or some other
config in memory from some time in the past? What happens if we now have
different device names referring to the same physical device, we now need a
whole locking mechanism that can cover the use case of multiple versions of
the SD config accessing the same physical device, possibly with different
parameters and names. How would you be able to tell which version of the
config a given job is using? Remember it is easy to start a backup job
that can last a couple of days - a full backup of a huge fileserver for
instance.
Things would get really messy really fast, with practically no benefit.
Your SD config likely changes what, once or twice per year? If that? It
is much safer to just restart the SD when you have an idle period between
backups.
Bryn
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 directory (i.e.: storage device) to keep
backups for each server. Each "storage device" would contain backup files
(volumes) grouped in a "Volume pool" (one for each host). Ideally each
volume includes data for a single job, but we can skip this for now.
I want such setup because hosts come and go and I want to be able to
easily delete backup files and reclaim disk space if a host is dismissed.
Can someone suggest me a better way to manage this?
Regards
Andrea
.a.c.
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

Andrea Carpani

2014-10-24 14:59:16 UTC

Post by Ana EmÃlia M. Arruda
Hi Andrea,
Have you heard about Virtual Autochanger? There is a very good white
http://blog.bacula.org/whitepapers/CommunityDiskBackup.pdf.

Thanks Ana,

I'll take a look at this paper.

Regards,

.a.c.

Ana Emília M. Arruda

2014-10-24 15:21:12 UTC

YouÂŽre welcome Andrea.

Regards,
Ana

On Fri, Oct 24, 2014 at 11:59 AM, Andrea Carpani <

Post by Ana EmÃlia M. Arruda
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.
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

Uwe Schuerkamp

2014-10-24 14:15:16 UTC

Post by Andrea Carpani
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 directory (i.e.: storage device) to keep
backups for each server. Each "storage device" would contain backup
files (volumes) grouped in a "Volume pool" (one for each host). Ideally
each volume includes data for a single job, but we can skip this for now.
I want such setup because hosts come and go and I want to be able to
easily delete backup files and reclaim disk space if a host is dismissed.
Can someone suggest me a better way to manage this?

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

--
NIONEX --- Ein Unternehmen der Bertelsmann SE & Co. KGaA

------------------------------------------------------------------------------

Heitor Faria

2014-10-24 14:39:54 UTC

Post by Uwe Schuerkamp
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 device?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

------------------------------------------------------------------------------

Bryn Hughes

2014-10-24 16:26:51 UTC

Sense to humans yes, sense to program code not so much.
The nature of the SD is that its configuration should almost never
change - all it has for config is an inventory of hardware devices.
There's a certain elegance in simplicity that would be lost trying to
cover what should be a fairly narrow use case.
Imagine all the debugging you have to do - is this job failing
because it is trying to use the config as it appears in the config
file, or some other config in memory from some time in the past? What
happens if we now have different device names referring to the same
physical device, we now need a whole locking mechanism that can cover
the use case of multiple versions of the SD config accessing the same
physical device, possibly with different parameters and names. How
would you be able to tell which version of the config a given job is
using? Remember it is easy to start a backup job that can last a
couple of days - a full backup of a huge fileserver for instance.
Things would get really messy really fast, with practically no
benefit. Your SD config likely changes what, once or twice per
year? If that? It is much safer to just restart the SD when you
have an idle period between backups.
Bryn

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 directory (i.e.: storage device) to keep
backups for each server. Each "storage device" would contain backup
files (volumes) grouped in a "Volume pool" (one for each host).
Ideally each volume includes data for a single job, but we can skip
this for now.
I want such setup because hosts come and go and I want to be able to
easily delete backup files and reclaim disk space if a host is dismissed.
Can someone suggest me a better way to manage this?
Regards
Andrea
.a.c.

Aha, the root cause emerges... ;)

A better way would be to use a file pool and let Bacula worry about
managing things. Really there is no need to be worrying about where
your individual files are located - that's why you have a director with
a database. It knows which files are associated with which hosts,
there's no need to be adding another layer of complexity. When you do a
restore you ask Bacula to restore a given host, it knows where the data
is, it loads up the correct files and takes care of everything.

Bryn

Alan Brown

2014-10-24 16:32:56 UTC

Post by Bryn Hughes
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 an autochanger
requires a SD restart - which means we need to shut down ALL backups in
progress - not a trivial undertaking when you're backing up a couple of
PB of data every month.

(Why would you want to disable a drive? If it's offline because it
failed its cleaning cycle, as a f'instance)

------------------------------------------------------------------------------

Bryn Hughes

2014-10-24 17:02:13 UTC

Post by Alan Brown
(Why would you want to disable a drive? If it's offline because it
failed its cleaning cycle, as a f'instance)

Alan Brown

2014-10-24 17:57:19 UTC

Post by Alan Brown
(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.

When the drive is replaced, its by-id changes, which has a ripple effect
across the configuration (This is one of the reasons I use symlinks from
"bacula ID" to the by-id, which in turn links to the real device.)

_BOTH_ features are useful (and there are tickets in bacula enterprise
for them already)

Post by Bryn Hughes
Bryn
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

------------------------------------------------------------------------------

Ana Emília M. Arruda

2014-10-24 22:27:19 UTC

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 make your Ã€rchive device" unavailable for bacula, you will have enough
time to take the necessary actions to avoid this.

I also think that backup software cannot be aware of hardware faliures.
Instead this is a problem that has to be treated in another fault tolerance
level.

Sorry If I am misunderstooding the problem here.

Best regards,
Ana

Post by Alan Brown
(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.

When the drive is replaced, its by-id changes, which has a ripple effect
across the configuration (This is one of the reasons I use symlinks from
"bacula ID" to the by-id, which in turn links to the real device.)
_BOTH_ features are useful (and there are tickets in bacula enterprise
for them already)

Post by Bryn Hughes
Bryn

------------------------------------------------------------------------------

Post by Bryn Hughes
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

Alan Brown

2014-10-27 10:26:28 UTC

Post by Ana EmÃlia M. Arruda
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.

Post by Ana EmÃlia M. Arruda
I also think that backup software cannot be aware of hardware faliures.

I _strongly_ disagree, especially in an enterprise-scale setup.

------------------------------------------------------------------------------

Ana Emília M. Arruda

2014-10-28 12:46:30 UTC

Post by Ana EmÃlia M. Arruda
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 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 with clients are the better choice.

In spite of this, If you have to work with tape drives (stand alone or tape
library ones connected directly - not in a fabric topology), 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. I mean, if
the first drive designated for the job or the pool falis (director could
check if no response is received, like it already does) and then director
instructs the use of the second drive, present in job or pools definition
of storage (Storage = Drive-1, Drive-2). This way it is not necesary to
reastart the failed job (once it could not run because of the drive
failure) and you can have enough time to change the crashed drive and no
changes in bacula-sd.conf would be necesary since you will have symlinks
for the archive device configuration.

Post by Alan Brown
I also think that backup software cannot be aware of hardware faliures.
I _strongly_ disagree, especially in an enterprise-scale setup.

âSorry Alan, in an enterprise-scale setup, you need, as I mentioned before,
other fault tolerance levels (disk-to-disk backups in storage arrays before
disse-to-tape backup, raids, multipaths, etc.)â.

âBest regards,
Anaâ

Alan Brown

2014-10-28 13:24:51 UTC

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 with clients are the better choice.

Devices are not associated with any clients. They're used as-available.
Tying devices to clients is an unnecessary restriction on resources and
generally indicates accountants gone mad or lack of thought about what
you are trying to achieve.

In spite of this, If you have to work with tape drives (stand alone or
tape library ones connected directly - not in a fabric topology)

They are fabric connected.

, 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 autochanger tape drive fails, jobs pile up behind it.

What's far worse than a drive failing is one getting dirty - they spend
forever doing rewrites and througput drops from hundreds of Mb per
second to 10-20, WITHOUT raising errors in the backup system - and
running a cleaning tape doesn't work in a lot of cases (LTO drives are
self cleaning, If you need a tape then you're already in trouble)

This is far from ideal behaviour, especially when there are petabytes of
science data involved.

The only way out of either situation at the moment involves restarting
the storage daemon, which kills ALL jobs running on ALL drives.

Comment: Please don't presume to lecture me about what I should or
should not be doing in my enterprise environment, or indeed about the
way systems are setup (it's all fabric path for starters and bacula does
not do d2d unless you count disk spooling - which we use intensively),
you have no idea of the operational constraints on my site and you're
making a bunch of fairly arrogant assumptions about the way things are
run which impinge on the way you think Bacula should operate.

It's this kind of attitude which results in inflexible software that
gets sworn at, rather than sworn by.

Thankfully Kern and his team are well aware that needs vary depending on
setups and that multiple-tape drive setups need improvement.

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.

------------------------------------------------------------------------------

Dmitri Maziuk

2014-10-28 14:59:12 UTC

On 10/28/2014 8:24 AM, Alan Brown wrote:
...

Post by Alan Brown
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.

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. AFAICT the only reason they're different (in how SD treats
them) is because the software is written that way...

Dima

------------------------------------------------------------------------------

Alan Brown

2014-10-28 18:15:27 UTC

Post by Dmitri Maziuk
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 devices, but a tape drive is a character device.

Post by Dmitri Maziuk
AFAICT the only reason they're different (in how SD treats
them) is because the software is written that way...

It's more about the way people approach the configuration and that has
much more to do with sequential vs random access and device naming
conventions.

People coming from a disk-environment tend to see files on disks
(volumes) as dedicated to a client, because you can trivially skip from
volume to volume and access multiple volumes simultaneously.

People coming from a tape environment tend to see tapes (volumes) as
something you use for a pool of clients or filesets, because changing
volumes is NOT trivial, the tapes are only reated for a limited number
of load cycles and you can only access one volume at a time.

If you have more tape drives you can access more volumes simultaneously,
but changing volumes is no less difficult/timeconsuming.

------------------------------------------------------------------------------

Dimitri Maziuk

2014-10-28 18:39:56 UTC

Post by Alan Brown
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.

Post by Alan Brown
People coming from a tape environment tend to see tapes (volumes) as
something you use for a pool of clients or filesets, because changing
volumes is NOT trivial, the tapes are only reated for a limited number
of load cycles and you can only access one volume at a time.
If you have more tape drives you can access more volumes simultaneously,
but changing volumes is no less difficult/timeconsuming.

As is changing disks. Skipping from one tarball to another on tape may
take much longer, but that shouldn't make any difference to the
higher-level code.

There is no reason to see file volumes as dedicated to a client AFAICT;
those who want it can do pool per client and volumes per pool -- works
with tapes just as well.

Yes, in general you can access multiple files on the same disk
simultaneously. I don't expect that a backup application streaming data
to or from that disk would -- or should -- actually do that, for any
number of obvious reasons.

Which is why I'll never understand the tape/disk dichotomy.

(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 I don't
need to.)

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

Alan Brown

2014-10-28 18:46:06 UTC

Post by Dimitri Maziuk
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.

Post by Dimitri Maziuk
(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 I don't
need to.)

It's been more than happy to set the media type to LTO-5 on 7 drives,
LTO-2 on 2 (different changer) and LTO-6 on another.

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.

------------------------------------------------------------------------------

Ana Emília M. Arruda

2014-10-28 19:12:35 UTC

Post by Alan Brown
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 same drive:
one that will work with LTO4 tapes and the other will work with the LTO5
tapes. I have this configured and it is working fine. The same tape library
reads/writes LTO-3 and LTO-5 HP tapes.â

Is this could be best configured? Yes, I think. If we could set "Media type
= LTO-3. LTO-4". But this is still not implemented and IÂŽm not sure about
the difficulties this should represent. Because in database we have a
volume (tape) associated with a media type. Maybe if we could have another
"media type" directive for pools. So we could say: this device can
read/write LTO-4 and LTO-5 types, but the volumes in this pool are from
media type = LTO-5.

Post by Alan Brown
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

Dimitri Maziuk

2014-10-28 19:23:41 UTC

It's been more than happy to set the media type to LTO-5 on 7 drives,
LTO-2 on 2 (different changer) and LTO-6 on another.
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.

We used ait-1 tapes in ait-3 drive with notworker and just ignored the
"premature eot" (or whatever it was) barf.

But I was referring to Kern's

Post by Alan Brown
Date: Sat, 11 May 2013 07:32:37 +0200
Subject: Re: [Bacula-users] backup to multiple disks

...

Post by Alan Brown
Yes, Media Type is very important. It must
be in the Storage resources on the Director
side, and notice that as I mentioned before, on
the SD side, Autochanger really just groups a
number of Devices. The Media Type must be
in each Device, because each one can be different
so it is not in the Autochanger resource.
There is no restriction for multiple devices to have
the same Media Type, but if they are disk devices
and don't have the same Archive Device, Bacula
won't be able to "mount" them. So, use the same
Media Type only in Devices that have the same Archive
Device.

I expect someone had reasons to code it that way for disk devices
specifically, and they may even seemed good at the time....

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

Kern Sibbald

2014-11-06 18:06:22 UTC

------------------------------------------------------------------------------

Kern Sibbald

2014-11-06 18:02:17 UTC

Post by Dimitri Maziuk
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.

It's been more than happy to set the media type to LTO-5 on 7 drives,
LTO-2 on 2 (different changer) and LTO-6 on another.
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.

This is on our list ...

------------------------------------------------------------------------------

Kern Sibbald

2014-11-06 18:01:35 UTC

------------------------------------------------------------------------------

Ana Emília M. Arruda

2014-11-10 12:31:41 UTC

â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
between tape drives and LTO generations: the hardware reads data from
catridges in its own generation and at least two prior ones and writes in
its own generation and to catridges that are in the immediately prior
generation (using the immediately prior generation format). Suppose you
have an LTO-3 drive working with LTO-3 catridges and you upgrade your
hardware to an LTO-5 drive that will not write to your LTO-3 catridges
because of compatibility. If you just specify "Media Type = LTO", Bacula
will try to read and write to all the LTO-3 and LTO-5 catridges and this
will no work. Is there another way of distinguishing different LTO catridge
generations? Normally I have been using this way: having two storage device
definitions for the same drive, each one working with an LTO catridge
generation.

Best regards,
Ana

Post by Dimitri Maziuk
Which is why I'll never understand the tape/disk dichotomy.
(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 I don't
need to.)

To be more precise, Bacula does not require you to use different Media
Types for different devices. It only does so for different disk devices so
that it can be sure where the Volume is actually stored. For a compatible
tape drives in an autochanger, there is no need to have different Media
Types. However, if you have multiple separate libraries the Media Type
must be different so that Bacula is sure what library the Volume is in (it
actually keeps a device index, but this is often insufficient).
Best regards,
Kern

Post by Dimitri Maziuk
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlRbt38ACgkQNgfoSvWqwEjnUQCfSOAEbCisEiI5zfGS2roZ1sEL
V0EAn28D4+yLzkzOcwfszYq5q3qOfy12
=mf19
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

m***@uphs.upenn.edu

2014-11-10 16:58:15 UTC

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
<Re: [Bacula-users] Configuration reload for bacula-sd> were:
=> ------------------------------------------------------------------------------

=> 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

It would be great if Bacula was enhanced to add more intelligence to
the definition of storage devices, including specifying a list of media
types that the storage device can use 'read+write' or use 'read-only'.

=> have an LTO-3 drive working with LTO-3 catridges and you upgrade your
=> hardware to an LTO-5 drive that will not write to your LTO-3 catridges

That's close to our situation, as we have gone from LTO2 -> LTO3 -> LTO4.

=> because of compatibility. If you just specify "Media Type = LTO", Bacula

Even more confusing, when we began using Bacula, we had just LTO2 drives
& media, so all the initial media was labled "LTO2". When we upgraded
to LTO3, we had the choice of correctly labling the new media as "LTO3"
and then losing access to all our LTO2 media since Bacula cannot deal
with multiple media types in a single SD, or deliberately incorrectly
labling our LTO3 media as "LTO2", or using multiple SD definitions for
the same physical tape drives.

We chose to label all our media (LTO2, LTO3, and LTO4) as "LTO2"
within Bacula.

We use printed barcode labels to name each piece of media, and are using
a convention where the first non-zero digit in the name is the LTO
type. For example, tape 004079 is an LTO4 tape, while 003134 is LTO3
media. This makes it easy for human beings to distinguish the actual
media types.

=> will try to read and write to all the LTO-3 and LTO-5 catridges and this
=> will no work. Is there another way of distinguishing different LTO catridge
=> generations? Normally I have been using this way: having two storage device

Our solution has been to to label all media as "LTO2", but to set the actual
LTO2 tapes as "read-only" within Bacula.

=> definitions for the same drive, each one working with an LTO catridge
=> generation.

I dislike that idea, as it will cause problems with backups. For example,
if a backup job begins with LTO3 media, loaded into a drive under the LTO3
definition for that SD, and the remaining available cartridges in the tape
changer are LTO4 media, then the backup will wait on operator intervention
until an LTO3 tape is supplied, rather than using one of the LTO4 tapes.

=>
=> Best regards,
=> Ana
=>

--
Mark Bergman voice: 215-662-7310
***@uphs.upenn.edu fax: 215-614-0266
http://www.cbica.upenn.edu/
IT Technical Director, Center for Biomedical Image Computing and Analytics
Department of Radiology University of Pennsylvania
PGP Key: http://www.cbica.upenn.edu/sbia/bergman

------------------------------------------------------------------------------

Kern Sibbald

2014-11-07 13:10:39 UTC

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 filesystem rather than on a raw disk for a number of
reasons. It would even be preferable to dedicate a disk to Bacula and
have a filesystem on it such as XFS rather than use it as a raw device.

Maybe you can be more precise about what you want.

By the way, the Bacula code that writes disk and tape is virtually
identical. Only the open and close and seek is different. The seeking
on tape devices is far more complex than seeking on a disk, which is
byte oriented (at least at the application level), rather than
file/block oriented as a tape device is.

Best regards,
Kern

Post by Dmitri Maziuk
...

------------------------------------------------------------------------------

Dmitri Maziuk

2014-11-07 15:48:26 UTC

Post by Kern Sibbald
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 advantage is you can pull the disk out and stick a new one in, just
like you do with the tape.

... It is, in general, far better to store

Post by Kern Sibbald
Volumes in a filesystem rather than on a raw disk for a number of
reasons. It would even be preferable to dedicate a disk to Bacula and
have a filesystem on it such as XFS rather than use it as a raw device.

I agree, however, in the current implementation volumes are files that
must reside in a single filesystem (or you need a fake autochanger). If
volumes were directories (i.e. mountpoints), we could use multiple
removable disks, pull full disk out, stick new one in.

Post by Kern Sibbald
Maybe you can be more precise about what you want.

Was that clear enough?

Dima

------------------------------------------------------------------------------

Kern Sibbald

2014-11-08 11:36:14 UTC

The advantage is you can pull the disk out and stick a new one in,
just like you do with the tape.
... It is, in general, far better to store

I agree, however, in the current implementation volumes are files that
must reside in a single filesystem (or you need a fake autochanger).
If volumes were directories (i.e. mountpoints), we could use multiple
removable disks, pull full disk out, stick new one in.

Post by Kern Sibbald
Maybe you can be more precise about what you want.

Was that clear enough?

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 from
what I believe you are requesting. Bacula can already deal with a mount
point where the physical device is removable such as a USB key,
providing your tell Bacula that it is removable. The difference is that
when the device is mounted, it assumes that it has a filesystem on it
rather than treating it as a raw device. When the device is first
mounted, Bacula will scan for what volumes are on that device.

Much like the Virtual Autochanger feature, I am not 100% sure where this
is documented, so you may have to search for it. The main requirement
for it to work is to configure the SD Device (even if it is a disk
device) as removable. I wrote the code to handle backup to USB keys
while I was on vacation -- I just plugged in any USB key, and if there
were any Volumes on the device, they would be used, which is mostly what
you are requesting.

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 community version
(slightly different from the Enterprise version).

www.bacula.org -> Documentation -> White Papers

Best regards,
Kern

Post by Dmitri Maziuk
Dima

------------------------------------------------------------------------------

Dmitri Maziuk

2014-11-08 18:35:08 UTC

Post by Kern Sibbald
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 device is mounted, it assumes that it has a
filesystem on it rather than treating it as a raw device.

Either way works, filesystem makes it easy to see what's on it, but you
have to mkfs on a new disk.

Post by Kern Sibbald
Much like the Virtual Autochanger feature, I am not 100% sure where this
is documented, so you may have to search for it. The main requirement
for it to work is to configure the SD Device (even if it is a disk
device) as removable.

"Devices that require a mount (USB)" in
http://www.bacula.org/7.0.x-manuals/en/main/Storage_Daemon_Configuratio.html#SECTION001730000000000000000
says, among other things, "write part command must be defined". "Write
part command" is somewhat documented in "Devices that require a mount
(DVD)" in docs for 5.0 and below, but not in 7.0. Its purpose is
unclear, my guess would be it's intended for "write to optical disk but
not close it", no idea how or why that would apply to a usb stick.

From reading that section I can't figure out the config for 12-bay
hot-swap sata storage server where I can write to all disks and replace
them as they get full, just like they were tapes. (But see my reading
comprehension note below.)

I notice now, thanks.

CommunityDiskBackup.pdf has the same old problem in 2.1 Grouping Storage
Devices: as usual, it talks multiple devices and shows 2 Device
definitions with Archive Device = /disk in both. Personally I don't know
how to mount multiple physical devices in the same /disk at the same
time and keep them separate too.

Same goes for 2.2 Virtual Autochanger: it doesn't let you write to
multiple (disk) devices, it lets bacula treat a single Archive Device as
"multipe devices" -- presumably for concurrent access.

Same goes for section 3 (Multiple Devices) in CommunityDiskBackupDesign.pdf

At least that's what I read in there. Maybe I'm not reading it right:
the years have not been kind and my leet reading comprehension skillz
ain't what they used to be.

The rest of it is very useful but not germane to the topic of using
multiple hot-swappable disks for storage.

This is all great but so far the only known config I've actually seen
working is a vchanger. I'd consider buying it off and rolling it into
bacula proper so instead of much handwaving and allegations of "maybe
documented somewhere" features you'd have a definitive and working
answer for retentive assholes like me.

Dima

------------------------------------------------------------------------------

Dmitri Maziuk

2014-11-08 20:20:01 UTC

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, but not both.

Dima

------------------------------------------------------------------------------

Kern Sibbald

2014-11-09 12:07:35 UTC

Post by Dmitri Maziuk
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, but not both.

As mentioned in a prior response, Bacula *may* actually permit both
providing each disk has its own filesystem (path).

I would add small nuance to what you wrote: if Bacula does *only* allow
either automatic volume management or multiple disks, it is not by
"design", but rather because other than some elementary USB stick code I
wrote and the no longer used DVD code, we never thought about dealing
with the particularities of hot-swappable disks.

By the way, during my vacation I noticed that you gave some very helpful
advice on this list -- thanks.

Kern

Post by Dmitri Maziuk
Dima

------------------------------------------------------------------------------

Kern Sibbald

2014-11-09 11:53:28 UTC

Either way works, filesystem makes it easy to see what's on it, but
you have to mkfs on a new disk.

It looks like the document is out of date. I am not sure we ever made a
pass through the manual to remove the DVD documentation. In any case, a
mount command may or may not be necessary for doing USB, but the "Write
Part Command" is definitely not needed and indeed not used any more.

Post by Dmitri Maziuk
From reading that section I can't figure out the config for 12-bay
hot-swap sata storage server where I can write to all disks and
replace them as they get full, just like they were tapes. (But see my
reading comprehension note below.)

I don't remember what the configuration would be, because I have not
used the feature for about 5 years, but the first step would be to play
with setting "Removable Media" to true, then looking at whether or not
"Requires Mount" and the "Mount Point" and "Mount Command" are needed.
If you have setup your USB to be automatically mounted, which seems to
be the default now, but was not when I used the feature, you may not
need any mount commands, though if the operator must explicitly remove
and replace a disk, I imagine they will be required.

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 Types otherwise, Bacula will
not know the right directory to look in for "fixed" disks.

Post by Dmitri Maziuk
Same goes for 2.2 Virtual Autochanger: it doesn't let you write to
multiple (disk) devices, it lets bacula treat a single Archive Device
as "multipe devices" -- presumably for concurrent access.

I am not sure why you believe the above. Each Device can have a
different Archive Device path. The examples probably use the same
directory so that it does not get too complicated (with Media Types and
all). I suggest you just try using different disk devices and see what
happens.

Post by Dmitri Maziuk
Same goes for section 3 (Multiple Devices) in
CommunityDiskBackupDesign.pdf
the years have not been kind and my leet reading comprehension skillz
ain't what they used to be.

I think it is just that the examples are simpler than what you want to do.

Post by Dmitri Maziuk
The rest of it is very useful but not germane to the topic of using
multiple hot-swappable disks for storage.

In principle hot-swappable disks should work, but since I don't think
anyone has done it before, there may be hidden problems that I am not
aware of.

Post by Dmitri Maziuk
This is all great but so far the only known config I've actually seen
working is a vchanger. I'd consider buying it off and rolling it into
bacula proper so instead of much handwaving and allegations of "maybe
documented somewhere" features you'd have a definitive and working
answer for retentive assholes like me.

I would say that if you are already using vchanger and it works for you,
you should stick with it. If someone is setting up a new configuration,
the Virtual Autochanger feature may or may not be able to solve their needs.

Best regards,
Kern

Post by Dmitri Maziuk
Dima

------------------------------------------------------------------------------

Dmitri Maziuk

2014-11-09 18:56:25 UTC

Post by Kern Sibbald
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 Types otherwise, Bacula will
not know the right directory to look in for "fixed" disks.

That's the part that doesn't make sense to me: why not? If I have 2
ait-3 tape drives, do I always have to put a tape in the drive that
originally wrote it? If yes, then fine, whatever (and I haven't used
bacula with tapes so I actually don't know), but if not, why do file
volumes have to be different?

Aside from that it looks to me that you can't use different media types
in the same pool, so yes, you can use more than one disk. But you have
to define a separate pool for each and spread your clients over the
pools and guesstimate your backup sizes/client correctly and generally
make the whole thing much more complicated than it needs to be.

Dima

------------------------------------------------------------------------------

Josh Fisher

2014-11-11 16:22:28 UTC

Post by Kern Sibbald

Post by Kern Sibbald
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
community version (slightly different from the Enterprise version).
I notice now, thanks.
CommunityDiskBackup.pdf has the same old problem in 2.1 Grouping
Storage Devices: as usual, it talks multiple devices and shows 2
Device definitions with Archive Device = /disk in both. Personally I
don't know how to mount multiple physical devices in the same /disk at
the same time and keep them separate too.

Post by Kern Sibbald
Same goes for 2.2 Virtual Autochanger: it doesn't let you write to
multiple (disk) devices, it lets bacula treat a single Archive Device
as "multipe devices" -- presumably for concurrent access.

I do not see how that is possible. It makes sense that each of the
virtual autochanger's Devices use a different Media Type, since that
forces volumes to only be "loadable" on the Device in which they exist.
What makes no sense to me is how that is defined in the Director config.
The Media Type directive in the Storage resource in bacula-dir.conf is
required, and as far as I can tell is limited to a single Media Type. If
a single Storage resource in the Director cannot utilize multiple Media
Types, then I do not see how a SD virtual autochanger using Devices with
different Media Types is addressable as a single Storage resource in Dir.

In my testing, I used the below config. Note that I specified a
comma-delimited list of the media types in the Media Type directive of
the Storage resource in bacula-dir.conf (Media Type = disk0,disk1). Dir
and SD start and run normally, accepting the syntax. Jobs run without
errors, but only ever utilize the Device with Media Type = disk0, first
media type listed. If I attempt to run two concurrent jobs, then they
run sequentially, with one waiting on storage until the other completes.
No job can use any volume that is not Media Type "disk0". If I switch
the order of the media types listed in the Media Type directive to Media
Type = disk1,disk0, then all jobs will write to the Device with Media
Type "disk1" and never any volumes with media type disk0.

This leads me to believe that while the SD has no problem with a virtual
autochanger that has Devices with different Media Types, it isn't
possible to define a single Storage resource in Dir that can utilize it.

# bacula-sd.conf
Autochanger {
Name = changer1
Changer Device = /dev/null
Changer Command = /dev/null
Device = changer1-0,changer1-1
}
Device {
Name = changer1-0
Drive Index = 0
Autochanger = yes
Archive Device = /mnt/disk0
Media Type = disk0
Automatic Mount = yes
Always Open = yes
Label Media = yes
}
Device {
Name = changer1-1
Drive Index = 1
Autochanger = yes
Archive Device = /mnt/disk1
Media Type = disk1
Automatic Mount = yes
Always Open = yes
Label Media = yes
}
# eof

# bacula-dir.conf
...
Storage {
Name = changer
Address = 192.168.2.9
SDPort = 9103
Password = "whatever"
Device = changer1
Media Type = disk0,disk1
Autochanger = yes;
Maximum Concurrent Jobs = 20
}
...
#eof

Josh Fisher

2014-11-12 19:11:36 UTC

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 that may be
attached all at the same time". For disk storage, including virtual disk
autochanger, the "device" is a directory, and in almost all cases it is
in fact the mount point of a filesystem partition. The virtual
autochanger described in 2.2 will work with any filesystem mounted at
/disk, so multiple disk drive partitions CAN be used, but ONLY one at a
time. This then works similarly to tape. When the disk drive partition
gets full, you must unmount the current disk partition and mount the
next one. Note that the "device" is really a filesystem. The filesystem
itself could be spread across multiple physical disk drives, but that is
another story.

Post by Dmitri Maziuk
Same goes for section 3 (Multiple Devices) in CommunityDiskBackupDesign.pdf
the years have not been kind and my leet reading comprehension skillz
ain't what they used to be.
The rest of it is very useful but not germane to the topic of using
multiple hot-swappable disks for storage.

There are really (at least) two separate issues going on here. One is
utilizing multiple filesystems simultaneously. Another is using
hot-swappable disk drives. I'll start with using hot-swappable drives.

Bacula has thus far not given a great deal of consideration to
hot-swappable disk drives. Nevertheless, the hooks are there for
mounting and unmounting as needed via the Requires Mount, Mount Command,
and associated directives in the Device resource config. There are
caveats, the most obvious being that the SD must either run as root or
else have sudo configured to allow the SD user to mount the
hot-swappable drives. The not so obvious caveat is that in order to use
hot-swappable drives with a disk Device you MUST use Requires Mount,
particularly if you are using automatic volume labeling. Otherwise, if
no filesystem is mounted at the Archive Device path, then Bacula will
create a volume file on the root filesystem. With Requires Mount = yes,
Bacula will block waiting for a mount request if no filesystem is
mounted at the Mount Point path. Yes, you could mount the hot-swappable
disks using udev and then run SD as a normal user, but if you do so,
then Bacula will write to the root filesystem when no hot-swappable
drive is currently mounted.

The other issue, using multiple simultaneously mounted filesystems, is
not so clear. Each Device resource associated with an autochanger can
specify a different Archive Device path. To do so, it is also necessary
to use a different Media Type for each filesystem. Bacula expects to be
able to load any volume of a particular Media Type into any Device
having that same Media Type. A volume file located in one Device's
Archive Device directory cannot be "loaded" into another Device with a
different Archive Device directory, and so each filesystem must have its
own Media Type. In my testing, the SD seems to support this well. What
is not so clear to me is how to then define the associated Storage
resource in the Director. As far as I can tell, a Storage resource can
only use one Media Type, so a SD Autochanger resource using multiple
Media Types does not seem to be usable as a single Storage resource in Dir.

As the author of vchanger, I can tell you a little about it. First, it
was developed to use multiple USB drives as a virtual autochanger at the
time of Bacula version 1.39.x in 2006. It is open source (GPL v2) and
available on SourceForge, so no "buying it off" is needed.

At the time vchanger was developed Bacula did not have the virtual
autochanger code. My suggestion is to use the native virtual autochanger
if you are backing up to fixed disk or else one removable disk at a
time. Otherwise, use vchanger for multiple simultaneously attached
removable disks. There will never be automatic volume labeling in the
sense of using Label Media=yes, but there is automatic barcode generation.

It just so happens that I have recently had some time to update
vchanger. I will hopefully be pushing it to SourceForge in the next week
or so as version 1.0.0. It has been working without issues for me for a
few weeks with USB drives, but the documentation updates are not yet
complete. The new version eliminates the artificial limitations on the
number of virtual drives and number of slots on a USB drive. The
"magazine" filesystem now contain nothing but volume files and all state
info and symlinks are kept in a per-autochanger subdirectory of
/var/spool/vchanger. It also adds udev support and integration with
Bacula via bconsole commands to automate the Update Slots and Label
Barcodes commands, making swapping USB drives a true plug-n-play
operation. My reasons for updating after all this time are I guess
somewhat selfish. It worked for me, but now I have a need for more
functionality for use with RDX drives.

Post by Dmitri Maziuk
Dima
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

Dimitri Maziuk

2014-11-12 20:10:04 UTC

Post by Josh Fisher
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 that may be
attached all at the same time". For disk storage, including virtual disk
autochanger, the "device" is a directory, and in almost all cases it is
in fact the mount point of a filesystem partition. The virtual
autochanger described in 2.2 will work with any filesystem mounted at
/disk, so multiple disk drive partitions CAN be used, but ONLY one at a
time. This then works similarly to tape.

If this were true you couldn't use more than one tape drive of the same
kind, e.g. the jukeboxes with 2 and more drives would only use one.
Perhaps that is the case and nobody knows about it because people who
can shell out $15K+ on a tape library don't use bacula.

... When the disk drive partition

Post by Josh Fisher
gets full, you must unmount the current disk partition and mount the
next one

... The not so obvious caveat is that in order to use

Post by Josh Fisher
hot-swappable drives with a disk Device you MUST use Requires Mount,
particularly if you are using automatic volume labeling.

Hmm. So I could in theory come up with Mount Command that mounts each
disk in a list (and optionally checks for free space and mounts the next
one if there isn't any) and it all will "Just Work(tm)". Maybe someday
I'll have copious free time and a fresh supply of round tuits...

...

Post by Josh Fisher
The other issue, using multiple simultaneously mounted filesystems, is
not so clear. Each Device resource associated with an autochanger can
specify a different Archive Device path. To do so, it is also necessary
to use a different Media Type for each filesystem. Bacula expects to be
able to load any volume of a particular Media Type into any Device
having that same Media Type. A volume file located in one Device's
Archive Device directory cannot be "loaded" into another Device with a
different Archive Device directory

Again, if as Kern says it's all implemented the same way, then you also
should not be able to load an LTO-6 tape in "just any" LTO-6 drive.
You'd have to give them media types (e.g.) lto-6-mt0 and lto-6-mt1 and
the tapes would only be loadable into /dev/mt0 and /dev/mt1 resp.

If that isn't the case then there are significant differences in how
tape and disk backups are coded in bacula. Then the "works similarly to
tape" assumption is incorrect.

[vchanger]
... It is open source (GPL v2) and

Post by Josh Fisher
available on SourceForge, so no "buying it off" is needed.

Figure of speech. Though I've no idea what legaleze comes with bacula
enterprise and how it might play with your gpl'ed code. (Bareos folks
might know more about that.)

Post by Josh Fisher
It just so happens that I have recently had some time to update
vchanger.

Cool. Please post a message to the list when it's out.
Thanks

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

Josh Fisher

2014-11-12 21:12:50 UTC

Post by Dimitri Maziuk

Again, if as Kern says it's all implemented the same way, then you also
should not be able to load an LTO-6 tape in "just any" LTO-6 drive.
You'd have to give them media types (e.g.) lto-6-mt0 and lto-6-mt1 and
the tapes would only be loadable into /dev/mt0 and /dev/mt1 resp.
If that isn't the case then there are significant differences in how
tape and disk backups are coded in bacula. Then the "works similarly to
tape" assumption is incorrect.

No. When all the drives can read/write the same media, then all of the
Device resources for those tape drives have the same Media Type and it
is the same as when all of the virtual autochanger's Devices have the
same Media Type (and so also the same path in the Archive Device).
Having virtual autochanger Devices with different Archive Device paths
(and so also different Media Types) is like having a jukebox with one
LTO-2 drive and one LTO-6 drive. You see? You would have to use
different Media Types to keep from loading LTO-6 tapes into the LTO-2
drive. It probably hasn't come up, since how many jukeboxes have
completely different types of tape drives in them? I don't know. But if
they do, then it seems to me that they too must be addressed, by the
Director, as two separate Storage resources.

Kern Sibbald

2014-11-14 21:40:43 UTC

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk

Dimitri Maziuk

2014-11-14 22:34:08 UTC

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 never opened
by Bacula (except for more exotic reasons on Windows).

Or it's an Archive Device in a Device in a virtual autochager?

Loading tapes (mounting) is something that only occurs on tape drives, so that
code is distinct from the code that "loads" (opens) a volume. Not all the code
for reading/writing tapes is identical to that for disks, but probably 90-95%
is. That said, there is no harm in you thinking that tapes and disks are
treated very different in Bacula.

Because evidently they are: a tape Device is "like a file within a
directory" whereas a disk Archive Device is a directory that has volume
files within it. ("That is never opened except on exotic Windows.")

I'm not confused when I say bacula treats them very differently. The
difference may well be "just 5-10%" but they seem to be the 5-10% that
really matter when it comes to using hot-swappable hard drives. Which
about every motherboard made in this decade can support at least 4 of on
built-in sata ports and I forget what the limit on usb devices is. I'm
also not confused when I say that bacula's implementation of disk backup
is not usable with multiple removable disk drives.

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

Josh Fisher

2014-10-28 15:48:19 UTC

Post by Ana EmÃlia M. Arruda
, 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.

Granted. But that sort of hardware failure must be handled at the device
driver level. Bacula cannot be blamed for the device driver not raising
an error, and the same behavior would be observed regardless of user
mode software used.

Post by Alan Brown
The only way out of either situation at the moment involves restarting
the storage daemon, which kills ALL jobs running on ALL drives.

Have you tried the umount command in bconsole? umount will close the
device and allow using mt or whatever tools to fix the problem. A
subsequent mount command will re-open the device. If a new or different
tape has been inserted, then the mount command will cause the volume
label to be read. The current job will likely have to be canceled,
unfortunately. Nevertheless, it is often possible to fix a drive issue
without restarting bacula-sd. Ideally, there would be some way to
declare all data written to the failing tape invalid and cause Bacula to
restart the job from the point where data was first written to the
failed tape, though I don't know if that is currently possible. And what
about other jobs that have already successfully written to the now
failed tape?

Post by Alan Brown
Comment: Please don't presume to lecture me about what I should or
should not be doing in my enterprise environment, or indeed about the
way systems are setup (it's all fabric path for starters and bacula does
not do d2d unless you count disk spooling - which we use intensively),
you have no idea of the operational constraints on my site and you're
making a bunch of fairly arrogant assumptions about the way things are
run which impinge on the way you think Bacula should operate.
It's this kind of attitude which results in inflexible software that
gets sworn at, rather than sworn by.
Thankfully Kern and his team are well aware that needs vary depending on
setups and that multiple-tape drive setups need improvement.

Absolutely. It is still evolving.

I don't entirely agree. For the most part, Bacula sticks to the Unix
principle of "everything is a file". Standard C library file i/o is
used. Once the file is opened, whether device file or filesystem file,
it is treated in exactly the same way by Bacula. Any difference is due
to the device and/or filesystem drivers and is beyond Bacula's control,
as it should be. If there are problems with the device driver and/or
device firmware not detecting error conditions, then a bug report is in
order.

That said, there is room for improvement in how media errors, once
detected, are handled. It would be nice to be able to restart jobs from
the point at which data was first written to a particular tape, since by
Murphy's Law, the failing tape tends to be the last tape needed.

------------------------------------------------------------------------------

Ana Emília M. Arruda

2014-10-28 16:50:17 UTC

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 the current version of the software. Also, like all the others,
give feedback about things . It is my believe this is the great objective
of this list.

Post by Ana EmÃlia M. Arruda
, 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.

âYes, IÂŽm aware that this does not work. It was a suggestion for adding in
new versions because IÂŽwas not understanding the whole thing.â

Post by Ana EmÃlia M. Arruda
Thankfully Kern and his team are well aware that needs vary depending on
setups and that multiple-tape drive setups need improvement.

âYes, Kern and his team are always â
â
âaware of all the suggestions and demands discussed here.â

Best regards,
Ana

Kern Sibbald

2014-11-06 17:48:29 UTC

In spite of this, If you have to work with tape drives (stand alone or
tape library ones connected directly - not in a fabric topology)

They are fabric connected.

, 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.

I am surprised that you say that Bacula does not do d2d. With Copy and
Migration jobs that is exactly what it does.

What it does not do is Hierarchical backups as well as it should since
it does not have the concept of cost or speed.

Post by Alan Brown
- which we use intensively),
you have no idea of the operational constraints on my site and you're
making a bunch of fairly arrogant assumptions about the way things are
run which impinge on the way you think Bacula should operate.
It's this kind of attitude which results in inflexible software that
gets sworn at, rather than sworn by.
Thankfully Kern and his team are well aware that needs vary depending on
setups and that multiple-tape drive setups need improvement.

Yes.

Virtual autochangers were not written for removable disks. Prior to
virtual autochangers, I wrote code that allows (at least for me) Bacula
to deal with removable disks such as USB sticks. Virtual autochangers
were written to allow much more flexibility with disks -- i.e. multiple
drives on one Storage, multiple directories, ... For the most part
virtual autochangers with fixed disks functions virtually identically to
tape drives similarly configured.

I am not sure why you consider virtual autochangers a kludge, since it
does *exactly* what I intended it to do for fixed disks. I have never
tried using *removable* disks with virtual autochangers, nor even
thought about it, so perhaps you are trying to make it do something it
was not designed for. In fact, there is a chance that removable disks
will work well with virtual autochangers, *provided* you tell Bacula it
is working with a removable device so it can use the removable disk code.

Best regards,
Kern

------------------------------------------------------------------------------

Kern Sibbald

2014-10-25 14:04:56 UTC

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 approach would be to use drives, each with
a different directory, but Bacula doesn' t handle that as well as pools
with names that are specific to a pool.

Post by Alan Brown
(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.
Bryn
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

------------------------------------------------------------------------------

Kern Sibbald

2014-10-25 13:52:33 UTC

Very well said, thanks.

Kern

Sense to humans yes, sense to program code not so much.
The nature of the SD is that its configuration should almost never
change - all it has for config is an inventory of hardware devices.
There's a certain elegance in simplicity that would be lost trying to
cover what should be a fairly narrow use case.
Imagine all the debugging you have to do - is this job failing because
it is trying to use the config as it appears in the config file, or
some other config in memory from some time in the past? What happens
if we now have different device names referring to the same physical
device, we now need a whole locking mechanism that can cover the use
case of multiple versions of the SD config accessing the same physical
device, possibly with different parameters and names. How would you
be able to tell which version of the config a given job is using?
Remember it is easy to start a backup job that can last a couple of
days - a full backup of a huge fileserver for instance.
Things would get really messy really fast, with practically no
benefit. Your SD config likely changes what, once or twice per year?
If that? It is much safer to just restart the SD when you have an
idle period between backups.
Bryn
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

Kern Sibbald

2014-10-25 13:50:52 UTC

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 locked when writing.

Anyway, this is something I would like to see, but someone needs to
program it ...

Kern