[Bacula-users] is not a Bacula labeled Volume, because: ERR=block.c:1023 Re
I already did, found nothing useful than you should relabel it, or use /dev/nst0 instead of /dev/st0. I've always used /dev/st0 The correct tape is in the drive, the tape is labeled correct. I can mount all 28 tapes in the library, except that one. The last status of the tape was marked append so, it is not in error or anything. Neither have I archived it or taken it out to archive it. bacula version is v5.0.1 and is installed from ubuntu (10.04) repository +-- |This was sent by c...@belnet.be via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] is not a Bacula labeled Volume, because: ERR=block.c:1023 Re
I already did, found nothing useful than you should relabel it, or use /dev/nst0 instead of /dev/st0. I've always used /dev/st0 The correct tape is in the drive, the tape is labeled correct. I can mount all 28 tapes in the library, and are all recognized. Except for that one. The last status of the tape was marked append so, it is not in error or anything. Neither have I archived it or taken it out to archive it. bacula version is v5.0.1 and is installed from ubuntu (10.04) repository +-- |This was sent by c...@belnet.be via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] is not a Bacula labeled Volume, because: ERR=block.c:1023 Re
I already did, found nothing useful than you should relabel it, or use /dev/nst0 instead of /dev/st0. I've always used /dev/st0 The correct tape is in the drive, the tape is labeled correct. I can mount all 28 tapes in the library, and are all recognized. Except for that one. The last status of the tape was marked append so, it is not in error or anything. Neither have I archived it or taken it out to archive it. bacula version is v5.0.1 and is installed from ubuntu (10.04) repository Regards Che +-- |This was sent by c...@belnet.be via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[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. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] very long Dir inserting Attributes
Hello.I encountered the same problem with a job saving a Windows 2008 server.
So, I have added and activated, in the bacula-dir.conf, the shadow copy option
(VSS) to resolve this problem.
FileSet{ Name = WinJob_xxx Enable VSS = yes #activation of the Volume
Shadow Copy.
Include { Options {
Le Mardi 21 octobre 2014 11h30, Anton Gorlov stal...@altlinux.ru a écrit
:
20.10.2014 20:34, Anton Gorlov пишет:
I change
wall_buffers to -1 (-1 sets based on shared_buffers)
shared_buffers = 1536MB
effective_cache_size = 4608MB
fsync is commented.
bacula == 5.2.6+dfsg-9 (debian stable)
run a full backup's at night...
+ full vacuum of dataase is help.
monitoring the situation as it progresses..
--
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://p.sf.net/sfu/Zoho
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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, 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. 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 Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
+1 Sent while mobile. Am 24.10.2014 um 10:11 schrieb Uwe Schuerkamp uwe.schuerk...@nionex.net: 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, 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. 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 Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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:andrea.carp...@dnshosting.it] Sent: 24 October 2014 9:48 To: bacula-users@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. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [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? 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 -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] is not a Bacula labeled Volume, because: ERR=block.c:1023 Re
From the little I have seen, it looks like your tape was never written (the data may be on another tape -- please check) or the tape was overwritten. Using /dev/st0 could *possibly* cause the tape to be overwritten, but Bacula attempts to avoid that. On 14-10-24 04:10 AM, Che_m wrote: I already did, found nothing useful than you should relabel it, or use /dev/nst0 instead of /dev/st0. I've always used /dev/st0 The correct tape is in the drive, the tape is labeled correct. I can mount all 28 tapes in the library, except that one. The last status of the tape was marked append so, it is not in error or anything. Neither have I archived it or taken it out to archive it. bacula version is v5.0.1 and is installed from ubuntu (10.04) repository +-- |This was sent by c...@belnet.be via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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, 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. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] is not a Bacula labeled Volume, because: ERR=block.c:1023 Re
According to the bacula database, the tape has 500GB of data written on it. I'm trying to check out on the tape itself, but knowledge of the mtx script is limited. However, the difference of nst0 and st0 is, the first one does not autorewind. and as stated by kern, bacula avoids rewinding the tape. so. also, this is tape which I have problems with, is the last one in a pool of 4 for that month specific. during the restore, it selects the 3 other tapes correctly, but it does not complete the restore, because of the 4th tape. +-- |This was sent by c...@belnet.be via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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 -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
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 li...@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 -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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 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 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 Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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 andrea.carp...@dnshosting.it 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 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 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 Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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 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 -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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 RD Systems Support Oak Ridge National Laboratory 865-576-7718 From: Ana Emília M. Arruda emiliaarr...@gmail.commailto:emiliaarr...@gmail.com Date: Friday, October 24, 2014 at 9:20 AM Cc: Bacula-users@lists.sourceforge.netmailto:Bacula-users@lists.sourceforge.net bacula-users@lists.sourceforge.netmailto:bacula-users@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 li...@nashira.camailto:li...@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 -- -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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.bacula.org/whitepapers/CommunityDiskBackup.pdf . Thanks Ana, I'll take a look at this paper. Regards, .a.c. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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 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 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 -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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 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) -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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. Bryn -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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 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) Bryn -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Configuration reload for bacula-sd
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 On Fri, Oct 24, 2014 at 2:57 PM, Alan Brown a...@mssl.ucl.ac.uk wrote: 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 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) Bryn -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Problem installing bacula on Solaris 10
I’m trying to build Bacula 7.0.4 on a Solaris 10 box (Sun T5220) but am getting this error during the configure: Doing make of dependencies ==Entering directory /home/garges/bacula-7.0.4/src ==Entering directory /home/garges/bacula-7.0.4/scripts ==Entering directory /home/garges/bacula-7.0.4/src/lib mksh: Fatal error in reader: = missing from replacement macro reference Current working directory /home/garges/bacula-7.0.4/src/lib *** Error code 1 The following command caused the error: for I in src scripts src/lib src/findlib src/filed src/console src/plugins/fd src/cats src/dird src/stored src/tools manpages; \ do (cd $I; echo ==Entering directory `pwd`; make DESTDIR= depend || exit 1); done make: Fatal error: Command failed for target `depend' chmod: WARNING: can't access storage-ctl chmod: WARNING: can't access bsg_persist Following a suggestion I read on the net I changed line 52 of Makefile.in to force configure to use gmake instead of the Solaris make: -bash-3.2$ more +52 -1 Makefile.in do (cd $$I; echo ==Entering directory `pwd`; /opt/csw/bin/gmake DESTDIR=$(DESTDIR) $@ || exit 1); done That changes the error to: Doing make of dependencies ==Entering directory /home/garges/bacula-7.0.4/src gmake[1]: Entering directory `/home/garges/bacula-7.0.4/src' gmake[1]: Nothing to be done for `depend'. gmake[1]: Leaving directory `/home/garges/bacula-7.0.4/src' ==Entering directory /home/garges/bacula-7.0.4/scripts gmake[1]: Entering directory `/home/garges/bacula-7.0.4/scripts' gmake[1]: `depend' is up to date. gmake[1]: Leaving directory `/home/garges/bacula-7.0.4/scripts' ==Entering directory /home/garges/bacula-7.0.4/src/lib gmake[1]: Entering directory `/home/garges/bacula-7.0.4/src/lib' /bin/sh: # DO NOT DELETE: nice dependency list follows: not found gmake[1]: *** [depend] Error 1 gmake[1]: Leaving directory `/home/garges/bacula-7.0.4/src/lib' *** Error code 1 The following command caused the error: for I in src scripts src/lib src/findlib src/filed src/console src/plugins/fd src/cats src/dird src/stored src/tools manpages; \ do (cd $I; echo ==Entering directory `pwd`; /opt/csw/bin/gmake DESTDIR= depend || exit 1); done make: Fatal error: Command failed for target `depend' chmod: WARNING: can't access storage-ctl chmod: WARNING: can't access bsg_persist Trying to run it manually gives the same error: -bash-3.2$ cd src/lib -bash-3.2$ /opt/csw/bin/gmake DESTDIR= depend /bin/sh: # DO NOT DELETE: nice dependency list follows: not found gmake: *** [depend] Error 1 The error seems to imply the shell is trying to execute the last line of the Makefile.in which is a comment! -bash-3.2$ tail -2 Makefile.in # DO NOT DELETE: nice dependency list follows -bash-3.2$ tail -2 Makefile # --- So I’m stumped. What should I try next? Here’s the whole dialog: PATH=/opt/csw/bin:/usr/bin:/usr/ccs/bin:/etc:/usr/openwin/bin:/usr/local/bin:/usr/ucb:/usr/sbin export PATH LDFLAGS=-L/opt/csw/lib -R/opt/csw/lib -L/opt/csw/lib/openssl -R/opt/csw/lib/openssl -I/opt/csw/include -I/opt/csw/include/openssl export LDFLAGS CFLAGS=-g -I/opt/csw/include -lcrypto -lssl -L/opt/csw/lib -R/opt/csw/lib export CFLAGS ./configure \ --sbindir=/usr/local/bin \ --sysconfdir=/etc/bacula \ --with-postgresql=/opt/csw \ --enable-smartalloc \ --with-pid-dir=/var/bacula/working \ --with-subsys-dir=/var/bacula/subsys \ --with-working-dir=/var/bacula/working \ --with-dir-user=bacula \ --with-dir-group=backup \ --with-sd-user=bacula \ --with-sd-group=backup \ --with-fd-user=root \ --with-fd-group=backup \ --with-dump-email=gar...@ucsc.edu \ --with-job-email=gar...@ucsc.edu \ --with-smtp-host=smtp.ucsc.edu \ --with-openssl=/opt/csw \ --disable-ipv6 --disable-batch-insert checking for true... /usr/bin/true checking for false... /usr/bin/false configuring for Bacula 7.0.4 (04 June 2014) checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/xpg4/bin/grep checking for egrep... /usr/xpg4/bin/grep -E checking whether gcc needs -traditional... no checking for g++... /usr/local/bin/g++ checking for a BSD-compatible install... /opt/csw/bin/ginstall -c checking for mv... /usr/bin/mv checking for rm... /usr/bin/rm checking for cp... /usr/bin/cp checking for sed... /usr/bin/sed checking for
