Re: [Vchanger-users] Relabeling of volumes...

[Marco G. <ga...@li...>]

Mandi! Josh Fisher
  In chel di` si favelave...

> First, an answer to the question....to relabel a zero-byte volume, go to
> bconsole and delete the volume record with 'delete volume=volume_name'. Then
> from bconsole issue a 'label barcodes' command. It will not relabel already
> labeled volumes, only the volumes on the magazine that aren't already in the
> Bacula catalog.

Wonderful!


> For the volumes that do have data but are marked as Error, go to bconsole
> and issue 'update volume=volume_name volstatus=Active' to change the volume
> status from Error back to Active.

Also, thanks.


> There are a few reasons why a volume gets marked in error. One is when there
> is truly an i/o error with the hardware. Check dmesg. Bacula thinks that
> PDPVE2RDX_0001_0000 is labeled, but it has a zero byte length as if the
> volume label was never written. That would cause Bacula to mark it as Error
> when it couldn't read the volume label. Most definitely, ejecting the RDX
> device before an umount could do that. One way to mitigate that is to set
> Sync on Close = yes in the Device resources in bacula-sd.conf. That will
> cause Bacula to flush the cache when closing the volume file.

Around 'eject' run i've found in logs FS/kernel errors, so i suppose that
really is 'eject'... to umount the filesystem i use the udev script, that
use 'at' to do the umount, and subsequent i'll do the 'eject'.
I've added  an 'sleep 10' between, i hope will suffice.

I've tried also to add 'Sync On Close = yes' but...

 Sep 27 15:46:04 vipve2 bacula-sd[2647]: bacula-sd: ERROR TERMINATION at parse_conf.c:1104
 Sep 27 15:46:04 vipve2 bacula-sd[2647]: Config error: Keyword "SyncOnClose" not permitted in this resource.
 Sep 27 15:46:04 vipve2 bacula-sd[2647]: Perhaps you left the trailing brace off of the previous resource.
 Sep 27 15:46:04 vipve2 bacula-sd[2647]:             : line 122, col 16 of file /etc/bacula/bacula-sd.conf
 Sep 27 15:46:04 vipve2 bacula-sd[2647]:   Sync On Close = yes


> against setting it to no because of potential race conditions. What happens
> is this:

Perfectly clear. I have a daily task and a weekly task, and effectively most
of my trouble happens on the 'daily + weekly' day...

> There are a few ways to get around this when using concurrent jobs. One way
> is to set Maximum Concurrent Jobs > 1 in the Device resources in
> bacula-sd.conf and allow multiple jobs to write to the same drive and volume
> concurrently. This will cause the job's blocks to be interleaved with each
> other and potentially slow restores. On disk media it should be OK to do so.
> On tape it would be really slow. On SSD it would make almost no difference.

I've just 'Maximum Concurrent Jobs = 5' on director's Autochanger{}, on
storage's storage{} and device {}.


Thanks.