Question How can I retrieve content only through SFTP (and SSH)?

[Lenny]

Hello everyone,

I have two servers under Plesk, one for experiments on which resides my site and some sites in staging.

The experimental server was supposed to have a daily external backup from the host, with a 7-day rotation cycle. In addition, Plesk was backing up daily .tar backups of the Plesk configuration, resellers, and domains.

I wanted to experiment with HTTP/3 but I made a command error, I upgraded the entire server to Bullseye which Plesk is not compatible with. I tried to downgrade but it was complicated or impossible. I thought of reintegrating the backups of my host but for the moment, they are in error... I have a ticket with them. I'm going to see my /var/lib/psa/dumps folder by SSH/SFTP, there are backups ... in .tzst format and not .tar, I can't import them!

I tried SSH commands such as autoinstall, repair, restore, etc ... the bins do not exist anymore.

Currently, I'm recovering the www folder from my /var folder, it contains all the web files of my properties. I will try to transfer the mysql folder of /var/lib in which my bases are encoded. However, according to a Google search, the databases under InnoDB cannot be recovered in this way?

What can I *simply* export from my FTP (I have SSH access so I can give myself 777 rights) and re-import to a new server, in order to export a compliant .tar backup to import to a new server at another host? Keeping Plesk, of course.

Can I just export the whole /var folder and re-import it on a new Plesk Clean?

Have a nice day,
Lenny

 

[Lenny]

Downgrading from bullseye to bullster did not restore Plesk to working order but allows me to launch its installer.

Some packages can't be installed and each step shows an error, in the order (packages, errors):

Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming.

ERROR 1049 (42000): Unknown database 'psa'

Basic Plesk SSH commands such as bin, repair, and sbin show the following message: "Unknown Plesk command-line utility: "[command]". What I'm asking for is a full restore only via FTP.

The whole is corrupted, but some areas are partially accessible. I have SSH root access and can run multiple VMs if I need to copy instances. Is it possible to restore the whole Plesk by copying and pasting one or more directories?

 

[Dave W]

In your situation you should first try and get the server restored to a time before the attempted upgrade.

Failing that, you will need to recreate the domains on a new Plesk server and import the sites files via FTP from the source server.

For the databases you will need a database server running the same database application as you had on the source server, replace the /var/lib/mysql folder with your original files and start the mysql application. There may be issues in doing this, but with a bit of luck the application will start. This will allow you to dump the databases individually.

You will need then need to recreate the databases on the new server in Plesk and then import the databases from the source server.

 

[Lenny]

I have some but they are currently unusable (restoration via my host sends me "Can not connect to the server" errors both in SSH and access to the Plesk panel on the browser). A ticket is still open at my hosting company, although I am in the process of migrating to Google Cloud Platform.

Currently, I notice that the .tzst files have the new compression method imposed by Plesk late last year. Inspecting a healthy backup, I notice that it is simply a matter of wrapping the entirety of these .tszt files into a .tar file, I have done this and am transferring via SFTP to my new instance at Google Cloud Platform, once done, I would run an SSH command to execute the restore.

This seems like the sanest solution, I'm testing this and if it doesn't work, I'll try your solution, which on paper seems to work just as well (now, it's more getting your hand in the cookie jar and so the risk of error is greater). Thank you for your solution proposal!

 

[Lenny]

When running this command:
"plesk bin pleskrestore --restore "/var/lib/psa/dumps/backup_info_date.tar" -ignore-sign -verbose -level server"

This error message appears:
"Unable to import file as dump: Import error: Unable to find archive metadata. The archive is not valid Plesk backup or has been created in an unsupported Plesk version"

 

[Bitpalast]

I've seen the same message when the same backup has previously been imported and is already a local backup.

 

[Lenny]

In your situation you should first try and get the server restored to a time before the attempted upgrade.

Failing that, you will need to recreate the domains on a new Plesk server and import the sites files via FTP from the source server.

For the databases you will need a database server running the same database application as you had on the source server, replace the /var/lib/mysql folder with your original files and start the mysql application. There may be issues in doing this, but with a bit of luck the application will start. This will allow you to dump the databases individually.

You will need then need to recreate the databases on the new server in Plesk and then import the databases from the source server.

I tested this for half of the domains. As for the rest, I simply uploaded the entire dump folder as it is (with the .tzst files) and miraculously, it is recognized in the Backup Manager!

As for your method, it works but it brings a lot of ".conf" errors. As it is, it allows you to go back online while debugging.

The other method, with the import of the dump folder, also works and doesn't seem to report any errors (except for a bad reconfiguration of the SSL certificates, they are imported but not recognized by the browser. It is, therefore, sufficient to reconfigure them). Reconfigured via Backup Manager -> it works. Tested via SFTP, it doesn't work as well because it's not the root user or the reseller login that is passed but my SSH login that Plesk doesn't recognize on its back office.

All you have to do is import all the files (composed of .tzst, .XML, and unformatted files) and dump folders. You will recover your files, your databases, your e-mail addresses, and their messages and a large part of the server configuration, your domains, and resellers. You can delete incremental backups (recognizable by the nomenclature backup_services_date1_date2 where the fourth argument indicates that it is an incremental backup, there must be only three arguments i.e. backup_service_date).

 

[Lenny]

Everything passed but one last problem: NginX won't start!

Error: New configuration files for the Apache web server were not created due to the errors in configuration templates: nginx: [emerg] unknown "rocket_mobile_detection" variable nginx: configuration file /etc/nginx/nginx.conf test failed. Possible solution: Try to remove directive (if defined) from the Additional nginx directives section at the bottom of the page and rebuild broken configuration.

Error: Can not reconfigure web server configurations: Unable to execute httpdmng: [2022-02-10 18:40:23.580] 1528773:62054dff1cb50 ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/nginx-config' '-t'] with exit code [1] [2022-02-10 18:40:24.965] 1528773:62054dff1cb50 ERR [panel] Apache config (16445148140.83298100) generation failed: Template_Exception: nginx: [emerg] unknown "rocket_mobile_detection" variable nginx: configuration file /etc/nginx/nginx.conf test failed file: /opt/psa/admin/plib/Template/Writer/Webserver/Abstract.php line: 75 code: 0 nginx: [emerg] unknown "rocket_mobile_detection" variable nginx: configuration file /etc/nginx/nginx.conf test failed

The viable rocket_mobile_detection is part of a WP Rocket extension of WordPress. Initially, it uses a modified version of NginX called rocket-nginx. I disabled its include in the nginx.conf files of the few virtual hosts that had it but the above problem happens. I can't regenerate the files, either via the Webserver Configurations Troubleshooter or via SSH, the repair web command doesn't want to go further because the /etc/nginx/nginx.conf test fails. This file is healthy.

 

[Lenny]

To fix the problem, a copy of this rocket-nginx had to be reinstalled.

On the other hand, I don't advise anyone to switch to Google Cloud Platform with Plesk ... This host definitely blocks port 25, you have to go through an API or SMTP relay to be able to send your emails. API that becomes chargeable in case of overuse, which is defined by Google policy. Moreover, the DNS management behind the NAT is not well done...

In any case, this problem is solved.

 

[Dave W]

Mail submission is on port 587, not port 25.

 

[Lenny]

By default, a clean installation of Plesk only uses port 25 for email output.

Checking the box to enable port 587 doesn't seem to solve the problem of sending emails, I think it could work internally via the use of webmail but not via an external application. In any case, I could not send any e-mails and Plesk informs me, even if I only use 587, that port 25 is blocked and that e-mails cannot be sent.