[Bacula-users] configuration question: IPs and hostnames
Hi, I got a bacula setup running for several years now, sadly I hit a snag and was hoping someone here can help me. The setup is as follows: * bacula-director and bacula-sd running on one box (v. 5.2.6, Debian wheezy) * several bacula-sd (v. 5.2.6, Debian wheezy) * one bacula-sd (v. 5.2.6, Debian jessie) (- this is the box i'm currently making my changes to) I doubt the versions do matter but for the sake of completion .. :-) Now I'm in the middle of the painfull process of migration to different IPs (from 192.168.0.0/24 to 10.0.0.0/8) and got a LAN and DMZ area too as to make things anything but simple. I'm trying to use hostnames everywhere now so I changed the Storage definition for bacula-director to a FQN (host.domain.com) that is resolvably at least for my servers. Now the bacula-director got two IPs .. one in the old segment, one in the new. The main bunch of the bacula-sd still got old IPs and connect to the director/storage on the old IP. For one bacula-sd I tried switching over to the new IP (only, no dual IP there) but then bacula won't work anymore. According to the error message it tried sending the backup to the bacula-fd on the OLD IP, even though on the box the hostname resolves correctly to the new IP it SHOULD use. I got the sneaking suspicion the hostname on the configuration gets resolved on the director, not the sd and is wrong. Is there any way around that? For the migration I need to be able to switch one box after the other to the new IPs, there are a buckload of internal services on there that i can't possibly all reconfigure at once ... Any help would be appreciated. Florian -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Back error only in one machine
Hi, I do not really understand why this back is failing (this is the only back that never works), I have other machines in the same configuration (bacula is in internal network and it makes the back through a firewall port forwarding) and so many other on the same internal network. ii bacula 5.2.6+dfsg-5ubuntu1all network backup service - metapackage ii bacula-client 5.2.6+dfsg-5ubuntu1all network backup service - client metapackage ii bacula-common 5.2.6+dfsg-5ubuntu1amd64network backup service - common support files ii bacula-common-mysql 5.2.6+dfsg-5ubuntu1amd64network backup service - MySQL common files ii bacula-console 5.2.6+dfsg-5ubuntu1amd64network backup service - text console ii bacula-director-common 5.2.6+dfsg-5ubuntu1amd64network backup service - Director common files ii bacula-director-mysql 5.2.6+dfsg-5ubuntu1amd64network backup service - MySQL storage for Director ii bacula-fd 5.2.6+dfsg-5ubuntu1amd64network backup service - file daemon ii bacula-sd 5.2.6+dfsg-5ubuntu1amd64network backup service - storage daemon ii bacula-sd-mysql 5.2.6+dfsg-5ubuntu1amd64network backup service - MySQL SD tools ii bacula-server 5.2.6+dfsg-5ubuntu1all network backup service - server metapackage ii bacula-traymonitor 5.2.6+dfsg-5ubuntu1amd64network backup service - tray monitor The bacula back process start well, and asking the clients status everything seems to be OK: *status client=ibergrid-voms-fd Connecting to Client ibergrid-voms-fd at ibergrid-voms.ifca.es:9102 ibergrid-voms-fd Version: 5.0.0 (26 January 2010) x86_64-redhat-linux-gnu redhat (Carbon) Daemon started 10-Jul-15 13:32, 9 Jobs run since started. Heap: heap=135,168 smbytes=91,924 max_bytes=794,880 bufs=97 max_bufs=502 Sizeof: boffset_t=8 size_t=8 debug=0 trace=0 Running Jobs: Director connected at: 13-Jul-15 10:32 No Jobs running. Terminated Jobs: JobId LevelFiles Bytes Status FinishedName == 16498 Full137,0461.624 G OK 10-Jul-15 05:48 BackIbergrid-voms 16516 Full137,0451.231 G OK 10-Jul-15 13:42 BackIbergrid-voms 16516 Full137,0451.231 G OK 10-Jul-15 16:43 BackIbergrid-voms 16524 Full137,0451.231 G OK 10-Jul-15 19:06 BackIbergrid-voms 16524 Full137,0451.231 G OK 10-Jul-15 22:06 BackIbergrid-voms 16546 Full137,0561.231 G OK 11-Jul-15 18:30 BackIbergrid-voms 16546 Full137,0561.231 G OK 11-Jul-15 21:32 BackIbergrid-voms 16566 Full137,0671.231 G OK 12-Jul-15 16:37 BackIbergrid-voms 16566 Full137,0671.225 G OK 12-Jul-15 19:38 BackIbergrid-voms 16580 Full137,0781.226 G OK 13-Jul-15 10:11 BackIbergrid-voms I do spooldata = yes *13-Jul 10:11 bacula-sd JobId 16580: Job write elapsed time = 00:10:41, Transfer rate = 1.942 M Bytes/second13-Jul 10:11 bacula-sd JobId 16580: Committing spooled data to Volume L30006L3. Despooling 1,249,398,751 bytes ...13-Jul 10:12 bacula-sd JobId 16580: Despooling elapsed time = 00:00:30, Transfer rate = 41.64 M Bytes/second13-Jul 10:12 bacula-sd JobId 16580: Sending spooled attrs to the Director. Despooling 31,611,415 bytes ...* While the client say that the job has ended correctly the diector see this still running: *Running Jobs:Console connected at 13-Jul-15 10:18 JobId Level Name Status== 16580 FullBackIbergrid-voms.2015-07-13_10.01.02_03 is running* *The storage deamon sees the jobs end ok:*status storage=TSM3500-LTO3 Connecting to Storage daemon TSM3500-LTO3 at bacula.ifca.es:9103 http://bacula.ifca.es:9103bacula-sd Version: 5.2.6 (21 February 2012) x86_64-pc-linux-gnu ubuntu 12.10Daemon started 07-May-15 13:54. Jobs: run=1611, running=0. Heap: heap=270,336 smbytes=1,093,786 max_bytes=2,185,198 bufs=144 max_bufs=191 Sizes: boffset_t=8 size_t=8 int32_t=4 int64_t=8 mode=0,0Running Jobs:No Jobs running.* *Jobs waiting to reserve a drive:Terminated Jobs: JobId Level Files Bytes Status FinishedName ===... 16580 Full137,0781.245 G OK 13-Jul-15 10:12 BackIbergrid-vomsDevice status:Autochanger TSM3500 with devices: ULT3580-TD3 (/dev/nst1) ULT3580-TD5 (/dev/nst0)Device FileStorage (/data/Bacula/Default) is not open.Device ULT3580-TD3 (/dev/nst1) is mounted with:Volume: L30006L3Pool:FullMedia type: LTO-3Slot 7 is loaded in drive 1.
[Bacula-users] Replacement server fails with some clients
Hi all, I'm replacing a old (Fedora 14) server with a Centos 7 one. I've copied the /etc/bacula/bacula-[sf]d.conf files and everything looks fine. Both the client and storage services are running and talk to the director without problems. However, some of the clients fail to connect with the storage server when running a backup job. The error message I get is related to authentication. However, the clients have not been changed, and the server talks to the director. I'm initial guess was that this is probably a version problem as the old F14 server was running 5.0.3 RPMs and the C7 server is running 5.2.13 My director is also 5.2.13. My director server is also my main storage server, which kind of cancels that idea, as most clients back up to this server. Most of my other storage servers are 5.0.3 (one is 5.0.0) The vast majority of my clients are Win7 running bacula-win64 5.2.10 One of the things that's surprised me about looking into this problem is that a recently built and yum -y update Fedora 21 box is running 7.0.5. Not sure why that is. This is one of the clients who are failing with the new storage server. It may be that the other (Win7) clients are also running 5.0.x. Despite my comments above, does this still look like it could be the issue? If so, what's the best / easiest way to upgrade the Fedora 21 to 5.2.x RPMs? The log for one of these jobs is below. 13-Jul 13:49 eddie1-dir JobId 124118: Prior failed job found in catalog. Upgrading to Full. 13-Jul 13:49 eddie1-dir JobId 124118: shell command: run BeforeJob /etc/bacula/jobcheck.sh eddienew-fd 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: PING 10.1.1.226 (10.1.1.226) 56(84) bytes of data. 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: 64 bytes from 10.1.1.226: icmp_seq=1 ttl=64 time=0.109 ms 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: --- 10.1.1.226 ping statistics --- 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: 1 packets transmitted, 1 received, 0% packet loss, time 0ms 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: rtt min/avg/max/mdev = 0.109/0.109/0.109/0.000 ms 13-Jul 13:49 eddie1-dir JobId 124118: Start Backup JobId 124118, Job=eddienew.2015-07-13_13.49.33_58 13-Jul 13:49 eddie1-dir JobId 124118: Using Device ChicoStorage to write. 13-Jul 13:49 eddienew-fd JobId 124118: Fatal error: Authorization key rejected by Storage daemon. Please see http://www.bacula.org/en/rel-manual/Bacula_Freque_Asked_Questi.html#SECTION0026 for help. 13-Jul 13:49 eddie1-dir JobId 124118: Fatal error: Bad response to Storage command: wanted 2000 OK storage , got 2902 Bad storage 13-Jul 13:49 eddie1-dir JobId 124118: Error: Bacula eddie1-dir 5.2.13 (19Jan13): Build OS: x86_64-redhat-linux-gnu redhat Cat) JobId: 124118 Job:eddienew.2015-07-13_13.49.33_58 Backup Level: Full (upgraded from Incremental) Client: eddienew-fd 7.0.5 (28Jul14) x86_64-redhat-linux-gnu,redhat,One) FileSet:Linux Full 2012-08-13 19:05:00 Pool: chico (From Job resource) Catalog:MyCatalog (From Client resource) Storage:chico-chico (From Job resource) Scheduled time: 13-Jul-2015 13:49:33 Start time: 13-Jul-2015 13:49:38 End time: 13-Jul-2015 13:49:50 Elapsed time: 12 secs Priority: 7 FD Files Written: 0 SD Files Written: 0 FD Bytes Written: 0 (0 B) SD Bytes Written: 0 (0 B) Rate: 0.0 KB/s Software Compression: None VSS:no Encryption: no Accurate: no Volume name(s): Volume Session Id: 896 Volume Session Time:1436082818 Last Volume Bytes: 208,677,550 (208.6 MB) Non-fatal FD errors:2 SD Errors: 0 FD termination status: Error SD termination status: Waiting on FD Termination:*** Backup Error *** -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Replacement server fails with some clients
Hello Gary, If your director is running 5.2.13, you should have all your storage daemons in this version too. Also If you have a client in the director host, this client should be the same version of director. About your client problems, you should have your client versions at most equal to director version, not greater than. Best regards, Ana On Mon, Jul 13, 2015 at 10:05 AM, Gary Stainburn g...@ringways.co.uk wrote: Hi all, I'm replacing a old (Fedora 14) server with a Centos 7 one. I've copied the /etc/bacula/bacula-[sf]d.conf files and everything looks fine. Both the client and storage services are running and talk to the director without problems. However, some of the clients fail to connect with the storage server when running a backup job. The error message I get is related to authentication. However, the clients have not been changed, and the server talks to the director. I'm initial guess was that this is probably a version problem as the old F14 server was running 5.0.3 RPMs and the C7 server is running 5.2.13 My director is also 5.2.13. My director server is also my main storage server, which kind of cancels that idea, as most clients back up to this server. Most of my other storage servers are 5.0.3 (one is 5.0.0) The vast majority of my clients are Win7 running bacula-win64 5.2.10 One of the things that's surprised me about looking into this problem is that a recently built and yum -y update Fedora 21 box is running 7.0.5. Not sure why that is. This is one of the clients who are failing with the new storage server. It may be that the other (Win7) clients are also running 5.0.x. Despite my comments above, does this still look like it could be the issue? If so, what's the best / easiest way to upgrade the Fedora 21 to 5.2.x RPMs? The log for one of these jobs is below. 13-Jul 13:49 eddie1-dir JobId 124118: Prior failed job found in catalog. Upgrading to Full. 13-Jul 13:49 eddie1-dir JobId 124118: shell command: run BeforeJob /etc/bacula/jobcheck.sh eddienew-fd 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: PING 10.1.1.226 (10.1.1.226) 56(84) bytes of data. 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: 64 bytes from 10.1.1.226: icmp_seq=1 ttl=64 time=0.109 ms 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: --- 10.1.1.226 ping statistics --- 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: 1 packets transmitted, 1 received, 0% packet loss, time 0ms 13-Jul 13:49 eddie1-dir JobId 124118: BeforeJob: rtt min/avg/max/mdev = 0.109/0.109/0.109/0.000 ms 13-Jul 13:49 eddie1-dir JobId 124118: Start Backup JobId 124118, Job=eddienew.2015-07-13_13.49.33_58 13-Jul 13:49 eddie1-dir JobId 124118: Using Device ChicoStorage to write. 13-Jul 13:49 eddienew-fd JobId 124118: Fatal error: Authorization key rejected by Storage daemon. Please see http://www.bacula.org/en/rel-manual/Bacula_Freque_Asked_Questi.html#SECTION0026 for help. 13-Jul 13:49 eddie1-dir JobId 124118: Fatal error: Bad response to Storage command: wanted 2000 OK storage , got 2902 Bad storage 13-Jul 13:49 eddie1-dir JobId 124118: Error: Bacula eddie1-dir 5.2.13 (19Jan13): Build OS: x86_64-redhat-linux-gnu redhat Cat) JobId: 124118 Job:eddienew.2015-07-13_13.49.33_58 Backup Level: Full (upgraded from Incremental) Client: eddienew-fd 7.0.5 (28Jul14) x86_64-redhat-linux-gnu,redhat,One) FileSet:Linux Full 2012-08-13 19:05:00 Pool: chico (From Job resource) Catalog:MyCatalog (From Client resource) Storage:chico-chico (From Job resource) Scheduled time: 13-Jul-2015 13:49:33 Start time: 13-Jul-2015 13:49:38 End time: 13-Jul-2015 13:49:50 Elapsed time: 12 secs Priority: 7 FD Files Written: 0 SD Files Written: 0 FD Bytes Written: 0 (0 B) SD Bytes Written: 0 (0 B) Rate: 0.0 KB/s Software Compression: None VSS:no Encryption: no Accurate: no Volume name(s): Volume Session Id: 896 Volume Session Time:1436082818 Last Volume Bytes: 208,677,550 (208.6 MB) Non-fatal FD errors:2 SD Errors: 0 FD termination status: Error SD termination status: Waiting on FD Termination:*** Backup Error *** -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___
Re: [Bacula-users] configuration question: IPs and hostnames
On 7/13/2015 8:29 AM, Florian Schnabel wrote: I'm trying to use hostnames everywhere now so I changed the Storage definition for bacula-director to a FQN (host.domain.com) that is resolvably at least for my servers. Now the bacula-director got two IPs .. one in the old segment, one in the new. The main bunch of the bacula-sd still got old IPs and connect to the director/storage on the old IP. For one bacula-sd I tried switching over to the new IP (only, no dual IP there) but then bacula won't work anymore. According to the error message it tried sending the backup to the bacula-fd on the OLD IP, even though on the box the hostname resolves correctly to the new IP it SHOULD use. Don't switch to using hostnames until after the switch. Even if the clients are using IPs, the Dir will tell the client to connect to the SD at some.host.name and the client will/may get the wrong IP for the SD. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Back error only in one machine
*messages 13-Jul 12:01 bacula-dir JobId 16580: Fatal error: Network error with FD during Backup: ERR=Connection reset by peer 13-Jul 12:01 bacula-dir JobId 16580: Fatal error: No Job status returned from FD. 13-Jul 12:01 bacula-dir JobId 16580: Error: Bacula bacula-dir 5.2.6 (21Feb12): Build OS: x86_64-pc-linux-gnu ubuntu 12.10 JobId: 16580 Job: BackIbergrid-voms.2015-07-13_10.01.02_03 Backup Level: Full Client: ibergrid-voms-fd 5.0.0 (26Jan10) x86_64-redhat-linux-gnu,redhat,(Carbon) Hello Iban: could you please upgrade your client to a 5.2.x version and try again? Even though Director version may be bigger than clients one it's advisable not to abuse of Bacula daemons compatibility matrix. Regards, === Heitor Medrado de Faria - LPIC-III | ITIL-F | Bacula Systems Certified Administrator II 29 de junho a 13 de julho: Treinamento Telepresencial Bacula: http://www.bacula.com.br/?p=2174 61 8268-4220 Site: www.bacula.com.br | Facebook: heitor.faria -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Replacement server fails with some clients
Hi Ana Thank you for this. However, initialy the opposite seems to have been the case. The storage daemons at 5.0.x were working fine, while the one at 5.2.13 was not. However, changing the client has fixed this specific client. While looking into this, and trying to find out how to install 5.2.x RPM's onto my Fedora 21 file and print server I found references to Bareos. This is something I was totally unaware of. I have followed the instructions to install the bareos repo and have installed the bareos-client. Having turned 'compatibilty = yes' on I can now successfully back up this server. While I'm not sure how I should proceed long term, it does seem to have solved this problem. What I don't understand is why *very* old boxes running Fedora 9 and 2.4.x clients back up and work fine, while newer Fedora 21 / 5.0.x clients fail. Gary On Monday 13 July 2015 15:35:26 Ana Emília M. Arruda wrote: Hello Gary, If your director is running 5.2.13, you should have all your storage daemons in this version too. Also If you have a client in the director host, this client should be the same version of director. About your client problems, you should have your client versions at most equal to director version, not greater than. Best regards, Ana -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
