Re: [Bacula-users] Bacula, Autochangers, insist on loading 'not in changer' media...

2023-05-12 Thread Josh Fisher via Bacula-users
I would add that this problem appears to occur when all in-changer tapes 
are unavailable due to volume status AND the job's pool does contain 
available tapes, but those tapes are not in-changer. Bacula will attempt 
to load a tape that is not in-changer, where it should send an operator 
intervention notice.


On 5/12/23 06:22, Marco Gaiarin wrote:

We have some setups using bacula (debian buster, 9.4.2-2+deb10u1) and RDX
media, by the way of the 'vchanger' (Virtual Changer) script.

All works as expected, until the current mounted media exaust the 'in
changer' media (because exausted it; or because simply users load the
incorrect media...).

After that, bacula try to mount expired (purge them) or generically
avaliable volumes from other media, that are 'not in changer', putting them
on error.
We have extensivaly debugged vchanger script, that seems behave correctly.

Bacula seems have a current and correct state of 'in changer' volumes, and
anyway a 'update volumes' on console does not solve the trouble.


On director we have:

Autochanger {
Name = SDPVE2RDX
Address = sdpve2.sd.lnf.it
SDPort = 9103
Password = "unknown"
Maximum Concurrent Jobs = 5
Device = RDXAutochanger
Media Type = RDX
}

Pool {
Name = VEN-SD-SDPVE2RDXPool
Pool Type = Backup
Volume Use Duration = 1 days
Maximum Volume Jobs = 1
Recycle = yes
AutoPrune = yes
Action On Purge = Truncate
Volume Retention = 20 days
}


On SD we have:

Autochanger {
   Name = RDXAutochanger
   Device = RDXStorage0
   Device = RDXStorage1
   Device = RDXStorage2
   Changer Command = "/usr/bin/vchanger %c %o %S %a %d"
   Changer Device = "/etc/vchanger/SDPVE2RDX.conf"
}

Device {
   Name = RDXStorage0
   Drive Index = 0
   Device Type = File
   Media Type = RDX
   RemovableMedia = no
   RandomAccess = yes
   Maximum Concurrent Jobs = 1
   Archive Device = "/var/spool/vchanger/SDPVE2RDX/0"
}

Device {
   Name = RDXStorage1
   Drive Index = 1
   Device Type = File
   Media Type = RDX
   RemovableMedia = no
   RandomAccess = yes
   Maximum Concurrent Jobs = 1
   Archive Device = "/var/spool/vchanger/SDPVE2RDX/1"
}

Device {
   Name = RDXStorage2
   Drive Index = 2
   Device Type = File
   Media Type = RDX
   RemovableMedia = no
   RandomAccess = yes
   Maximum Concurrent Jobs = 1
   Archive Device = "/var/spool/vchanger/SDPVE2RDX/2"
}


Someone have some clue? Thanks.




___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] compression with lto?

2023-05-12 Thread Dr. Thorsten Brandau


Gary R. Schmidt schrieb am 12.05.23 um 16:26:

On 11/05/2023 13:49, Dr. Thorsten Brandau wrote:

Hi
I use an lto-9 drive for backup. I activated hardware compression on 
the tape (i think) but all the logs of bacula show a tape change at 
18TB which should be the native (uncompressed) capacity. From 
experience I would expect a ratio of at last 1:1.2. Is there any way 
to make sure to use compression (or as last resort activate software 
compression)?



Are you using the actual compressed device in your bacula-sd.conf?

On Solaris I use /dev/rmt/0cbn to turn on compression.  (But I started 
out handling tape back when they were huge upright things, throwing 
pseudo-random characters into device names is reflex. :-) )


Cheers,
    Gary    B-)



Hi Gary,

well I remember times were you could change the whole disc with a cake 
basket like holder and tapes could be used as paperweights and through 
from the 5th floor, but will work fine afterwards...


I am running linux and the tape is /dev/nst0 which should referr to the 
compressed device. The loader is sg7 but that should not play any role.


I also remember times where tapes had so many names in /dev but also our 
older LTOs do not fuss around and leave little options on the dev side, 
but you have to configure them with MT or MTX.


However, I turned compression on with MT and MTX, so I still do not 
understand why it seems that the data is imcompressible... I will try 
software compression to see IF the data is compressible (s many text 
files, should shrink nice an easy...).


Cheers

TB

___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] compression with lto?

2023-05-12 Thread Gary R. Schmidt

On 11/05/2023 13:49, Dr. Thorsten Brandau wrote:

Hi
I use an lto-9 drive for backup. I activated hardware compression on the tape 
(i think) but all the logs of bacula show a tape change at 18TB which should be 
the native (uncompressed) capacity. From experience I would expect a ratio of 
at last 1:1.2. Is there any way to make sure to use compression (or as last 
resort activate software compression)?


Are you using the actual compressed device in your bacula-sd.conf?

