I filed it yesterday:
http://bugs.bacula.org/view.php?id=1716
And it was closed immediately as not fixable. I'm okay with what was
explained, I think my only comment from here on out is if it was
explicitly called out in the documentation not to mix volume sizes.
Mike C
On 03/30/2011 06:30 AM,
John Drescher wrote:
> I have had that as well. I believe any change in the block size causes
> all previous tapes to be unreadable. Could this be a fixed blocks
> versus variable blocks problem?
I suspect so, but unless it's filed it won't get looked at by Kern.
AB
-
On 03/29/2011 04:21 AM, Alan Brown wrote:
> Mike Carlson wrote:
>
>> I had recently changed the bacula-sd.conf from using " Maximum Block
>> Size = 262144", to whatever the default value is. I didn't realize that
>> by undoing this, all previous backups would no longer be readable (since
>> I gues
>> I had recently changed the bacula-sd.conf from using " Maximum Block
>> Size = 262144", to whatever the default value is. I didn't realize that
>> by undoing this, all previous backups would no longer be readable (since
>> I guess the SD is expecting a different block size?). So, I added that
>
Mike Carlson wrote:
> I had recently changed the bacula-sd.conf from using " Maximum Block
> Size = 262144", to whatever the default value is. I didn't realize that
> by undoing this, all previous backups would no longer be readable (since
> I guess the SD is expecting a different block size?)
On 03/28/2011 11:10 AM, Mike Carlson wrote:
I'm getting a "Requested Volume is not a Bacula labled Volume,
because: ERR=block.c:318 Volume data error at 0:0!" at the beginning
of a restore for disk based backups.
Here is what the console is showing:
8-Mar 10:52 write.llnl.gov-dir JobId 31
I'm getting a "Requested Volume is not a Bacula labled Volume, because:
ERR=block.c:318 Volume data error at 0:0!" at the beginning of a restore
for disk based backups.
Here is what the console is showing:
8-Mar 10:52 write.llnl.gov-dir JobId 31259: Start Restore Job
home-server01_Restor
