Package: bacula Version: 1.38.11-1 Severity: normal We have a problem with very long backup-times of our file-server.
The file-server is only used for NFS and is quite heavily loaded. It is a Debian etch amd64 with a 2.6.16.20 kernel running on a Athlon 64 X2 3800+ (dual core) with 2Gb mem and two 500 Gb discs in raid1. ext3 is used as filesystem, with dir_index enabled. The backup-server is also a Debian etch amd64 but with a 2.6.15.6 kernel and an Athlon 64 3200+ CPU with 512 Mb mem. Both bacula-sd and bacula-dir is running on the backup-server, as well as a mysql-daemon. Discs are used for backup. The file-server and the backup-server are connected via an GE-network without loss. I've done some measurements on a ~7.5 Gb directory tree with 88208 files (just one user-account): bacula backup without SW compression: 1 hour 45 mins 2 secs bacula backup with SW compression: 2 hours 42 mins 11 secs local tar on the fileserver*: 53 mins 3 secs * time /bin/sh -c "tar cf - directory | cat >/dev/null" The CPU's on the fileserver was unloaded during all operations, one of them was 100% idle, the other was mostly >90% IO-wait. The backup-server is 98%-100% idle at all time. Why is the local tar *much* faster then the bacula-fd??? And why is SW compression making the backup much slower, even with unloaded CPU's? I've studied the network traffic pattern with ethereal during a backup, and the backup-server is responding directly at all time. It is waiting for data from the fileserver. I've seen up to 400 ms without a single packet from the fileserver and most of the packets sent from the fileserver to the backup-server is small. What can explain this? How can I debug/analyze this further. What should I try? / Anders -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.6 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to sv_SE) Versions of packages bacula depends on: ii bacula-client 1.38.11-1 Network backup, recovery and verif ii bacula-server 1.38.11-1 Network backup, recovery and verif bacula recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
