Issue All my websites go down for a few minutes on weekly full backup

[Daan Verbaan]

Hi All,

I have a Plesk Obsedian server with Strato, everything runs smoothly, except every week, when my weekly full backup runs, all websites go down for a few minutes (some multiple times). Incremental backups run just fine.

Backups are made localy and remote. I run the whole process with a very low priory and there is plenty of space on the server. Furthermore get this warning every week:

Not all the data from /var/www/*****/************* was backed up successfully:
/usr/lib64/plesk-9.0/sw-tar: Removing leading `/' from member names

Does anyone knows what is causing my websites going offline?

Thanks for helping!

 

[IgorG]

Issue - Backup warning : /usr/lib/plesk-9.0/sw-tar: Removing leading `/' from member names

Hello, I have this message everyday when performing automatic backup with Plesk : Not all the data from /var/www/vhosts/XXX was backed up successfully: /usr/lib/plesk-9.0/sw-tar: Removing leading `/' from member names I use Plesk Obsidian 18.0.37 with Ubuntu 20.04.3 LTS I found this...

talk.plesk.com

 

[Daan Verbaan]

Issue - Backup warning : /usr/lib/plesk-9.0/sw-tar: Removing leading `/' from member names

Hello, I have this message everyday when performing automatic backup with Plesk : Not all the data from /var/www/vhosts/XXX was backed up successfully: /usr/lib/plesk-9.0/sw-tar: Removing leading `/' from member names I use Plesk Obsidian 18.0.37 with Ubuntu 20.04.3 LTS I found this...

talk.plesk.com

Thank you @IgorG. I did see that post, but the main thing is that my websites go down while backing up. Could that also be cause by the folder structure?

 

[WebHostingAce]

This could be due to the lack of system memory.

Please explain "all websites go down". What is the error message do you see during this time?

 

[Daan Verbaan]

This could be due to the lack of system memory.

Please explain "all websites go down". What is the error message do you see during this time?

Hi thanks for responding. To honest I don't know what the error message is (I'm sleeping at the time ;-) ). I'm running some UptimeRobots though (service that checks whether your website is online) and it simply states that there is a connection timeout.

 

[Bitpalast]

Does the same happen when you disable compression in the backup setup?

 

[Daan Verbaan]

Does the same happen when you disable compression in the backup setup?

I don't know, but it's worth trying. I do have to wait a few days though, as my weekly full backup is due Fri-Sat night. Thanks

 

[Daan Verbaan]

Does the same happen when you disable compression in the backup setup?

So the weekly full backup ran last night and it was a nightmare. Normally it gives some hickups during the night, but now when I woke up around 8 AM, websites were still unstable (reachable / not reachable) and only a versy 1/3 of the backup ran. In the end I decided to stop the process.

 

[Bitpalast]

When compression is disabled, the CPU load is reduced dramatically and the overall "calcuations" on the server are lowed a big deal. The only thing that increases is the disk space usage and maybe transport time to an FTP storage space, but else disabling compression should actually speed up things and prevent overloading the server.

So if the same issue still exists or became even worse, you need to do at least two things:
1) Check your /var/log/messages file for CPU throttle messages. Are any cores throttled? You could seek like
# grep ottle /var/log/messages
2) Check your Linux process list for processes that use a lot of cpu time and slow your system down. For example
# ps aux | sort -nrk 3,3 | head -n 30
to see the top 30 processes sorted by cpu usage. What are the top ranking processes from this?

 

[Dave W]

Check diskspace aswell, the backups are created locally and then migrated. Though I thought that Plesk wouldnt run backups if the disk space wasnt there to create the backup.

 

[mow]

Though I thought that Plesk wouldnt run backups if the disk space wasnt there to create the backup.

It shouldn't start the backup, but then that initial check does not help if disk available space gets eaten by other tasks, e.g. excessive logging, while the backup runs.

Like Peter wrote, disabling compression should make the backup faster, not slower. Also check the CPU temperature (with e.g. `sensors`) and your storage (with `smartctl -a /dev/sda` and/or `nvme smart-log /dev/nvme0`).