Backup Funktion arbeitet nicht korrekt

[Manuel]

Hallo,
ich verwende das aktuelle keyHelp auf aktuellem Debian 8 und habe da mit der Backup Funktion ein Problem.

Ich habe 2 Benutzer Accounts, bei dem ersten habe ich angegeben, dass 4 Backups erstellt werden sollen im Remote Repository und bei dem zweiten Account habe ich 7 angegeben.
Jedoch gibt es ingesamt nur 4 Backups von jedem der zwei Accounts jeweils nur 2.

Edit:
Die Backups sind auch jedem anderen Benutzeraccount sichtbar, also auch die von andere Benutzer.
Das sollte man umgehend beheben und diesen Fix auch umgehend veröffentlichen, da es ein Sicherheitsrisiko der privaten Daten sein könnten.
Also nicht erst in einer neuen Version Veröffentlichung, so zu sagen ein Hotfix, den man üblicherweise sofort veröffentlicht.

[Martin]

Hallo,

bezieht sich Ihre Aussage auf das lokale oder ein von Ihnen angegebenes Remote Repository für die Backups?

Ich habe dies auf einem Testsystem versucht nachzustellen, im lokalen Repository abgelegte Backups sind hier aber korrekt nur jedem Benutzer selbst zugänglich. Eine entsprechende Sicherheitslücke in KeyHelp vermag ich hier daher nicht zu erkennen.

Sofern beide User natürlich ein und das selbe Remote Repository sehen, so ist es möglich hier alle dortigen Dateien zu sehen. Hierfür mussten aber die User die entsprechenden Repositorys mit den nötigen FTP/SFTP Zugangsdaten anlegen, über welche ebenfalls ein Zugriff auf alle dortigen Dateien möglich wäre.
Für sensible Daten besteht hier aber natürlich noch die Möglichkeit das Backuparchiv mit einem Passwort zu sichern. Da hier für die abschließende Kompression 7zip genutzt wird, so ist hierdurch das komplette Archiv AES256 verschlüsselt.

[Manuel]

Das betrifft ausschliesslich nur auf ein von mir angegebenes Remote Repository

[Martin]

Hallo,

wie geschrieben wäre dies normal, wenn hier überall das gleiche Repository angelegt wurde. Eine Unterscheidung ist hier nicht möglich.

Sofern die Backups administrativ erfolgen, so stünde hier auch die Backupfunktion des KeyHelp Administrators, welcher ein komplettes Backup (auch aller Benutzer) anfertigt, zur Verfügung.

[Manuel]

Ja gut aber, ich habe noch ein zweites Problem genannt.

In dem 1. Benutzeraccount habe ich maximal 4 Backups angegeben, in dem 2. Benutzeraccount habe ich maximal 7 Backups angegeben.
Also ingesamt 11 Backups sollten vorhanden sein, 4 von dem 1. Benutzeraccount und 7 von dem 2. Benutzeraccount. Es sind jedoch ingesamt nur 4.

[Martin]

Hallo,

bei Benutzerbackups sollten Sie hierzu in den "Panel-Aufgaben-Logs" pro Benutzerback eine Logdatei finden können. Sind hierzu entsprechende Informationen enthalten?

Speziell folgend Zeile wäre hier von Interesse:

[12-Dec-2016 17:43:02] DEBUG --> apply rotation - keep max. 2 file(s) in repository.

(Wobei hier die Anzahl der maximal eingestellten Backups stehen sollte)

[Manuel]

[12-Dec-2016 17:43:02] DEBUG --> apply rotation - keep max. 2 file(s) in repository.

Solche Zeile finde ich nicht vor ich finde ausschliesslich nur:

Benutzer 1:

Code: Select all

[12-Dec-2016 00:00:02] DEBUG --> start backup process, task id: "55"

[12-Dec-2016 00:00:02] DEBUG --> prepare processing dir

[12-Dec-2016 00:00:02] DEBUG --> write pid file

[12-Dec-2016 00:00:02] DEBUG --> check remote connection

[12-Dec-2016 00:00:03] DEBUG --> estimate disk space needed for this job

[12-Dec-2016 00:00:03] DEBUG --> write "allocated" file

[12-Dec-2016 00:00:03] DEBUG --> free: 2,579,224.05 MiB

[12-Dec-2016 00:00:03] DEBUG --> reserve: 140,393.06 MiB (5%)

[12-Dec-2016 00:00:03] DEBUG --> this backup task: 140,350.00 MiB

[12-Dec-2016 00:00:03] DEBUG --> all running backup tasks: 140,350.00 MiB

[12-Dec-2016 00:00:03] DEBUG --> generate archive directories

