Ultimate Backup macht NACH der Sicherung den Server zu 25% dicht.

[Scirocco3]

Hi,

ich habe seit einiger Zeit das Problem das auf der NAS der Dienst SYSLOG-NG immer 25% CPU braucht.
Nach einigem schauen hab ich in der CPU Anzeige mal auf einen Tag geschaut und siehe da...
Wenn ich den Server neu starte ist die Last normal, und nachdem der Backup dann durch ist (Zeitgesteuert) ist das Problem dann da.

Zuerst war der Backup Nachts um 00:00 ? wie in der Hardcopy zu sehen, springt da die CPU Last hoch.
Dann hab ich den Server heute mal neu gestartet und den Backup auf 14 ? terminiert.
Und siehe da... Nach 14 ? ist dann der SYSLOG-NG wieder am rödeln und die Last 25% von diesem Dienst.

Ich habe keinerlei Login aktiviert so das ich nicht verstehe was der Dienst nach dem Backup noch so macht?
Hab keine Lust jeden Tag nach dem Backup den Server neu zu starten, hoffe es hat jemand (Der Entwickler ist ja auch hier) eine Idee ??

Hardware siehe Sig, Sicherung auf 2 externe USB 3.0 Platten.

Besten Dank für die Tips

Greets Steffen

Datensicherungs-Ziel : /volumeUSB1/usbshare/BackupDS916 (/) [ $target ]
Key-File der Zielordnerverschlüsselung : [ $keyfile ]
Anzahl Wiederholungen bei einem Fehler : 3 [ $repeat_max ]
Wartezeit in Sek. für Wiederholung : 60 [ $repeat_sleep ]
Die Quell und Zielordner... : werden nicht synchronisiert [ $sync ]
Das Sicherungs-Ziel befindet sich... : am Speicherort des rsync-Scripts [ $nottoscript ]
Hostnamen im Sicherungsziel verwenden : Nein [ $hostname ]
Versionierung : Ja [ $version ]
Anzahl der Versionen (2-1000) : 90 [ $max_version ]
Snapshot erstellen : Nein [ $snapshot ]
Snapshot verstecken : Nein [ $snapshot_hide ]
Snapshot sperren : Nein [ $snapshot_lock ]
Ext. Datenträger automatisch starten : Nein [ $autorun ]
Ext. Datenträger automatisch auswerfen : Nein [ $autorun_unmount ]
Umgang mit verschlüsselten Ordnern : es wird nichts getrennt [ $unmount ]
SSH-Benutzername : [ $ssh_user ]
IP-, Host- oder Domain des Quellservers : [ $ssh_from ]
IP-, Host- oder Domain des Zielservers : [ $ssh_to ]
Abweichender SSH-Port : [ $ssh_port ]
Abweichender rsync-Port : [ $rsync_port ]
MAC-Adresse falls WOL gewünscht : [ $mac ]
WOL Wartezeit in Sekunden : [ $sleep ]
Lokalen Server nach der Sicherung : nicht runterfahren [ $shutdown_local ]
Entfernten Server nach der Sicherung : nicht runterfahren [ $shutdown_remote ]
E-Mail Adresse : xxxx@xxxx.com [ $email ]
E-Mail Betreff : [ $emailsubject ]
Zustellungsart des rsync-Protokolls : rsync-Protokoll nur bei Problemen senden [ $emailfail ]
Benachrichtigung über Systemmeldungen : DSM Benachrichtigung [ $notify ]
Zustellungsart der Benachrichtigungen : Nachricht immer senden [ $notifyfail ]
Pushbullet Access Token (API) : [ $api ]
Pushbullet Device-ID : [ $device_id ]
Optische und akustische Signalausgabe : Ein [ $signal ]
DSM-Systemkonfiguration sichern (.dss) : Ja [ $dsm_export ]
@Recycle, löschen wenn älter als (Tage) : 90 [ $recycle_rotate ]
@Logfile, löschen wenn älter als (Tage) : 90 [ $logfiles_rotate ]
@DSMConfig, löschen wenn älter als (Tage) : 90 [ $dsmconfig_rotate ]

» rsync-Spezifische Einstellungen
(Hinweis: Bis auf den Optionsschalter [ $syncopt ] können nachfolgende Angaben nur innerhalb des rsync-Scriptes geändert werden.)
rsync-Optionsschalter -ahR [ $syncopt ]
Reportverhalten --stats [ $logstat ]
Ausschlussverhalten --delete-excluded --exclude=@eaDir/*** --exclude=@Logfiles/*** --exclude=#recycle/*** --exclude=#snapshot/*** --exclude=.DS_Store/*** [ $exclude ]
Lösch- und Sicherungsverhalten --delete --backup --backup-dir=@Recycle/2018-08-11_21h28m56s_Backup_DS916_8TB [ $recycle ]

 

[PsychoHH]

Würde das ganze mal ohne Angabe von Email probieren.

 

[Scirocco3]

Okay.. Mach ich mal... Ich berichte

*Update*
Also ich hab beide Jobs geändert. Den einen dann noch mal per Hand gestartet und der 2te lief kurz drauf per Scheduler.
Nach Ende beider Jobs ist die CPU Last wieder normal. Scheinbar lags es an der Mail.

Besten Dank für den Tipp. Aber "normal" ist das wohl eher nicht