bacula : fd errors , connection reset by peer

[Boudewijn]

Hoihoi

Ik heb een bacula server (director en storage daemon) thuis staan en wat file daemons op mijn VPS omgeving.
Punt is dat ik een van die clients met de grootste moeite aan de gang krijg:

code:

17-Jul 02:52 leiden-dir JobId 94: Fatal error: Network error with FD during Backup: ERR=Connection reset by peer
17-Jul 02:52 leiden-dir JobId 94: Fatal error: No Job status returned from FD.
17-Jul 02:52 leiden-dir JobId 94: Error: Bacula leiden-dir 5.0.3 (04Aug10): 17-Jul-2011 02:52:30
  Build OS:               i486-pc-linux-gnu debian wheezy/sid
  JobId:                  94
  Job:                    BLAjob.2011-07-17_00.52.14_10
  Backup Level:           Full (upgraded from Incremental)
  Client:                 "client4" 5.0.2 (28Apr10) x86_64-pc-linux-gnu,debian,squeeze/sid
  FileSet:                "BLA Set" 2011-07-16 23:49:43
  Pool:                   "LeidenPool" (From Job resource)
  Catalog:                "MyCatalog" (From Client resource)
  Storage:                "leiden-filestorage" (From Job resource)
  Scheduled time:         17-Jul-2011 00:52:13
  Start time:             17-Jul-2011 00:52:16
  End time:               17-Jul-2011 02:52:30
  Elapsed time:           2 hours 14 secs
  Priority:               10
  FD Files Written:       0
  SD Files Written:       137,033
  FD Bytes Written:       0 (0 B)
  SD Bytes Written:       3,586,674,915 (3.586 GB)
  Rate:                   0.0 KB/s
  Software Compression:   None
  VSS:                    no
  Encryption:             no
  Accurate:               no
  Volume name(s):         LeidenVol0005
  Volume Session Id:      20
  Volume Session Time:    1310599400
  Last Volume Bytes:      12,025,925,394 (12.02 GB)
  Non-fatal FD errors:    0
  SD Errors:              0
  FD termination status:  Error
  SD termination status:  OK
  Termination:            *** Backup Error ***

Wat me opvalt is dat als ik die job met de hand nogmaals start, ik dezelfde error krijg... op bijna hetzelfde moment:

code:

  SD Files Written:       137,051
  FD Bytes Written:       0 (0 B)
  SD Bytes Written:       3,589,051,512 (3.589 GB)

Hmmmzzz.Dat lijkt me een structureel probleem.

Mijn configs:

code:

Client {
  Name = bla
  Address = bla.nl
  FDPort = 9102
  Catalog = MyCatalog
  Password = "knip"          # password for FileDaemon
  File Retention = 30 days            # 30 days
  Job Retention = 6 months            # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
  Heartbeat Interval = 60
}

Die Heartbeat Interval heb ik geadd om dit probleem te fixen maar dat is het dus niet. Sommige andere clients backuppen trouwens prima naar de bacula d irector.

Alle OSen zijn 64b debian squeeze.
Weet iemand waar ik nog meer naar kan gaan kijken?

[kluyze]

Some day soon I'm going to find this peer guy and reset HIS connection!

Heb je al eens getest om een connection buiten bacula om open te houden, een ssh connection (zonder traffiek) of een connectie waar wel trafiek op zit.

Wat voor hardware zit er nog tussen? Router/switch/...

Ik zou in elk geval eerst eens naar de connectie zelf kijken.

[ Voor 4% gewijzigd door kluyze op 17-07-2011 22:24 ]

[Boudewijn]

Nou het punt is dat op diezelfde Xen server meer guest OSen draaien die backuppen naar dezelfde bacula server , met dezelfde software. Ik geloof dus bijna niet dat dat het probleem is.
Of ze ook zoveel backuppen weet ik niet.

Qua router thuis: Juniper netscreen 5gt. Colocated: dunno.

[kluyze]

Boudewijn schreef op zondag 17 juli 2011 @ 22:32:
Nou het punt is dat op diezelfde Xen server meer guest OSen draaien die backuppen naar dezelfde bacula server , met dezelfde software. Ik geloof dus bijna niet dat dat het probleem is.
Of ze ook zoveel backuppen weet ik niet.

het kan natuurlijk dat bv de router na ~2u intensief gebruik er genoeg van heeft.