[12-Dec-2016 00:00:03] DEBUG --> backup type is "user"

[12-Dec-2016 00:00:03] DEBUG --> backup home directory

[12-Dec-2016 00:24:09] DEBUG --> backup user databases

[12-Dec-2016 00:24:09] DEBUG --> backup mail directories

[12-Dec-2016 00:24:09] DEBUG --> create one backup file

[12-Dec-2016 00:24:09] DEBUG --> file name is /backup/processing/task-55/user-server1-budachmanu-20161212002409.7z

[12-Dec-2016 00:24:09] DEBUG --> compressing file

[12-Dec-2016 04:33:51] DEBUG --> compressing done

[12-Dec-2016 04:43:32] DEBUG --> sha1 checksum: 3fb3f2ca10e4228bb29452cdc3771f363c80b5f1

[12-Dec-2016 04:43:32] DEBUG --> remove archive directory

[12-Dec-2016 04:43:32] INFO  --> perform rm -rf /backup/processing/task-55/archive/

[12-Dec-2016 04:43:35] INFO  --> move file to remote repository

[12-Dec-2016 04:43:35] DEBUG --> apply rotation

[12-Dec-2016 04:43:35] DEBUG --> delete file from remote "user-server1-budachman1-20161210000011.7z'

[12-Dec-2016 04:43:35] DEBUG --> delete file from remote "user-server1-budachmanu-20161210002451.7z'

[12-Dec-2016 05:00:01] DEBUG --> cleanup

[12-Dec-2016 05:00:01] INFO  --> perform rm -rf /backup/processing/task-55/

[12-Dec-2016 05:00:03] INFO  --> backup finished

Benutzer 2:

Code: Select all

[12-Dec-2016 00:00:03] DEBUG --> start backup process, task id: "56"

[12-Dec-2016 00:00:03] DEBUG --> prepare processing dir

[12-Dec-2016 00:00:03] DEBUG --> write pid file

[12-Dec-2016 00:00:03] DEBUG --> check remote connection

[12-Dec-2016 00:00:04] DEBUG --> estimate disk space needed for this job

[12-Dec-2016 00:00:04] DEBUG --> write "allocated" file

[12-Dec-2016 00:00:04] DEBUG --> free: 2,579,187.85 MiB

[12-Dec-2016 00:00:04] DEBUG --> reserve: 140,393.06 MiB (5%)

[12-Dec-2016 00:00:04] DEBUG --> this backup task: 57.75 MiB

[12-Dec-2016 00:00:04] DEBUG --> all running backup tasks: 140,407.75 MiB

[12-Dec-2016 00:00:04] DEBUG --> generate archive directories

[12-Dec-2016 00:00:04] DEBUG --> backup type is "user"

[12-Dec-2016 00:00:04] DEBUG --> backup home directory

[12-Dec-2016 00:00:11] DEBUG --> backup user databases

[12-Dec-2016 00:00:11] DEBUG --> backup mail directories

[12-Dec-2016 00:00:11] DEBUG --> create one backup file

[12-Dec-2016 00:00:11] DEBUG --> file name is /backup/processing/task-56/user-server1-budachman1-20161212000011.7z

[12-Dec-2016 00:00:11] DEBUG --> compressing file

[12-Dec-2016 00:00:13] DEBUG --> compressing done

[12-Dec-2016 00:00:13] DEBUG --> sha1 checksum: 59ded532ee5b65e7d29102a1f3c992047e8605e9

[12-Dec-2016 00:00:13] DEBUG --> remove archive directory

[12-Dec-2016 00:00:13] INFO  --> perform rm -rf /backup/processing/task-56/archive/

[12-Dec-2016 00:00:13] INFO  --> move file to remote repository

[12-Dec-2016 00:00:13] DEBUG --> apply rotation

[12-Dec-2016 00:00:13] DEBUG --> cleanup

[12-Dec-2016 00:00:13] INFO  --> perform rm -rf /backup/processing/task-56/

[12-Dec-2016 00:00:14] INFO  --> backup finished

[Martin]

Hallo,

im ersten Log ist zu entnehmen, dass hier die Rotation stattfindet.

Grundsätzlich kann KeyHelp bei einem Remote Repository nur die Anzahl der Backups bestimmen, somit begrenzt der Backupjob des ersten Users die Anzahl entsprechend seiner Einstellungen auf 4.

Sofern die selben Zugangsdaten genutzt werden, so sollten hier dann zumindest pro User entsprechend unterschiedliche Unterverzeichnisse für die Backups angelegt werden.

[passi]

Habe auch ein Anmerkung (ein Problem?) mit der Backupfunktion.
Die Backups dauern immer relativ lange. Ich habe gerade mal ein manuelles Backup gestartet und mir dabei "top" angeschaut:

