[Bacula-users] Restore performance using concurrent backups

2006-03-29 Thread Christoph Litauer
Hi,

I just searched the archives but didn't find hints. Sorry if this
question has been asked before.

I am using bacula-1.36.3 for the backup of about 12 linux clients. At
the moment I just use an external hardware raid as (File-)backup device:

Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /storage
  LabelMedia = yes;
  Random Access = Yes;
  AutomaticMount = yes;
  RemovableMedia = no;
  AlwaysOpen = no;
  Maximum Volume Size = 2147483648  # 2GB
}

The backups are done in parallel with a maximum of 20 concurrent jobs.

The most recent backup of one of the clients (about 1,6 GB of data)
consists of a full, 1 differential and 2 incrememtal backups, located on
16 backup files (FileStorage).

Running the restore I get a "Rate" of about 500 KB/sec (restoring to a
local filesystem on the storage server). The raid device is able to
deliver 12MB/sec. The local filesystem is able to write about 10MB/sec,

My conclusion for that degraded performance is that even if I use
FileStorage as a random access media, the restore process recovers the
data by sequentially reading all the 16 backup files "searching for the
right files". I would have expected a rate of nearly native disk speed
because the backup files could be "seeked".

A solution would be to not perform concurrent backups. But then the
backup window gets significantly wider (especially for the incrementals).

Any solutions, hints? Would my problem disappear if I upgrade to 1.38.x?

Thanks a lot in advance. If you need more of my configuration files, no
problem, please tell me.

-- 
Regards
Christoph

Christoph Litauer  [EMAIL PROTECTED]
Uni Koblenz, Computing Center, http://www.uni-koblenz.de/~litauer
Postfach 201602, 56016 Koblenz Fon: +49 261 287-1311, Fax: -100 1311
PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] Restore performance using concurrent backups

2006-03-30 Thread Arno Lehmann

Hello,

On 3/30/2006 9:38 AM, Christoph Litauer wrote:

Hi,

I just searched the archives but didn't find hints. Sorry if this
question has been asked before.

I am using bacula-1.36.3 for the backup of about 12 linux clients. At
the moment I just use an external hardware raid as (File-)backup device:

Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /storage
  LabelMedia = yes;
  Random Access = Yes;
  AutomaticMount = yes;
  RemovableMedia = no;
  AlwaysOpen = no;
  Maximum Volume Size = 2147483648  # 2GB
}

The backups are done in parallel with a maximum of 20 concurrent jobs.

The most recent backup of one of the clients (about 1,6 GB of data)
consists of a full, 1 differential and 2 incrememtal backups, located on
16 backup files (FileStorage).

Running the restore I get a "Rate" of about 500 KB/sec (restoring to a
local filesystem on the storage server). The raid device is able to
deliver 12MB/sec. The local filesystem is able to write about 10MB/sec,

My conclusion for that degraded performance is that even if I use
FileStorage as a random access media, the restore process recovers the
data by sequentially reading all the 16 backup files "searching for the
right files". I would have expected a rate of nearly native disk speed
because the backup files could be "seeked".


As far as I know, there are some problems using seeking instead of 
reading and interpreting which lead to Kern disabling volume seeking for 
file volumes, so your conclusion is right.



A solution would be to not perform concurrent backups. But then the
backup window gets significantly wider (especially for the incrementals).

Any solutions, hints? Would my problem disappear if I upgrade to 1.38.x?


Perhaps, I don't know if that peculiar problem is resolved by now. You 
might read through the release notes of the 1.38 versions.


Possible solution, assuming you've got enough disk space: Use spooling. 
It's - theoretically - nonsense doing this with file volumes, but might 
reslove the performance problems you see. Try to put the spool space 
onto different physical disks and a different filesystem than the real 
storage space!


Arno


Thanks a lot in advance. If you need more of my configuration files, no
problem, please tell me.



--
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann  http://www.its-lehmann.de


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users