Gaat bacula trouwens eerst de files comprimeren tot 1 bestand of gaat de backup als veel kleine bestanden over het netwerk? Het is al weer een tijd geleden dat ik nog met bacula gewerkt heb.

Er is trouwens in de manual een stukje over errors ivm fd naar sd. Maar dat gaat blijkbaar enkel over bepaalde domainnamen en problemen ivm het poortnummer

[Boudewijn]

kluyze schreef op zondag 17 juli 2011 @ 23:32:
[...]
het kan natuurlijk dat bv de router na ~2u intensief gebruik er genoeg van heeft.

Die router zou dat prima aan moeten kunnen.

Gaat bacula trouwens eerst de files comprimeren tot 1 bestand of gaat de backup als veel kleine bestanden over het netwerk? Het is al weer een tijd geleden dat ik nog met bacula gewerkt heb.

Dat ga ik even uitzoeken.

Er is trouwens in de manual een stukje over errors ivm fd naar sd. Maar dat gaat blijkbaar enkel over bepaalde domainnamen en problemen ivm het poortnummer

Ik zal het eens lezen, vond zo snel niet iets specifieks rond dit verhaal.

[Boudewijn]

Shit zeg, er faalt zojuist nog een VM:

code:

  Elapsed time:           2 hours 23 secs
  Priority:               10
  FD Files Written:       0
  SD Files Written:       90,949
  FD Bytes Written:       0 (0 B)
  SD Bytes Written:       7,339,661,658 (7.339 GB)
  Rate:                   0.0 KB/s

Grmbl.

[kluyze]

Op een paar seconden na, even lang.

Als je het zelf nog niet gevonden had, dit stukje bedoelde ik in de manual. Maar ik denk eerlijk niet dat dat het is.

Difficulties Connecting from the FD to the SD

