Over the last weeks I fiddle with an installation with the following
behavior:
The amanda server is an older gentoo linux box and runs amanda-3.4.5r1
(gentoo package number).
The reason I keep this older version is that I have to talk to an amanda
client which is way older -> a VM with ancient
Am 12.05.20 um 08:34 schrieb Stefan G. Weichinger:
> backups run to a LTO3 tape (remember, 400 GB uncompressed space per
> definition)
I ran amtapetpye and only get half of the expected capacity!
why that ...
$ amtapetype -t LTO3_2020 -f /dev/nst0
Checking for FSF_AFTER_FILEMARK requirement
A
Am 12.05.20 um 14:10 schrieb Stefan G. Weichinger:
> Maybe they bought LTO2 tapes, I check that asap.
No, the tapes are OK.
HP LTO3 C7973A
I googled some stinit.def and set:
# cat /etc/stinit.def
# HP StorageWorks Ultrium 960/920 SAS LTO-3
manufacturer="HP" model = "Ultrium 3-SCSI" {
scsi2logi
Retried amtatpetype with another new tape yesterday.
No success.
Labelled and tested with 64k blocksize, still about 200 GB size only.
Could the older kernel somehow play a role here?
The output of amtapetype says:
"LEOM is not supported for this drive and kernel"
I try to set "LEOM false"
Am 13.05.20 um 09:03 schrieb Stefan G. Weichinger:
> It looks like a LTO2 tape ... although the customer told me it says LTO3
> on the cartridge (and has a correct product number).
>
> mt status detects it as density=0x44 as well, but the capacity and speed
> looks like LTO2.
>
> Strange.
Some
Now look at this run of
"amtapetype -b 128k /dev/nst0"
with another tape, FUJI instead of HP:
define tapetype LTO3-fuji {
comment "Created by amtapetype; compression disabled"
length 284180096 kbytes
filemark 20803 kbytes
speed 38376 kps
blocksize 128 kbyt
> On May 13, 2020, at 11:17 AM, Stefan G. Weichinger wrote:
>
> Now look at this run of
>
> "amtapetype -b 128k /dev/nst0"
>
> with another tape, FUJI instead of HP:
>
> define tapetype LTO3-fuji {
>comment "Created by amtapetype; compression disabled"
>length 284180096 kbyte
On Wed, May 13, 2020 at 06:17:02PM +0200, Stefan G. Weichinger wrote:
> Now look at this run of
>
> "amtapetype -b 128k /dev/nst0"
>
> with another tape, FUJI instead of HP:
>
> define tapetype LTO3-fuji {
> comment "Created by amtapetype; compression disabled"
> length 284180096
Am 14.05.20 um 07:32 schrieb Jon LaBadie:
> I wasn't sure what LEOM was. I assume it is "Logical End of Media".
Seems like, yes. I still haven't figured out how to set that, the
"device_property" line wasn't accepted by Amanda.
> Anyway I came across two references that said need for cleaning
>
Am 14.05.20 um 07:59 schrieb Jens Berg:
> There was a discussion back in 2014 with subject "Backups to tape
> consistently under 60% tape capacity". I haven't read the whole lengthy
> thread but one participant mentioned that in his case a bad cleaning
> tape was found to be responsible for the cap
On Thursday 14 May 2020 01:32:05 Jon LaBadie wrote:
> On Wed, May 13, 2020 at 06:17:02PM +0200, Stefan G. Weichinger wrote:
> > Now look at this run of
> >
> > "amtapetype -b 128k /dev/nst0"
> >
> > with another tape, FUJI instead of HP:
> >
> > define tapetype LTO3-fuji {
> > comment "Cre
On Thu, May 14, 2020 at 09:14:17AM +0200, Stefan G. Weichinger wrote:
> Am 14.05.20 um 07:59 schrieb Jens Berg:
> > There was a discussion back in 2014 with subject "Backups to tape
> > consistently under 60% tape capacity". I haven't read the whole lengthy
> > thread but one participant mentioned
On Thu, May 14, 2020 at 09:14:17 +0200, Stefan G. Weichinger wrote:
> Interesting, how can a "dirty" drive trigger this behavior?
>
> I'd expect failures all along and not after ~200 or 300 GB written.
>
> I don't see any interrupted writing or so (until that End Of Tape).
(We switched to disk-
Glad you brought up this "feature" Nathan. I had heard it before
but not using tape, promptly forgot it.
Jon
On Thu, May 14, 2020 at 05:30:53PM -0400, Nathan Stratton Treadway wrote:
> On Thu, May 14, 2020 at 09:14:17 +0200, Stefan G. Weichinger wrote:
> > Interesting, how can a "dirty" drive t
On Thursday 14 May 2020 17:30:53 Nathan Stratton Treadway wrote:
> On Thu, May 14, 2020 at 09:14:17 +0200, Stefan G. Weichinger wrote:
> > Interesting, how can a "dirty" drive trigger this behavior?
> >
> > I'd expect failures all along and not after ~200 or 300 GB written.
> >
> > I don't see any
There was a discussion back in 2014 with subject "Backups to tape
consistently under 60% tape capacity". I haven't read the whole lengthy
thread but one participant mentioned that in his case a bad cleaning
tape was found to be responsible for the capacity loss. Others reported
that they had tr
Am 13.05.20 um 18:17 schrieb Stefan G. Weichinger:
> Now look at this run of
>
> "amtapetype -b 128k /dev/nst0"
>
> with another tape, FUJI instead of HP:
>
> define tapetype LTO3-fuji {
> comment "Created by amtapetype; compression disabled"
> length 284180096 kbytes
> f
On Fri, May 15, 2020 at 10:59:49 +0200, Stefan G. Weichinger wrote:
> I am gonna restore as well just to check if there are hidden write
> errors (doesn't look like that to me so far ...)
That reminded me that (at least on our Ubuntu Linux system) the
smartmontools package's "smartctl" let us rea
Hi!
Am 15.05.20 um 13:33 schrieb Nathan Stratton Treadway:
> On Fri, May 15, 2020 at 10:59:49 +0200, Stefan G. Weichinger wrote:
>> I am gonna restore as well just to check if there are hidden write
>> errors (doesn't look like that to me so far ...)
>
>
> That reminded me that (at least on our
Am 15.05.20 um 13:59 schrieb Andreas Haumer:
> I think this was not mentioned on this thread yet, but
> there is also the HPE Library & Tape Tools utility ("ltt"),
> which allows to test many aspects of a tape drive.
> This software runs fine under Linux and can be used with tape
> drives of other
Am 15.05.20 um 13:33 schrieb Nathan Stratton Treadway:
> On Fri, May 15, 2020 at 10:59:49 +0200, Stefan G. Weichinger wrote:
>> I am gonna restore as well just to check if there are hidden write
>> errors (doesn't look like that to me so far ...)
>
>
> That reminded me that (at least on our Ubunt
21 matches
Mail list logo
