Bacula-users

Re: [Bacula-users] Bacula 2.4.4 backup error

2009-07-14 06:46:50
Subject: Re: [Bacula-users] Bacula 2.4.4 backup error
From: Bruno Friedmann <bruno AT ioda-net DOT ch>
Date: Tue, 14 Jul 2009 12:41:38 +0200
Thomas Kempf wrote:
> Bruno Friedmann schrieb:
>> Thomas Kempf wrote:
>>> Thomas Kempf schrieb:
>>>> Martin Simmons schrieb:
>>>>>>>>>> On Tue, 07 Jul 2009 08:13:43 +0200, Thomas Kempf said:
>>>>>> hello,
>>>>>> i've got some problems with bacula 2.4.4. on Debian Lenny and postgresql 
>>>>>> 8.3. Basically I'm facing the problem with postgresql discarding the 
>>>>>> complete batch insert after a job because there are some invalid utf8 
>>>>>> byte-sequences in it. There were already some discussions on this 
>>>>>> subject with the proposal to dump the db and to reload it with encoding 
>>>>>> SQL_ASCII which is what i did. This did not solve my problem. The backup 
>>>>>> of some machines still produces this annoying error. Now i have two 
>>>>>> questions.
>>>>>>
>>>>>> 1. Why does bacula send me messages with the backup status of ok for 
>>>>>> those machines instead of telling me at least, that the batch copy 
>>>>>> failed. IMO there should be at least a warning that attribute despooling 
>>>>>> failed.
>>>>> If this happens with the latest version of Bacula, then please make a bug
>>>>> report.
>>> o.k. I installed bacula 3.0.1 and ran a backup job with one of the 
>>> clients where the problem exists. Error still occurs. Here are the logs:
>>>
>>> **************************************************************************
>>> 09-Jul 11:45 baraber-sd: Job write elapsed time = 01:23:56, Transfer 
>>> rate = 22.43 M bytes/second
>>> 09-Jul 11:45 baraber-sd: Sending spooled attrs to the Director. 
>>> Despooling 4,787,248 bytes ...
>>> 09-Jul 11:45 hueper-dir JobId 11420: Bacula hueper-dir 3.0.1 (30Apr09): 
>>> 09-Jul-2009 11:45:57
>>>    Build OS:               powerpc-unknown-linux-gnu debian 5.0.1
>>>    JobId:                  11420
>>>    Job:                    TT-save.2009-07-09_10.19.00_04
>>>    Backup Level:           Full
>>>    Client:                 "baraber-fd" 2.1.26 (12Jul07) 
>>> i686-pc-linux-gnu,suse,9.3
>>>    FileSet:                "tt-save" 2009-07-09 10:19:00
>>>    Pool:                   "TT" (From Job resource)
>>>    Catalog:                "MyCatalog" (From Client resource)
>>>    Storage:                "NEC-LTO2" (From command line)
>>>    Scheduled time:         09-Jul-2009 10:18:52
>>>    Start time:             09-Jul-2009 10:19:03
>>>    End time:               09-Jul-2009 11:45:57
>>>    Elapsed time:           1 hour 26 mins 54 secs
>>>    Priority:               10
>>>    FD Files Written:       12,768
>>>    SD Files Written:       0
>>>    FD Bytes Written:       112,968,866,299 (112.9 GB)
>>>    SD Bytes Written:       0 (0 B)
>>>    Rate:                   21666.4 KB/s
>>>    Software Compression:   None
>>>    VSS:                    no
>>>    Encryption:             no
>>>    Accurate:               no
>>>    Volume name(s):         TT0002L2
>>>    Volume Session Id:      602
>>>    Volume Session Time:    1239870780
>>>    Last Volume Bytes:      119,144,245,248 (119.1 GB)
>>>    Non-fatal FD errors:    0
>>>    SD Errors:              0
>>>    FD termination status:  OK
>>>    SD termination status:  OK
>>>    Termination:            Backup OK
>>>
>>> 09-Jul 11:45 hueper-dir JobId 11420: Begin pruning Jobs.
>>> 09-Jul 11:45 hueper-dir JobId 11420: No Jobs found to prune.
>>> 09-Jul 11:45 hueper-dir JobId 11420: Begin pruning Files.
>>> 09-Jul 11:45 hueper-dir JobId 11420: Pruned Files from 1 Jobs for client 
>>> baraber-fd from catalog.
>>> 09-Jul 11:45 hueper-dir JobId 11420: End auto prune.
>>>
>>> **********************************************************************
>>> After the job, there are no entries in the file table instead this is in 
>>> the log of postgresql:
>>> ***********************************************************************
>>>
>>> 2009-07-09 11:45:53 CEST FEHLER:  ungültige Byte-Sequenz für Kodierung 
>>> »UTF8«: 0xe4727a
>>> 2009-07-09 11:45:53 CEST TIPP:  Dieser Fehler kann auch auftreten, wenn 
>>> die Bytesequenz nicht mit der Kodierung übereinstimmt, die der Server 
>>> erwartet, welche durch »client_encoding« bestimmt wird.
>>> 2009-07-09 11:45:53 CEST ZUSAMMENHANG:  COPY batch, Zeile 6844
>>> 2009-07-09 11:45:53 CEST ANWEISUNG:  COPY batch FROM STDIN
>>> 2009-07-09 11:45:57 CEST FEHLER:  Tabelle »delcandidates« existiert nicht
>>> 2009-07-09 11:45:57 CEST ANWEISUNG:  DROP TABLE DelCandidates
>>>
>>> so i guess i'll make a bug report, because there should be at least a 
>>> warning that something went wrong while spooling attributes.
>>> Tom
>>>
>>>
>>>
>> Hi Thomas, I remember discussion on the ML about trouble with postgresql & 
>> bacula.
>> Bacula mens insist to have SQL_ASCII for postgres & bacula.
>> Your bacula's db is SQL_ASCII, but I suppose as template0 and template1 are 
>> UTF-8 the batch temporary table
>> are created based on one of the two which conduct to the errors you 
>> encounter.
>>
>> I think you have to give this information if you are reporting this bug.
>> (Perharps give a try to the wiki, searching about postgresql & the docs ) 
>> before you transmit a bug.
>>
>> Anyway if bacula need a sql_ascii table, it should be "smart" enough to 
>> create it with this requirement.
>>
> Hi Bruno,
> first of all thank you for your explanation. It seems reasonable for me, 
> that this is the root of the problem with postgresql and bacula. I 've 
> really searched the docs, the mailinglist and the web, but have not 
> found any place where the template DB encoding is mentioned as the 
> problem source. I'll check this though.
As I've not migrated from mysql/sun/oracle to postgresql for bacula,
I've no real sample on hands. This would arrive when 3.0.2 will be released.

> I already transmitted a bug report, because no matter what the reason 
> for this behaviour is, bacula should not tell me the backup is ok when 
> it is not! Anyway, i'll include your information on this subject in the 
> bugreport.
You're welcome, if a soluce exist it should be mentionned on docs & wiki.

> But, this is just a little problem. When i think of all the huge 
> problems i had with commercial backup software in the sad "pre-bacula 
> times" ...
> 
> Tom
Did you also come from the arghserve solution ? :-)

Yesterday I've just save a customer bunch of data using bacula (version 
1.38.11) It's amazing how it work
and how we can be confident in it.

-- 

     Bruno Friedmann



------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users