If you are having difficulties getting one or more of your File daemons to connect to the Storage daemon, it is most likely because you have not used a fully qualified domain name on the Address directive in the Director's Storage resource. That is the resolver on the File daemon's machine (not on the Director's) must be able to resolve the name you supply into an IP address. An example of an address that is guaranteed not to work: localhost. An example that may work: megalon. An example that is more likely to work: magalon.mydomain.com. On Win32 if you don't have a good resolver (often true on older Win98 systems), you might try using an IP address in place of a name.

If your address is correct, then make sure that no other program is using the port 9103 on the Storage daemon's machine. The Bacula port numbers are authorized by IANA, and should not be used by other programs, but apparently some HP printers do use these port numbers. A netstat -a on the Storage daemon's machine can determine who is using the 9103 port (used for FD to SD communications in Bacula).

Er bestaat tegenwoordig blijkbaar een max-run instelling in bacula, staat die toevallig niet op 2u?
www.bacula.org/5.0.x-manuals/en/main/main/New_Features_in_3_0_0.html
Kan in de bconsole die waarde niet getoond worden?

[Boudewijn]

Goed, dat is inderdada heel raar. We gaan eens proberen die 2 uur te doorbreken.
Localhost niet gebruiken was me al duidelijk adhv de config. .

[Boudewijn]

En ook dat werkt helaas niet:

code:

18-Jul 21:37 leiden-dir JobId 105: No prior Full backup Job record found.
18-Jul 21:37 leiden-dir JobId 105: No prior or suitable Full backup found in catalog. Doing FULL backup.
18-Jul 21:37 leiden-dir JobId 105: Start Backup JobId 105, Job=blajob.2011-07-18_21.37.00_03
18-Jul 21:37 leiden-dir JobId 105: Using Device "leiden-filestorage"
18-Jul 23:37 leiden-dir JobId 105: Fatal error: Network error with FD during Backup: ERR=Connection reset by peer
18-Jul 23:37 leiden-filestorage JobId 105: JobId=105 Job="blajob.2011-07-18_21.37.00_03" marked to be canceled.
18-Jul 23:37 leiden-dir JobId 105: Fatal error: No Job status returned from FD.
18-Jul 23:37 leiden-dir JobId 105: Error: Bacula leiden-dir 5.0.3 (04Aug10): 18-Jul-2011 23:37:17

*KNIP*

  Scheduled time:         18-Jul-2011 21:37:00
  Start time:             18-Jul-2011 21:37:03
  End time:               18-Jul-2011 23:37:17
  Elapsed time:           2 hours 14 secs

In de director config:

code:

Job {
  Name = "blajob"
  JobDefs = "blaj-weekly"
  Write Bootstrap = "/var/lib/bacula/blaj.bsr"
  Max Run Time = 144000
}

Iemand nog een goed idee?

[Boudewijn]

Goed, ik heb de max time opgevoerd en de heartbeat op 60 minuten gezet.
Vervolgens in mijn bacula-dir (en storage daemon):

code:

   sysctl -w net.ipv4.tcp_keepalive_time=60

code:

  Elapsed time:           15 hours 22 mins 58 secs
  Priority:               10
  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:      33
  Volume Session Time:    1310599400

CRAP.
15 uur pruttelen voor 0 bytes.

[CAPSLOCK2000]

Gebruiken al die clients ook dezelfde configuratie? Ik bedoel, bewaren ze dezelfde directories?
Kan het zijn dat die defecte client probeert om /dev of /proc ofzo te backupppen?

Heb je tcpdump al gebruikt om te kijken of de juiste verbindingen worden opgezet?

[Boudewijn]

Het is dezelfde job ja:

code:

# List of files to be backed up
FileSet {
  Name = "Full Set"
  Include {
    Options {
      signature = MD5
    }
#
#  Put your list of files here, preceded by 'File =', one per line
#    or include an external list with:
#
#    File = <file-name
#
#  Note: / backs up everything on the root partition.
#    if you have other partitons such as /usr or /home
#    you will probably want to add them too.
#
#  By default this is defined to point to the Bacula build
#    directory to give a reasonable FileSet to backup to
#    disk storage during initial testing.
#
    File = /build/buildd/bacula-2.4.4/debian/tmp-build-sqlite
    #File = /
    File = /etc
    File = /root
    File = /var
    File = /home
  }

#
# If you backup the root directory, the following two excluded
#   files can be useful
#
  Exclude {
    File = /proc
    File = /tmp
    File = /.journal
    File = /.fsck
  }
}

Deze werkt ook op diverse andere bakken prima.

Qua client: Allemaal hetzelfde, standaard debian install. De ene heeft een mailserver, de andere mysql. Etc .


tcpdump ga ik zo eens doen, maar dat is meestal een last resort.

[mboy]

Heb je die heartbeat interval ook op fd's zelf ingesteld? Wij hebben ook last gehad van dit probleem bij verschillende clients en het instellen van een heartbeat interval op zowel de fd als de director lostte het probleem doorgaans wel op. HB interval staat bij ons trouwens op 15, maar ik weet niet meer precies waarom die keuze is gemaakt....

Die max-run instelling zal het wel niet zijn vermoed ik, die zou er nooit zo'n foutmelding uitgooien.

[Boudewijn]

Net ook even de heartbeat interval op de FD in de "FileDaemon" tag gezet ,maar er gebeurt weinig als ik een nieuwe backup start.
Normaal zie je de filedaemon in top wel terug op je client.

[mboy]

Maar wat ik dan wel apart vind is dat er nu helemaal geen bytes meer worden geschreven, terwijl dat eerst nog wel goed ging. Ik zou zeggen, doe eens een estimate op de bconsole van dir om te kijken of de communicatie tussen dir en fd verder tot op zekere hoogte werkt:

estimate job=<job-name> listing client=<client-name> fileset=<fileset-name>

Check ook nog even de connectiviteit tussen fd en sd met de settings zoals ze gedefinieerd staan in de storage resource op de director en probeer het eventueel ook eens met een andere, kleinere, fileset en kijk of die job wel goed wordt afgesloten.

[ Voor 0% gewijzigd door mboy op 22-07-2011 07:36 . Reden: typo ]

[Boudewijn]

Ik heb de fileset aangepast naar /home/boudewijn .

code:

*estimate
The defined Job resources are:
     1: www2job
     2: sqljob
     3: mailjob
     4: wwwjob
     5: X
     6: klantbackupjob
     7: BackupCatalog
     8: RestoreFiles
Select Job resource (1-8): 5
Using Catalog "MyCatalog"
Connecting to Client X at X.Y.nl:9102
2000 OK estimate files=13 bytes=24,720

Even de machinenaam weggecopieerd, die is nml van een klant .


Op zich ziet dit er prima uit... maar op machine X lijkt ook niets te gebeuren.


edit:
En na 10 mins staat hij daar nog steeds op .

[ Voor 5% gewijzigd door Boudewijn op 23-07-2011 18:43 ]

[Boudewijn]

Ik kreeg dus net dit mailtje ook nog eventjes:

code:

23-Jul 18:30 leiden-dir JobId 144: No prior Full backup Job record found.
23-Jul 18:30 leiden-dir JobId 144: No prior or suitable Full backup found in catalog. Doing FULL backup.
23-Jul 18:30 leiden-dir JobId 144: Start Backup JobId 144, Job=Xjob.2011-07-23_18.30.06_03
23-Jul 18:30 leiden-dir JobId 144: Using Device "leiden-filestorage"
23-Jul 18:42 leiden-dir JobId 144: Fatal error: Network error with FD during Backup: ERR=No data available
23-Jul 18:42 leiden-filestorage JobId 144: JobId=144 Job="Xjob.2011-07-23_18.30.06_03" marked to be canceled.
23-Jul 18:42 leiden-dir JobId 144: Fatal error: No Job status returned from FD.
23-Jul 18:42 leiden-dir JobId 144: Error: Bacula leiden-dir 5.0.3 (04Aug10): 23-Jul-2011 18:42:18
  Build OS:               i486-pc-linux-gnu debian wheezy/sid
  JobId:                  144
  Job:                    Xjob.2011-07-23_18.30.06_03
  Backup Level:           Full (upgraded from Incremental)
  Client:                 "X" 5.0.2 (28Apr10) x86_64-pc-linux-gnu,debian,squeeze/sid
  FileSet:                "Gong Set" 2011-07-23 18:30:06
  Pool:                   "LeidenPool" (From Job resource)
  Catalog:                "MyCatalog" (From Client resource)
  Storage:                "leiden-filestorage" (From Job resource)
  Scheduled time:         23-Jul-2011 18:30:02
  Start time:             23-Jul-2011 18:30:08
  End time:               23-Jul-2011 18:42:18
  Elapsed time:           12 mins 10 secs
  Priority:               10
  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:      36
  Volume Session Time:    1310599400
  Last Volume Bytes:      0 (0 B)
  Non-fatal FD errors:    0
  SD Errors:              0
  FD termination status:  Error
  SD termination status:  Error
  Termination:            *** Backup Error ***

Lekker balen.

[Boudewijn]

Nou ja, nog maar een schopje .

[CAPSLOCK2000]

Ik zou met een packetsniffer aan de weer gaan. Als het dan nog niet lukt denk ik dat je het beter een keer op de bacula mailinglijst kan proberen. Aangezien het bij een aantal andere clients wel goed gaat zit het probleem ofwel helemaal niet in Bacula, of het is een bug. Ik vrees dat je vraag te lastig is hier op te lossen.

[kluyze]

Toch nog een poging van mijn kant:

Toevallig geen overijverige firewall?

[Boudewijn]

Nop want dan zouden andere hosts wel moeten werken.

code:

boudewijn@serenity:~$ telnet leiden.X.nl 9103
Trying Y...
Connected to leiden.X.nl.
Escape character is '^]'.
^]
telnet> Connection closed.

