License Warning

[24unix]

Ich bekomme seit 2 tagen diese Mail:

Hello keyhelpadmin!

The following problems occurred while updating your KeyHelp Professional license on server vader.24unix.net.

------------------------
Failed to decrypt the license file.
Please request the license again via the license management.
------------------------

Best regards,
Your support team


---
This message was generated automatically.
Please do not reply to this email.

Im Panel sieht aber alles OK aus:

Das einzige was ich geändert habe, war den Support Access zu deaktivieren, weil der ja nicht einfach so offen sein muss.

[Alexander]

Hallo,

Die Lizenz wird in 2 Fällen mit dem Lizenzserver abgeglichen. Zum Einen, täglich zu einer festgelegten Zeit anhand deines Hostnamens errechnet, zum Anderen nach einem Neustart. Anhand der Logs auf dem Lizenzserver konnte ich sehen, das du deinen Server häufig neu gestartet hast.
Ggf. läuft die Prüfung schon, aber dein Server ist noch nicht 100%ig wieder oben und hat dort ggf. Probleme mit dem encoder der Datei.

Wie häufig (Anzahl pro Tag) hast du die Mail den bereits bekommen?

[24unix]

Hallo,

Die Lizenz wird in 2 Fällen mit dem Lizenzserver abgeglichen. Zum Einen, täglich zu einer festgelegten Zeit anhand deines Hostnamens errechnet, zum Anderen nach einem Neustart. Anhand der Logs auf dem Lizenzserver konnte ich sehen, das du deinen Server recht häufig neu startest.

Ja, leider. Restic zickt. Heute Morgen war er wieder bei einer Load von über 25 (16 Kerne).
Ich habe dann Häppchenweise nur das CP, System Configuration und dann User Accounts gesichert.

Damit ist er gerade zugange, 56% von knapp 700GB.

Ggf. läuft die Prüfung schon, aber dein Server ist noch nicht 100%ig wieder oben und hat dort ggf. Probleme mit dem encoder der Datei.

Wenn er täglich prüft ist das nachvollziehbar. Heute Nacht war die Last so hoch, selbst die Cronjobs stiegen aus: /bin/sh: 1: Cannot fork

Wie häufig (Anzahl pro Tag) hast du die Mail den bereits bekommen?

Deckt sich wohl ungefähr mit den Neustarts, also wohl weiter kein Problem.

[Alexander]

