Re: amanda fails

[Gene Heskett]

On Saturday 23 October 2021 05:03:23 Gene Heskett wrote:

> On Saturday 23 October 2021 04:52:41 Stefan G. Weichinger wrote:
> > Am 19.10.21 um 16:45 schrieb Charles Curley:
> > > On Tue, 19 Oct 2021 10:19:28 +0200
> > >
> > > "Stefan G. Weichinger"  wrote:
> > >> Switching the parameter "taperscan" from "lexical" to
> > >> "traditional" works around that now.
> > >
> > > I don't have taperscan in either of my configurations, so I guess
> > > I'm running on the default. The lack probably comes from more than
> > > a decade of copying in old configurations every time I install.
> >
> > That setup worked for a few days now with "traditional".
> >
> > Checked right now, holding disk full, dumps not taped again.
> >
> > amcheck did not find the next vtape, I assume the external USB drive
> > (= another chg-disk changer in my aggregate setup) has been plugged
> > in yesterday.
>
> But you don't know that for sure?  And is it automounted when it is
> plugged in? One of the things people do is forget...
>
> > Edited back to "lexical", amflush works now.
> >
> > A bit strange and not reliable, as it seems.

I should probably point out that ALL my problems with bad crc's of the 
holding disk files went away when I replaced the holding disk, which was 
apparently an SMR disk, with an SSD of 1/4 the size of the spinning rust 
disk.  And my backup times to get all 6 machines were sped up from 
around two hours to under 30 minutes. All by the non-SMR, SSD holding 
disk.  So at the very least, I can sure recommend an SSD as a holding 
disk.

It has been so successful and error free over the last 6 months, that I 
have installed, but not yet built for use, 4 1T samsung EVO-870 SSD's on 
another cheap non-raid controller, adding 6 more sata-III ports, which I 
intend to build a raid 10 out of, and use for the /home partition if and 
when I install debian 11. Probably when debian announces 11.3 as that 
should be time enough to fix any new bullseye version bugs.

Will that find something not compatible with amanda 3.5.1?

Copyright 2021 by Maurice E. Heskett
Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: amanda fails

[Olivier]

Gene Heskett  writes:

> I should probably point out that ALL my problems with bad crc's of the 
> holding disk files went away when I replaced the holding disk, which was 
> apparently an SMR disk, with an SSD of 1/4 the size of the spinning rust 
> disk.  And my backup times to get all 6 machines were sped up from 
> around two hours to under 30 minutes. All by the non-SMR, SSD holding 
> disk.  So at the very least, I can sure recommend an SSD as a holding 
> disk.

My 2 cents about using SSD for holding disk: over 15 years of running
amanda on hard disks, the only disk problem I ever had was with the
holding disk and the disk did get damaged in the holding disk area. It
seems that the holding disk function puts a tremendous usage on the disk
(especially with compression on the server I presume) to the point of
damaging a hard disk. I am wondering how an SSD will cope.

Best regards,

Olivier

Re: amanda fails

[Gene Heskett]

On Friday 12 November 2021 04:58:34 Olivier wrote:

> Gene Heskett  writes:
> > I should probably point out that ALL my problems with bad crc's of
> > the holding disk files went away when I replaced the holding disk,
> > which was apparently an SMR disk, with an SSD of 1/4 the size of the
> > spinning rust disk.  And my backup times to get all 6 machines were
> > sped up from around two hours to under 30 minutes. All by the
> > non-SMR, SSD holding disk.  So at the very least, I can sure
> > recommend an SSD as a holding disk.
>
> My 2 cents about using SSD for holding disk: over 15 years of running
> amanda on hard disks, the only disk problem I ever had was with the
> holding disk and the disk did get damaged in the holding disk area. It
> seems that the holding disk function puts a tremendous usage on the
> disk (especially with compression on the server I presume) to the
> point of damaging a hard disk. I am wondering how an SSD will cope.
>
Since the holding disk is empty at the end of a given run that had no 
errors, a hard drive will get beat up on the same area near the start of 
the disk. The SSD has 23+ hours to look things over and if needed, 
shuffle the data areas used all over its array. All while its 
essentially empty. Only 62k of 240 gigs is shown as used right now, and 
thats just the ext4 overheard.  Its empty now since thats all it does.
It will be a long time before the wear leveler can't find enough good 
sectors to do a backup. Since I'm 87, I expect it to outlast me.

> Best regards,
>
> Olivier



Copyright 2021 by Maurice E. Heskett
Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page