Search results

https://support.plesk.com/hc/en-us/articles/12388090147095-How-to-get-support-directly-from-Plesk

I suggest to contact Plesk support on it, because it is not the expected behavior.

Set to forbidden. Just to make sure that file permissions and internal permissions are updated.

It seems that your operating system is using a special source, because "tuxcare" is not the official Centos 7 repository. I suggest posting your question to the Issues · plesk/centos2alma page so that a developer can respond to it.

The nature of a chrooted environment is that it must not be possible to breakout of the chrooted jail. Especially not via FTP or SFTP. I suggest disabling SSH access and in a second step re-enabling it with the chrooted option. If you are still able to breakout afterwards, please contact Plesk...

Yes, probably the user clicked on the icon at least once.

I've tested this and it is working here. I did a test-backup to a remote FTP storage location and a restore of that backup. Both have worked. Thank you! Now let's hope it also works for the full server backup and increments.

Easy to to: Click the "Domains" menu and let it sort by traffic.

You mentioned 2 TB/day, but this traffic is only 14 GB/month.

In ticket 95402670 I asked support to provide a method to manually tar the locally generated backups so that we can manually upload them to an external storage. The command provided works so far that it creates the .tar file including all the backup content. But it fails at the end with the same...

And do the 17 source IP make sense? And why are there only 17? There should be hundreds. Is there an IP address that creates most traffic? What source is that (look it up on centralops.net maybe)? Which IP address is hitting files that are not for public access? Why is it not being banned by...

I didn't expect that. A WP websites without any 301 or 404 entries in the log sounds rare, because normally bad bots are trying the website. Is your question then where the traffic originates? You could find the top sources with cat access_ssl_log | awk '{print $1}' | sort -n | uniq -c | sort -n

We've had unnecessary support requests here, too, for the same case. Customers who were not using SiteJet Builder had received such mails, too.

Have you checked the access_ssl_log lines for the occurrence of " 404 " and " 301 " entries? Do you find any and if so, could you post an example here?

I've also tested it on the CLI, same error.

It is related to the recent Alma 9.4 -> 9.5 update.

It occurs independently from an enabled or disabled backup encryption and independently from FTP/FTPS settings. It affects not only the server backup, but all backup operations, including end user (subscriber) backups. It also has one more caveat: The failed remote backup is stored locally until...

@Sebahat.hadzhi This is critical, it will need a fast hotfix, because it leaves the affected servers without valid backups.

That is a known issue. Sometimes when a domain or subscription is removed, for unknown reasons the corresponding PHP configuration file is not removed. It then refers to non-existent directories which can lead to start failures of PHP-FPM.

Yes, please. I support this. New features are a nice-to-have, but the business is not about new features, but about reliability and trust. This can be achieved better by robustness of servers.