On Solaris I use /dev/rmt/0cbn to turn on compression.  (But I started 
out handling tape back when they were huge upright things, throwing 
pseudo-random characters into device names is reflex.  :-) )


Cheers,
GaryB-)


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] compression with lto?

2023-05-12 Thread Dr. Thorsten Brandau


Bill Arlofski via Bacula-users schrieb am 11.05.23 um 20:45:

On 5/10/23 21:49, Dr. Thorsten Brandau wrote:

Hi
I use an lto-9 drive for backup. I activated hardware compression on 
the tape (i think) but all the logs of bacula show a tape change at 
18TB which should be the native (uncompressed) capacity. From 
experience I would expect a ratio of at last 1:1.2. Is there any way 
to make sure to use compression (or as last resort activate software 
compression)?



Hello Thorsten,

Of course, with LTO tape drives, you always want to enable hardware 
compression and disable software compression in Bacula.


How that is set on your specific drive(s) I do not know. :)

Bacula will just write until it gets an EOT (end of tape) from the 
tape drive, so the compression you will see is dependent on your dataset.




Some tips:
In your Director's configuration for the Storage resource which points 
to the SD's Tape drive (or library with multiple drives), you should set


`AllowCompression = no`


This will tell the FDs to not try to compress data before sending it 
to the SD when using this Storage resource in a job, even if you have 
a `compression = (lzo|gzip|zstd)` in your fileset.


For jobs using this Storage, if compression in enabled for the fileset 
in use, you will see a harmless info log entry in the job logs telling 
you that "compression is not allowed for this storage device". (or 
similar)


I prefer to enable/disable this in the Director's Storage resource and 
always enable compression in my filesets so that the same job and 
fileset, when using a different Director Storage that allows 
compression, it will automatically "Just Work"™



P.S. You can enable/disable compression in the SD's Devices, but I 
prefer to set it at what I would call the beginning of the chain in 
the Director's Storage resource.



Home some of this is helpful,
Bill 



Hi Bill,

thank you. It still does not solve my problem why it does not compress 
the data on the tape... I think this is strange. I try to use GZIP6 now 
and see if the written data/total data changes then to see if I can safe 
some meters of tapes. And Backuptime. It seems that the Raid here is not 
the fastest to read and that makes the backup slow.


Cheers

T
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


[Bacula-users] Bacula, Autochangers, insist on loading 'not in changer' media...

2023-05-12 Thread Marco Gaiarin


We have some setups using bacula (debian buster, 9.4.2-2+deb10u1) and RDX
media, by the way of the 'vchanger' (Virtual Changer) script.

All works as expected, until the current mounted media exaust the 'in
changer' media (because exausted it; or because simply users load the
incorrect media...).

After that, bacula try to mount expired (purge them) or generically
avaliable volumes from other media, that are 'not in changer', putting them
on error.
We have extensivaly debugged vchanger script, that seems behave correctly.

Bacula seems have a current and correct state of 'in changer' volumes, and
anyway a 'update volumes' on console does not solve the trouble.


On director we have:

Autochanger {
Name = SDPVE2RDX
Address = sdpve2.sd.lnf.it
SDPort = 9103
Password = "unknown"
Maximum Concurrent Jobs = 5
Device = RDXAutochanger
Media Type = RDX
}

Pool {
Name = VEN-SD-SDPVE2RDXPool
Pool Type = Backup
Volume Use Duration = 1 days
Maximum Volume Jobs = 1
Recycle = yes
AutoPrune = yes
Action On Purge = Truncate
Volume Retention = 20 days
}


On SD we have:

Autochanger {
  Name = RDXAutochanger
  Device = RDXStorage0
  Device = RDXStorage1
  Device = RDXStorage2
  Changer Command = "/usr/bin/vchanger %c %o %S %a %d"
  Changer Device = "/etc/vchanger/SDPVE2RDX.conf"
}

Device {
  Name = RDXStorage0
  Drive Index = 0
  Device Type = File
  Media Type = RDX
  RemovableMedia = no
  RandomAccess = yes
  Maximum Concurrent Jobs = 1
  Archive Device = "/var/spool/vchanger/SDPVE2RDX/0"
}

Device {
  Name = RDXStorage1
  Drive Index = 1
  Device Type = File
  Media Type = RDX
  RemovableMedia = no
  RandomAccess = yes
  Maximum Concurrent Jobs = 1
  Archive Device = "/var/spool/vchanger/SDPVE2RDX/1"
}

Device {
  Name = RDXStorage2
  Drive Index = 2
  Device Type = File
  Media Type = RDX
  RemovableMedia = no
  RandomAccess = yes
  Maximum Concurrent Jobs = 1
  Archive Device = "/var/spool/vchanger/SDPVE2RDX/2"
}


Someone have some clue? Thanks.

-- 
  Ho ancora la forza di starvi a raccontare
  le mie storie di sempre, di come posso amare  (F. Guccini)




___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users