Die connection close ik zelf.

Werkt prima dus vanaf de remote server naar de backupdoos.
De andere kant op, op 9102 uiteraard ook .

[Boudewijn]

Wat trouwens wel weer echt gaaf is, is dit:

code:

Date/Time   Source Address/Port Destination Address/Port    Translated Source Address/Port  Translated Destination Address/Port Service Duration    Bytes Sent  Bytes Received  Close Reason
2011-07-25 21:31:43 <client IP>:34013   <director IP>9103   <client IP>:34013   192.168.1.44:9103   TCP PORT 9103   4 sec.  288 148 Close - TCP FIN
2011-07-25 09:43:35 <client IP>:57727   <director IP>:9103  <client IP>:57727   192.168.1.44:9103   TCP PORT 9103   144055 sec. 136365  136301  Close - AGE OUT
2011-07-23 17:42:21 <client IP>:36260   <director IP>:9103  <client IP>:36260   192.168.1.44:9103   TCP PORT 9103   732 sec.    1616    1482    Close - AGE OUT

Aldus mijn router. Ik zie dus dat hier erg lang een connectie open heeft gestaan, maar hier amper data doorheen is gestroomd.

[ Voor 4% gewijzigd door Boudewijn op 25-07-2011 22:38 ]

[Boudewijn]

Goed, een laatste schop.


Het probleem is nml opgelost. Ik had een vrij hoge HeartBeat Interval, maar met een waarde van 15 gaat het nu wel weer prima . Dat was alles .