The funny thing is the problem went away by itself. Tapes were again filling up
at approx 420GB per tape.
It was doing that for a few months of regular backup cycles. But now
unfortunately tapes are once again coming up as Full at only 320GB.
We do regular rewind and WEOF on these tapes prior t
Thanks Alan
re: Cleaning tapes are abrasive. Don't use them unless the drive asks for
them. LTO drives and media have internal head and path wiper mechanisms
which keep things under control under normal circumstances - cleaning
tapes are a last resort.
Noted. Will do so only when drive asks from
FWIW: I had similar problems with a large batch of LTO5 tapes recently.
Discussion with the tech support guys at Overland brought out the
information that sometimes they see this on new tapes due to dust
contamination during assembly (or insufficient removal of loose
particles during manufactur
It would seem the problem resolved itself.
All our tapes are now getting full at 410GB and over. No tape is under 400GB so
far (about 10 of them swapped around). Do not believe it was tape drive itself.
All we've done to the machine was regular ubuntu upgrades and machine restarts.
Occasionally
> We've got nowhere with this unfortunately and are left to run the critical
> backups anyway knowing we would basically loose about 100GB per tape (x30+
> tapes) this becomes an $$$ issue. We tried a few things, but nothing has
> worked.
We had a similar issue with a Tandberg LTO4. Testing by
Just an update, however no good news.
We've got nowhere with this unfortunately and are left to run the critical
backups anyway knowing we would basically loose about 100GB per tape (x30+
tapes) this becomes an $$$ issue. We tried a few things, but nothing has worked.
If anyone has any ideas as
Zitat von Dan Langille :
> On Nov 22, 2012, at 9:40 AM, Jacky Carimalo wrote:
>
>> Le 20/11/2012 16:39, Tilman Schmidt a écrit :
>>> Am 20.11.2012 17:14, schrieb Jacky Carimalo:
Le 20/11/2012 15:32, John Drescher a écrit :
> Also you should avoid /dev/st0 and use /dev/nst0 since /dev/st0
On Nov 22, 2012, at 9:40 AM, Jacky Carimalo wrote:
> Le 20/11/2012 16:39, Tilman Schmidt a écrit :
>> Am 20.11.2012 17:14, schrieb Jacky Carimalo:
>>> Le 20/11/2012 15:32, John Drescher a écrit :
Also you should avoid /dev/st0 and use /dev/nst0 since /dev/st0 can
cause corruption in you
Le 20/11/2012 16:39, Tilman Schmidt a écrit :
Am 20.11.2012 17:14, schrieb Jacky Carimalo:
Le 20/11/2012 15:32, John Drescher a écrit :
Also you should avoid /dev/st0 and use /dev/nst0 since /dev/st0 can
cause corruption in your tapes.
But I have no choice :
bacula2-64:~/bacula/bin# lsscsi -
Am 20.11.2012 17:14, schrieb Jacky Carimalo:
> Le 20/11/2012 15:32, John Drescher a écrit :
>> Also you should avoid /dev/st0 and use /dev/nst0 since /dev/st0 can
>> cause corruption in your tapes.
>>
> But I have no choice :
>
> bacula2-64:~/bacula/bin# lsscsi -g
> [0:0:0:0]diskIFT
Am 20.11.2012 17:13, schrieb Jacky Carimalo:
> kern.log on the host machine :
> Nov 20 04:49:51 singleton.u06.univ-nantes.prive kernel: [1168599.570017]
> lpfc :08:00.0: 0:(0):0713 SCSI layer issued Device Reset (1, 0)
> return x2002
> Nov 20 04:49:51 singleton.u06.univ-nantes.prive kernel: [
Zitat von Jacky Carimalo :
> Le 20/11/2012 15:32, John Drescher a écrit :
>> On Tue, Nov 20, 2012 at 9:30 AM, John Drescher wrote:
>>> On Tue, Nov 20, 2012 at 10:15 AM, Jacky Carimalo
>>> wrote:
I put Volume Use Duration = 36 months,
but always having sometimes :
Error: bloc
Hello,
2012/11/20 Jacky Carimalo
> Yes, LTP102L1 is a tape volume.
> I defined Maximum Volumes = 1000 ; as you said, it would be better having
> no line like this ; but I think it would be the same :
>
Parameter Maximum Volumes = 1000 do not cause volume to be set as Used. You
have to use Max
Le 20/11/2012 15:32, John Drescher a écrit :
> On Tue, Nov 20, 2012 at 9:30 AM, John Drescher wrote:
>> On Tue, Nov 20, 2012 at 10:15 AM, Jacky Carimalo
>> wrote:
>>> I put Volume Use Duration = 36 months,
>>> but always having sometimes :
>>>
>>> Error: block.c:590 Write error at 88:2499 on devi
Le 20/11/2012 15:30, John Drescher a écrit :
> On Tue, Nov 20, 2012 at 10:15 AM, Jacky Carimalo
> wrote:
>> I put Volume Use Duration = 36 months,
>> but always having sometimes :
>>
>> Error: block.c:590 Write error at 88:2499 on device "OVL_LTO-3_Drive-2"
>> (/dev/st0). ERR=Erreur d'entrée/sorti
On Tue, Nov 20, 2012 at 9:30 AM, John Drescher wrote:
> On Tue, Nov 20, 2012 at 10:15 AM, Jacky Carimalo
> wrote:
>> I put Volume Use Duration = 36 months,
>> but always having sometimes :
>>
>> Error: block.c:590 Write error at 88:2499 on device "OVL_LTO-3_Drive-2"
>> (/dev/st0). ERR=Erreur d'en
On Tue, Nov 20, 2012 at 10:15 AM, Jacky Carimalo
wrote:
> I put Volume Use Duration = 36 months,
> but always having sometimes :
>
> Error: block.c:590 Write error at 88:2499 on device "OVL_LTO-3_Drive-2"
> (/dev/st0). ERR=Erreur d'entrée/sortie.
> Error: Error writing final EOF to tape. This Volu
Yes, LTP102L1 is a tape volume.
I defined Maximum Volumes = 1000 ; as you said, it would be better
having no line like this ; but I think it would be the same :
having sometimes :
Error: block.c:590 Write error at 88:2499 on device "OVL_LTO-3_Drive-2"
(/dev/st0). ERR=Erreur d'entrée/sortie.
E
I put Volume Use Duration = 36 months,
but always having sometimes :
Error: block.c:590 Write error at 88:2499 on device "OVL_LTO-3_Drive-2"
(/dev/st0). ERR=Erreur d'entrée/sortie.
Error: Error writing final EOF to tape. This Volume may not be readable.
dev.c:1566 ioctl MTWEOF error on "OVL_LTO
Hello,
2012/11/19 Jacky Carimalo
> Le 19/11/2012 12:00, Alan Brown a écrit :
> > On 19/11/12 11:04, Jacky Carimalo wrote:
> >> Hello,
> >> I have the same problem.
> >> Bacula stopped filling a tape after 4 errors, as described below !
> >> I would like to be able to tell it to continue ...
> >
On 19/11/12 15:46, Jacky Carimalo wrote:
> update Volume={name} VolStatus=append
>
> but it then marked the volume Used, and not enabled for backup on it
> again, keeping its first data.
Bacula has decided the volume has been open too long.
This is set with Volume Use Duration and has no default
Le 19/11/2012 12:00, Alan Brown a écrit :
> On 19/11/12 11:04, Jacky Carimalo wrote:
>> Hello,
>> I have the same problem.
>> Bacula stopped filling a tape after 4 errors, as described below !
>> I would like to be able to tell it to continue ...
> update Volume={name} VolStatus=append
>
>
I did :
On 19/11/12 11:04, Jacky Carimalo wrote:
> Hello,
> I have the same problem.
> Bacula stopped filling a tape after 4 errors, as described below !
> I would like to be able to tell it to continue ...
update Volume={name} VolStatus=append
Hello,
I have the same problem.
Bacula stopped filling a tape after 4 errors, as described below !
I would like to be able to tell it to continue ...
Any idea ?
Jacky
*query
Choose a query (1-20): 16 (List Volumes likely to need replacement from
age or errors)
+---+---
Thanks John,
We've had these tapes fill up to 420GB in the past (to it's native size). I
have added some extra Messages to see if error becomes apparent. We have
multiple pools/multiple tapes (up to 50 tapes) they all are full on odd 300GB
now days. Tape drive configuration in bacula is unchang
> I am currently running a backup job of 1 large iso file and checking the logs
> to see what it could be. Perhaps an issue with software rather than hardware.
> We look after our drive well with cleans whenever asked by the machine. We
> have a EXABYTE Model: LTO 1x7 2U.
If it is software then
Thanks for your reply there John,
I am currently running a backup job of 1 large iso file and checking the logs
to see what it could be. Perhaps an issue with software rather than hardware.
We look after our drive well with cleans whenever asked by the machine. We have
a EXABYTE Model: LTO 1x7
On Thu, Nov 15, 2012 at 8:07 PM, UserMOP wrote:
> Hello,
>
> First time poster, love the community, been reading it for years but never
> had an issue worth posting, until today. :)
>
> Using Bacula Version: 5.0.1 (24 February 2010).
>
> Our brand new LTO3 tapes are filling up too quick. Tapes th
Hello,
First time poster, love the community, been reading it for years but never had
an issue worth posting, until today. :)
Using Bacula Version: 5.0.1 (24 February 2010).
Our brand new LTO3 tapes are filling up too quick. Tapes that normally take
420GB are full at 320GB. This is a major con
29 matches
Mail list logo