Code: Select all

top - 16:50:01 up 13 days, 19:47,  1 user,  load average: 1,10, 0,62, 0,26
Tasks: 132 total,   3 running, 129 sleeping,   0 stopped,   0 zombie
%Cpu0  :  1,3 us,  7,0 sy, 73,2 ni, 16,4 id,  0,3 wa,  0,0 hi,  0,3 si,  1,3 st
%Cpu1  :  0,0 us,  0,3 sy, 28,4 ni, 70,2 id,  0,3 wa,  0,0 hi,  0,0 si,  0,7 st
KiB Mem:   6115044 total,  5938944 used,   176100 free,   230284 buffers
KiB Swap: 12578812 total,        0 used, 12578812 free.  4419924 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 9540 root      35  15  105256  13096   4300 R 100,4  0,2   0:07.34 7z
   35 root      20   0       0      0      0 S   0,7  0,0   0:54.22 kswapd0
 1248 root      20   0  790140  13988   6056 S   0,7  0,2  10:59.54 fail2ban-s+
21509 root      20   0       0      0      0 R   0,7  0,0   1:13.66 kworker/0:0
    1 root      20   0   28920   5204   3116 S   0,3  0,1   3:05.31 systemd
  439 root      20   0   49748  16340  13924 S   0,3  0,3   2:23.26 systemd-jo+
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.49 kthreadd
    3 root      20   0       0      0      0 S   0,0  0,0   0:06.76 ksoftirqd/0
    5 root       0 -20       0      0      0 S   0,0  0,0   0:00.00 kworker/0:+
    7 root      20   0       0      0      0 S   0,0  0,0   9:20.09 rcu_sched
    8 root      20   0       0      0      0 S   0,0  0,0   0:00.00 rcu_bh
    9 root      rt   0       0      0      0 S   0,0  0,0   0:03.50 migration/0
   10 root       0 -20       0      0      0 S   0,0  0,0   0:00.00 lru-add-dr+
   11 root      rt   0       0      0      0 S   0,0  0,0   0:03.94 watchdog/0
   12 root      20   0       0      0      0 S   0,0  0,0   0:00.00 cpuhp/0
   13 root      20   0       0      0      0 S   0,0  0,0   0:00.00 cpuhp/1

Warum werden die beiden CPU Kerne nicht mehr ausgelastet?

Vielen Dank

[nikko]

Hallo,
weshalb ein Backup sehr lange dauern kann, kann verschiedenste Ursachen haben.

Code: Select all

top - 16:50:01 up 13 days, 19:47,  1 user,  load average: 1,10, 0,62, 0,26
Tasks: 132 total,   3 running, 129 sleeping,   0 stopped,   0 zombie
%Cpu0  :  1,3 us,  7,0 sy, 73,2 ni, 16,4 id,  0,3 wa,  0,0 hi,  0,3 si,  1,3 st
%Cpu1  :  0,0 us,  0,3 sy, 28,4 ni, 70,2 id,  0,3 wa,  0,0 hi,  0,0 si,  0,7 st
KiB Mem:   6115044 total,  5938944 used,   176100 free,   230284 buffers
KiB Swap: 12578812 total,        0 used, 12578812 free.  4419924 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 9540 root      35  15  105256  13096   4300 R 100,4  0,2   0:07.34 7z
   35 root      20   0       0      0      0 S   0,7  0,0   0:54.22 kswapd0
 1248 root      20   0  790140  13988   6056 S   0,7  0,2  10:59.54 fail2ban-s+
21509 root      20   0       0      0      0 R   0,7  0,0   1:13.66 kworker/0:0
    1 root      20   0   28920   5204   3116 S   0,3  0,1   3:05.31 systemd
  439 root      20   0   49748  16340  13924 S   0,3  0,3   2:23.26 systemd-jo+
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.49 kthreadd
    3 root      20   0       0      0      0 S   0,0  0,0   0:06.76 ksoftirqd/0
    5 root       0 -20       0      0      0 S   0,0  0,0   0:00.00 kworker/0:+
    7 root      20   0       0      0      0 S   0,0  0,0   9:20.09 rcu_sched
    8 root      20   0       0      0      0 S   0,0  0,0   0:00.00 rcu_bh
    9 root      rt   0       0      0      0 S   0,0  0,0   0:03.50 migration/0
   10 root       0 -20       0      0      0 S   0,0  0,0   0:00.00 lru-add-dr+
   11 root      rt   0       0      0      0 S   0,0  0,0   0:03.94 watchdog/0
   12 root      20   0       0      0      0 S   0,0  0,0   0:00.00 cpuhp/0
   13 root      20   0       0      0      0 S   0,0  0,0   0:00.00 cpuhp/1

