Backup Central

hi,
is it possible (and does have sense) to run concurrent jobs on a tape ?
no risks of corruption of datas ?
thanks for your tips

hi,
is it possible (and does have sense) to run concurrent jobs on a tape ?
no risks of corruption of datas ?
thanks for your tips

On 3/2/07, St=E9phane Lardier <funfunfun < at > fr...> wrote:
hi,
is it possible (and does have sense) to run concurrent jobs on a tape ?
no risks of corruption of datas ?
thanks for your tips


No this works very well.

John

John Drescher a écrit :
On 3/2/07, Stéphane Lardier <funfunfun < at > fr...> wrote:
hi,
is it possible (and does have sense) to run concurrent jobs on a tape ?
no risks of corruption of datas ?
thanks for your tips


No this works very well.

good news. I can concurrently save my three remote servers behind a
slowly ADSL line but I have set Maximum Concurrent Jobs to 4
but it seems that the second job is queued.
what is wrong ?

On 3/2/07, St=E9phane Lardier <funfunfun < at > fr...> wrote:
John Drescher a =E9crit :
On 3/2/07, St=E9phane Lardier <funfunfun < at > fr...> wrote:
hi,
is it possible (and does have sense) to run concurrent jobs on a tape =
?
no risks of corruption of datas ?
thanks for your tips


No this works very well.

good news. I can concurrently save my three remote servers behind a
slowly ADSL line but I have set Maximum Concurrent Jobs to 4
but it seems that the second job is queued.
what is wrong ?

You need this in the director and storage daemon and if you want the fileda=
emon.

John

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Drescher wrote:
On 3/2/07, Stéphane Lardier <funfunfun < at > fr...> wrote:
hi,
is it possible (and does have sense) to run concurrent jobs on a tape ?
no risks of corruption of datas ?
thanks for your tips


No this works very well.

Wasn't there a difference between 'Concurrent with spooling' and 'really
concurrent as in interlaced'? I seem to recall something as if the
latter wasn't tested/recommended but I may have missed that getting
changed. (So far I'm only aware that concurrency through spooling works
well and is thoroughly tested.)

Greetings,
Michel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFF6EPD2Vs+MkscAyURApNOAJ94Snc4gpHXi50XSHgGe6U+f38JDwCgqKlC
KXTB0WaUcytsJwREi4SD7qo=
=xLSY
-----END PGP SIGNATURE-----

John Drescher a écrit :
On 3/2/07, Stéphane Lardier <funfunfun < at > fr...> wrote:
John Drescher a écrit :
On 3/2/07, Stéphane Lardier <funfunfun < at > fr...> wrote:
hi,
is it possible (and does have sense) to run concurrent jobs on a tape ?
no risks of corruption of datas ?
thanks for your tips

No this works very well.
good news. I can concurrently save my three remote servers behind a
slowly ADSL line but I have set Maximum Concurrent Jobs to 4
but it seems that the second job is queued.
what is wrong ?

You need this in the director and storage daemon and if you want the filedaemon.

very strange. It seems that only one job is running:
Running Jobs:
Writing: Full Backup job lapale JobId=416 Volume="Vol03"
pool="Default" device=""Drive-1" (/dev/nst0)"
spooling=0 despooling=0 despool_wait=0
Files=2 Bytes=4,456,628 Bytes/sec=29,710
FDReadSeqNo=82 in_msg=79 out_msg=5 fd=6
====

Jobs waiting to reserve a drive:
====

and grep in my configuration files give:
[root < at > images root]# fgrep -i concurrent /etc/bacula/*.conf
/etc/bacula/bacula-dir.conf: Maximum Concurrent Jobs = 4
/etc/bacula/bacula-fd.conf: Maximum Concurrent Jobs = 20
/etc/bacula/bacula-sd.conf: Maximum Concurrent Jobs = 20

and grep in my configuration files give:
[root < at > images root]# fgrep -i concurrent /etc/bacula/*.conf
/etc/bacula/bacula-dir.conf: Maximum Concurrent Jobs = 4
/etc/bacula/bacula-fd.conf: Maximum Concurrent Jobs = 20
/etc/bacula/bacula-sd.conf: Maximum Concurrent Jobs = 20

Have you restarted or reloaded the config files after making these
changes. Also is this also in the storage section of bacula-dir.conf?
If both are true I am not sure why this is not working.

John

John Drescher a écrit :
and grep in my configuration files give:
[root < at > images root]# fgrep -i concurrent /etc/bacula/*.conf
/etc/bacula/bacula-dir.conf: Maximum Concurrent Jobs = 4
/etc/bacula/bacula-fd.conf: Maximum Concurrent Jobs = 20
/etc/bacula/bacula-sd.conf: Maximum Concurrent Jobs = 20

Have you restarted or reloaded the config files after making these
changes. Also is this also in the storage section of bacula-dir.conf?
If both are true I am not sure why this is not working.

ok, corrected.
Maximum concurrent JOos was not set in the good section of my
bacula-dir.conf
now, it works nicely
thanks a lot

Hi,

On 3/2/2007 4:33 PM, Michel Meyers wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=20
John Drescher wrote:
=20
On 3/2/07, St=E9phane Lardier <funfunfun < at > fr...> wrote:

hi,
is it possible (and does have sense) to run concurrent jobs on a tape =
?
no risks of corruption of datas ?
thanks for your tips