Du kannst mal "restic self-update" ausführen. Es gab ein Restic Update auf 0.13.0 (https://github.com/restic/restic/blob/m ... ANGELOG.md). Habe die Kompatibilität mit KeyHelp vor ein paar Tagen überprüft, und musste keine Änderungen vornehmen, läuft also auch mit KeyHelp 22.0.

Ggf. schafft es ja bei dir Abhilfe.

[24unix]

Du kannst mal "restic self-update" ausführen. Es gab ein Restic Update auf 0.13.0 (https://github.com/restic/restic/blob/m ... ANGELOG.md). Habe die Kompatibilität mit KeyHelp vor ein paar Tagen überprüft, und musste keine Änderungen vornehmen, läuft also auch mit KeyHelp 22.0.

Ggf. schafft es ja bei dir Abhilfe.

Danke, werde ich probieren, wenn das aktuelle Backup durch ist. Liegt jetzt bei 66%, also 10% seit dem letzten Beitrag, Gegenstelle ist mein Server@home mit 200/100 Anbindung. Sollte es an der Anbindung liegen könnte ich für kleines Geld auch auf 1000/500 gehen.

[24unix]

Ok, habe das Update gefahren, dann neues Backup, Last pendelte so um 10, mal drunter, mal drüber, aber die Kiste war nicht mehr so träge.

Sollte gehen, wenn man bedenkt, dass das Backup nachts läuft und ja nicht immer alles neu gesichert werden muss.

[24unix]

So ganz ist das Problem noch nicht weg.
Backup lief heute Nacht wieder 03:30 bis 8:10, erscheint mir lang, dafür, dass es ja nur differentiell sein sollte.

Und die Kiste hatte wohl wieder einen zu hohen Verbrauch.
Ich bekam u.A. von Matomo mails, dass Cron-Job nicht forken konnten.

Postfix kränkelte auch:

Code: Select all

Apr  9 02:26:18 h2967204 postfix/smtpd[438500]: warning: connect to private/anvil: Connection refused
Apr  9 02:26:18 h2967204 postfix/smtpd[441558]: warning: connect to private/anvil: Connection refused
Apr  9 02:26:18 h2967204 postfix/smtpd[435060]: warning: connect to private/anvil: Connection refused
Apr  9 02:26:18 h2967204 postfix/smtpd[443893]: warning: connect to private/anvil: Connection refused

Da ist wohl ein Dienst ausgestiegen …

Und das war das letzte Lebenszeichen:

Code: Select all

Apr  9 02:26:18 h2967204 postfix/smtpd[441558]: disconnect from unknown[188.166.26.85] commands=0/0
Apr  9 02:26:18 h2967204 postfix/smtpd[443893]: disconnect from unknown[164.92.224.81] commands=0/0

Musste Postfix dann heute Morgen manuell neustarten.

Wenn ich das richtig sehe, läuft restic schon mit einem nice Wert von 10, aber die Subprozesse nicht?

[24unix]

Heut eiweder das selbe, eMail mit:

Code: Select all

/bin/bash: fork: retry: Resource temporarily unavailable
/bin/bash: fork: retry: Resource temporarily unavailable
/bin/bash: fork: retry: Resource temporarily unavailable

Postfix hat wieder die Grätsche gemacht.

Aufgrund der Dauer des backups vermute ich, dass jeden tag eine komplette Sicherung gemacht wird.
Ist das nicht sehr ineffizient?
Auch wieder mehrere Warnungen, dass die Lizenz nicht überprüft werden konnt, der Lizenzserver nicht erreichbar ist, ich vermute, dass das ursächlich zusammenhängt. Aso wenn die Kiste überlastet kappt auch die Lizenzprüfung nicht.
Ich werde das Backup heute Nacht mal aussetzen.

[ShortSnow]

Hast Du sehr viel Mailspeicher belegt? Der wird nicht so effektiv gepackt wie Webspeicher.

Ein reiner Mailserver mit ca. 100GB braucht bei mir ca. 2:30h jedes Backup. Eine Webserver mit 120 GB. Ab dem 2. Backup nur 20 Minuten.

Gruß Arne

[24unix]

Hast Du sehr viel Mailspeicher belegt? Der wird nicht so effektiv gepackt wie Webspeicher.

Code: Select all

 du -h /var/mail/vhosts
[..]
28G	/var/mail/vhosts

Ist das viel? ich finde nicht.

Ein reiner Mailserver mit ca. 100GB braucht bei mir ca. 2:30h jedes Backup. Eine Webserver mit 120 GB. Ab dem 2. Backup nur 20 Minuten.

Irgendwie sehe ich nicht, dass das 2. Backup schneller gehen würde:

Irgendwie hat es eher noch länger gedauert.

Backup-Server ist mit FTTH 200/100 angebunden, kann man aber für kleines Geld noch schneller machen.

[Alexander]

Du kannst den Vorgang einmal überwacht laufen lassen.

Zuerst ID des Repos bekommen (Datenbank: backup_repositories), dann über KeyHelp einen Backup Vorgang starten und dann musst du schneller sein, bevor der Backup-Job selbst zur nächsten vollen Minute zuschlägt.

Code: Select all

php /home/keyhelp/www/keyhelp/cronjob/on_demand/backup.php --repo-id <ID>

Zuerst läuft die Vorbereitung, da werden die Postfächer entsprechend vorbereitet, das könnte etwas länger dauern. Dieser Teil profitiert nicht von der Inkrementellen Speicherung. Prozentzahlen werden in der KeyHelp UI angezeigt. Sollte bei 28GB wahrscheinlich nicht länger als 30-45 min dauern.

Kannst auch hier sehen, wie es langsam anwächst.
/backup-keyhelp/<USER>/<UNIQUE-NAME>/__email_accounts__

Anschließend läuft das Backup zum Remote. Prozentwerte werden in UI und CLI angezeigt.

[24unix]

Du kannst den Vorgang einmal überwacht laufen lassen.

OK, werde ich mal probieren.

Heute, ohne Backup, lief der Server wie erwartet normal durch, keine Lizenzwarnung, kein toter Postfix.

[24unix]

Gestern eine "Lite-Version" probiert.

Ohne Verzeichnisse, nur DB und Accounts.

Wieder die Lizenz-Warnung, Postfix ausgestiegen und das:

Hello keyhelpadmin!

A backup operation has finished with the following status: ERROR

Server: vader.24unix.net
Backup type: Server backup
Repository: vader.24unix.net (SFTP)

Description: The backup operation has been canceled due to fatal errors.

Logged messages:
------------------------
Failed to create backup: sh: 1: Cannot fork
------------------------

Best regards,
Your support team


---
This message was generated automatically.
Please do not reply to this email.

Ich werde jetzt erst mal die Finger davon lasssen und die Kiste wie gewohnt von aussen sichern.

[24unix]

OK, neue Erfahrung, es liegt höchstwahrscheinlich nicht an KeyHelp oder restic.

Ich hatte KH Backup deaktiviert, und ein beherztes rsync -avhuz auf meinem NAS angeschmissen, mich dann um andere Sachen gekümmert.
Wollte gerade was im Panel schauen, Gateway Timeout.

Systemload von 45. Schnell den rsync gestoppt, dann hat die Kiste sich wieder gefangen.

Also da stimmt was mit dem vServer nicht. Ich bin von BareMetal mit Xen und uraltem Xeon auf einen vServer mit 16 epic-Kernel und 40GB RAM bei Strato.

Und die Kiste scheint kein bisschen lastfest zu sein.

Stro habe ich gewählt, weil günstig und laut einiger Seiten gute Performance. Hmm.

[Jolinar]

Stro habe ich gewählt, weil günstig und laut einiger Seiten gute Performance. Hmm.

Wenn du noch nicht allzu sehr mit dem "Geiz ist geil"-Virus infiziert bist, würde ich dir evtl. einen Anbieterwechsel vorschlagen...Ich kenne da einen guten Anbieter, fängt mit "k" an und hört mit "eyweb" auf