Lass uns kurz dein "top" zerlegen. Dein Server läuft mit ca. 55% Serverlast ( 110 loadaverage : 2 Kerne) wobei Kern 1 die höhere Last hat.
Kern 1 = CPU 0:
us: 1,3 - CPU-Nutzung von User-Prozessen
sy: 7,0 - CPU-Nutzung von System- und Kernel-Prozessen
ni: 73,2 - CPU-Nutzung von Prozessen, die keine Standard-Priorität besitzen
id: 16,4 - CPU im Leerlauf
wa: 0,3 - Zeit, welche die CPU durch I/O Zugriffe (bsp. Festplatte) warten muss
hi: 0,0 - Hardwareinterrrupts
si: 0,3 - Softwareinterrupts
st: 1,3 - stolen time (Zeit, die der physikalische Server anders vergibt, obwohl sie deiner virtuellen Maschine zugeordnet ist)

Wobei wir dann schon zum nächsten kommen: Du hast virtuelle CPU-Kerne und der Hypervisor bevorzugt einen anderen virtuellen Prozessor.
Zumal bei virtuellen CPU-Kernen nie die an dich vergebene Leistung bekannt ist, diese kann 90%, 80%, 70% eines physikalischen Kerns sein,
da der Rest für den Masternode reserviert ist.

Zum Prozess selbst:
PID: Prozess-ID 9540
USER: Der Benutzer, unter dessen Kennung der Prozess läuft bzw. gestartet wurde
PR: 35 - dynamische Priorität
NI: 15 - mit welcher Priorität der Prozess gestartet wurde
VIRT: 105256 - Virtueller Speicherverbrauch
RES: 13096 - Speicherverbrauch (RAM) des Prozesses (ohne Auslagerung)
SHR: 4300 - Der Speicher des virtuellen Speichers, der geshared werden kann
S: R - Prozess Status
%CPU: 100,4 - Prozentualer Zeitanteil der CPU für den Prozess
%MEM: 0,2 - Prozentualer Anteil des RAMs für den Prozess
TIME+: 7,34 - Die Gesamtzeit,die die CPU dem Prozess gewidmet hat

Alle Werte nahezu im grünen Bereich: Summasumarum gehts hier einfach nicht schneller.

Wäre z.B. die HDD zu langsam, würden sich die loadaverage erhöhen, bei wenig %us und hohem %wa, wobei der %wa Grenzwert mit der Faustformel 1/Prozessorkerne errechnen lässt. Wäre zu wenig RAM, würde sich dein swap-used Wert erhöhen, membuffers und memcached hingegen gegen 0 gehen, sowie ein höherer %wa Wert vorliegen, bei gleichzeitig hohem Load-Average.

LG nikko

[passi]

Ah ok..

Vielen Dank für die ausführliche Erklärung!

Gruß

[Martin]

Hallo,

Anmerkung hierzu, da es den Hinweis auch schon einmal in einem anderen Ticket gab, mit dem kommenden Update wird sich dann die Kompressionstufe des 7z Prozesses auch in KeyHelp einstellen lassen (bis hin zu "nur packen, ohne Kompression").

[MaisKolben]

Das hört sich gut an. Wann kann man mit dem Update rechnen? Ich meine etwas gelesen zu haben, dass es bereits schon letzte Woche erscheinen sollte. Ich entschuldige mich übrigens für meine Ungeduld.

Gibt es evtl. ein Update-Statuslog (möglicher Release Zeitraum) von dem ich nichts weiß? Sollte noch keines existieren, könnte man ein solches nicht vllt. den Interessenten hier anbieten. Selbstverständlich mit der Erwähnung, dass jegliche Daten unverbindlich sind.

Mit freundlichen Grüßen,
Mais

[racmo]

Im Changelog stehen bereits die Dinge die mit der neuen Version kommen
https://www.keyhelp.de/changelog/

Wie man dort auch sieht ist der Termin wohl bald: (very soon) March 2017

[b0snaX]

[...]Sollte noch keines existieren, könnte man ein solches nicht vllt. den Interessenten hier anbieten. Selbstverständlich mit der Erwähnung, dass jegliche Daten unverbindlich sind.

Erlich gesagt so unverbindliche Zusagen in der form es kommt am 25.03.2017 und aus technischen Gründen dauert es eben doch länger dann finden sich immer wieder paar leute die dann sagen: "Aber es war doch zugesagt fur den ..." davon halte ich wenig. Wenn das Update bereit ist dann ist es da. Ich denke mal aus eben dem gennanten Grund machen die Dev's keine Unverbindlichen erklärungen.