No this works very well.
=20
=20
Wasn't there a difference between 'Concurrent with spooling' and 'reall=
y
concurrent as in interlaced'? I seem to recall something as if the
latter wasn't tested/recommended but I may have missed that getting
changed. (So far I'm only aware that concurrency through spooling works=

well and is thoroughly tested.)

No, I think you're absolutely right - job concurrency without spooling=20
is not exactly recommended. Rightfully so, in my opinion, because you'd=20
really have a bad performance when restoring.

Due to that fact, I suppose noone ever tested it.

With spooling, concurrent jobs to tape work fine.

Arno

Greetings,
Michel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
=20
iD8DBQFF6EPD2Vs+MkscAyURApNOAJ94Snc4gpHXi50XSHgGe6U+f38JDwCgqKlC
KXTB0WaUcytsJwREi4SD7qo=3D
=3DxLSY
-----END PGP SIGNATURE-----
=20
-----------------------------------------------------------------------=
--
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share=
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

--=20
IT-Service Lehmann al < at > it...
Arno Lehmann http://www.its-lehmann.de

No, I think you're absolutely right - job concurrency without spooling
is not exactly recommended. Rightfully so, in my opinion, because you'd
really have a bad performance when restoring.

Due to that fact, I suppose noone ever tested it.

With spooling, concurrent jobs to tape work fine.

I have only used it with spooling and it works very well in that case.

John

On Friday 02 March 2007 16:54, Arno Lehmann wrote:
Hi,

On 3/2/2007 4:33 PM, Michel Meyers wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Drescher wrote:
On 3/2/07, St=E9phane Lardier <funfunfun < at > fr...> wrote:
hi,
is it possible (and does have sense) to run concurrent jobs on a tape ?
no risks of corruption of datas ?
thanks for your tips

No this works very well.

Wasn't there a difference between 'Concurrent with spooling' and 'really
concurrent as in interlaced'? I seem to recall something as if the
latter wasn't tested/recommended but I may have missed that getting
changed. (So far I'm only aware that concurrency through spooling works
well and is thoroughly tested.)

No, I think you're absolutely right - job concurrency without spooling
is not exactly recommended. Rightfully so, in my opinion, because you'd
really have a bad performance when restoring.

Due to that fact, I suppose noone ever tested it.

Yes, it is *very* well tested and works fine, but as you say, it is not rea=
lly=20
recommended without spooling.


With spooling, concurrent jobs to tape work fine.

Arno

Greetings,
Michel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFF6EPD2Vs+MkscAyURApNOAJ94Snc4gpHXi50XSHgGe6U+f38JDwCgqKlC
KXTB0WaUcytsJwREi4SD7qo=3D
=3DxLSY
-----END PGP SIGNATURE-----

-----------------------------------------------------------------------=
=2D-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys-and earn ca=
sh
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

On Fri, 2 Mar 2007, Michel Meyers wrote:

Wasn't there a difference between 'Concurrent with spooling' and 'really
concurrent as in interlaced'?

Yes.

I seem to recall something as if the
latter wasn't tested/recommended

It's fine to lay data to tape using concurrent/interlaced, however
restores will be _very_ painful due to massive tape shoeshining as it
seeks small distances for each block to recover, resulting in restore
down around 1-2MB/s or slower (assuming LTO2)

The time penalties for laying data as concurrent/spooled are tiny once
there are 2 or more jobs underway (ASSUMING THE SPOOL DISK IS FAST ENOUGH
TO KEEP UP![*]), but the speed on restore will be close to the native
speed of the tape, assuming no limits imposed by the target disk or
intervening network.

[*] In order to keep up with 4-6 jobs spooling off remote servers via
1Gb/s connections to 2 FC-connected LTO2 tape drives in a changer, I ended
up having to stripe the spool filesystem cross 4 SATA 2 drives - and this
only _just_ keeps up.

It became pretty clear while benchmarking that I should be looking very
hard at a 6-8 disk (or more) stripeset in order to achieve reasonable
speeds for any more tape drives, or if we moved to LTO3. The problem with
that many drives is that it requires a good dedicated RAID controller and
moves out of the realm of general commodity hardware for the backup
machine.

On Fri, 2 Mar 2007, Arno Lehmann wrote:

No, I think you're absolutely right - job concurrency without spooling
is not exactly recommended. Rightfully so, in my opinion, because you'd
really have a bad performance when restoring.

Due to that fact, I suppose noone ever tested it.

I tested it, in order to prove that spooling was an absolute requirement
for multiple concurrent backups.

"bad performance" is the understatment of the century...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This question has been asked in the last week or two (please check th=
e
archives) and is well explained in the manual.

St=E9phane Lardier wrote:
hi,
is it possible (and does have sense) to run concurrent jobs on a ta=
pe ?
no risks of corruption of datas ?
thanks for your tips
=20
=20
-------------------------------------------------------------------=
------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to s=
hare your
opinions on IT & business topics through brief surveys-and earn cas=
h
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&=
CID=3DDEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer I=
II
|$&| |__| | | |__/ | \| _| |novosirj < at > um... - 973/972.0922 (2-09=
22)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C=
630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF9q66mb+gadEcsb4RAqu4AKDjTZ3Rz3krT0rpIzKGRFy6kQNxZwCfaP8X
mD1luon0+fbmkH1XAVvHC0g=3D
=3D5qsn
-----END PGP SIGNATURE-----