Re: holding disk too small?

[Uwe Menges]

On 2019-12-05 06:00, Gene Heskett wrote:
> Lesson #2, I just learned today that the raspbian AND debian buster 10.2
> versions have NO inetd or xinetd. Ditto for RH.

I think that's along with other stuff moving to systemd.
On Fedora 30, I have

# systemctl status amanda.socket
● amanda.socket - Amanda Activation Socket
   Loaded: loaded (/usr/lib/systemd/system/amanda.socket; enabled;
vendor preset: disabled)
   Active: active (listening) since Sat 2019-11-30 14:46:46 CET; 4 days ago
   Listen: [::]:10080 (Stream)
 Accepted: 0; Connected: 0;
Tasks: 0 (limit: 4915)
   Memory: 0B
   CGroup: /system.slice/amanda.socket

Nov 30 14:46:46 lima systemd[1]: Listening on Amanda Activation Socket.

# systemctl cat amanda.socket
# /usr/lib/systemd/system/amanda.socket
[Unit]
Description=Amanda Activation Socket

[Socket]
ListenStream=10080
Accept=true

[Install]
WantedBy=sockets.target


Yours, Uwe

Re: holding disk too small?

[Gene Heskett]

On Tuesday 03 December 2019 20:23:04 Olivier wrote:

> "Stefan G. Weichinger"  writes:
> > So far it works but maybe not optimal. I consider recreating that
> > holding disk array (currently RAID1 of 2 disks) as RAID0 ..
>
> Unless your backups are super critical, you may not need RAID 1 for
> holding disk. Also consider that holding dick puts a lot of mechanical
> stress on the disk: I have seen at least one case where the disk did
> start failing and developing bad blocks in the holding disk space
> while the rest of the disk was OK.
>
> Best regards,
>
> Olivier

Lesson #1: Never ever put the holding disk area on the backup disk 
holding the vtapes, it just pounds the seek mechanism of that drive 
leading to a potential early failure. I've always put it on the main 
drive, but that then subjects the main drive to the same abuse only when 
backing up the main drive, and I'm supposedly backing up 4 other 
machines too. TBT I will have a drive that is not in current use when 
the new machine is built, and which may well be an even better solution. 
Set up that way should also be a measurable speed improvement.

Lesson #2, I just learned today that the raspbian AND debian buster 10.2 
versions have NO inetd or xinetd. Ditto for RH.

So that probably explains why I can install the clients and configure 
them to be backed up, except the clients crash about 3 seconds after the 
server first accesses that client, leaving NO clues in the logs of the 
crashed machines. I've had it happen to an armbian jessie install on a 
rock64, an rpi3 with a 64 bit debian buster install, and I expect it 
will be the same should I try to backup the raspbian armhf install on 
the rpi4.

This machine I pulled out of the midden heap in the garage so I at least 
had email, is so crippled I've turned amanda off until I can get a new 
machine built and this boot drive moved to it. Got the cpu today, might 
have the rest of it tomorrow.  The tower has smoke stains from the fire 
but that won't hurt it a bit.

Anyway, we've got to figure out what to do about the missing #inetd 
stuffs or its all going to die as folks update. 

Copyright 2019 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page