Issues using pleskbackup

[freaky@]

Hi there,

I'm trying to run a simple '/usr/local/psa/bin/pleskbackup server' (tried many variations, including attempting to back-up just 1 domain, 1 reseller, etc.) and it doesn't work.

It gives the very useful error:

root@plesk:/usr/local/psa/PMM/sessions# /usr/local/psa/bin/pleskbackup server
Runtime error: Unknown error from pmmcli

It does create a folder under /usr/local/psa/PMM/sessions. It contains 2 files migration.result and psadump.log.

The psadump.log shows it calculating sizes for the domains, it lists the existence of some keys in /etc/sw and ends with:

[5212]: 09:12:53 DEBUG Get backup size for server settings
[5212]: 09:12:53 DEBUG Retrieve size of '/var/www/vhosts/.skel/0': 252111 bytes
[5212]: 09:12:53 DEBUG Server: BackupSizeCalculator::getServerSettingsKeysSize started.
[5212]: 09:12:53 DEBUG getServerSettingsBackupSize: Found sw key repository: /etc/sw/keys
[5212]: 09:12:53 DEBUG getServerSettingsBackupSize: Load keys from '/etc/sw/keys/keys'
[5212]: 09:12:53 DEBUG Retrieve size of '/etc/sw/keys/keys/keyXXtOYV0h': 9524 bytes
[5212]: 09:12:53 DEBUG Server: BackupSizeCalculator::getServerSettingsKeysSize finished. Size is 9524 bytes.
[5212]: 09:12:53 DEBUG Server: BackupSizeCalculator::getServerSettingsAppPackagesSize started.
[5212]: 09:12:53 DEBUG Aps index file /opt/psa/var/apspkgarc/archive-index.xml is not exists. Skipping.
[5212]: 09:12:53 DEBUG Server: BackupSizeCalculator::getServerSettingsAppPackagesSize finished. Size is 0 bytes.
[5212]: 09:12:53 DEBUG Server: BackupSizeCalculator::getServerCustomButtonsSize started.
[5212]: 09:12:53 DEBUG Server: BackupSizeCalculator::getServerCustomButtonsSize finished. Size is 0 bytes.
[5212]: 09:12:53 DEBUG Get backup size of server settings finished. Size is 261635 bytes.
[5212]: 09:12:53 DEBUG Get backup size finished. Backup size of selected objects is 32765328899 bytes

Which seems fine to me.

The migration.result contains very little:

root@plesk:/usr/local/psa/PMM/sessions/2013-08-05-111252.858# cat migration.result
<?xml version="1.0" encoding="UTF-8"?>
<execution-result status="success" log-location="/opt/psa/PMM/sessions/2013-08-05-111252.858/migration.result"/>



Any ideas what might be going on?

 

[IgorG]

What sort of output:

# ll /bin/ps*

?

 

[freaky@]

Hi IgorG,

not sure whether you actually meant ps or pts, so here's both

root@plesk:~# ll /dev/pts*
total 0
drwxr-xr-x 2 root root 0 Jul 2 10:53 ./
drwxr-xr-x 14 root root 4260 Aug 5 10:47 ../
crw--w---- 1 root tty 136, 0 Aug 5 10:03 0
crw------- 1 root tty 136, 1 Aug 5 13:12 1
c--------- 1 root root 5, 2 Jul 2 10:53 ptmx

root@plesk:~# ll /dev/ps*
crw------- 1 root root 10, 1 Jul 2 10:53 /dev/psaux

 

[IgorG]

Hmm... I asked about exact command:

# ll /bin/ps*

but not

# ll /dev/ps*

 

[freaky@]

Sorry was asleep I guess :/

root@plesk:~# ll /bin/ps*
-rwxr-xr-x 1 root root 101240 Dec 12 2011 /bin/ps*


root@plesk:~# /bin/ps --version
procps version 3.2.8

 

[freaky@]

This is odd... I got it working - not sure why though.

We 'migrated' to this server from a 9.5 installation. The 9.5 was backed-up with CLI tools, the new machine, still 11.0 then, was created with the same IP addresses as the old one and the backup was restored (had quite some issues with that too).

All these 'backups' (well restores) still had their data in /var/lib/psa/dumps. In total about 25G's. I just removed all those files, including the customer directories (rm -rf /var/lib/psa/dumps/clients/*).

After that the backup seems to work (that is - it's running now about 20% done now). The backup command I used is literally copied/paste from the bash history file (had quite some domains to exclude) so it's highly unlikely it has to do with parameters, etc (simple 'pleskbackup server' didn't run either tho'). Going to test restoring this on a CentOS based plesk as we have odd issues with PHP as FastCGI running on Ubuntu on some sites (this already was the case with 9.5 and still was with 11.0 and now 11.5). The pages won't load properly, PHP nor Apache throws an error (well - after modifications that is - before that the error log contained something about index.pl not existing removed index.pl as default document (have no perl users) and since no errors whatsoever - but still doesn't run properly).

This happens only on some sites, all of these use .htaccess files with rewrite rules (but do note - not all sites with .htaccess rewrite rules have it) and it's a real pain to troubleshoot. Seen many posts on it - none seem to have a proper solution .

 

[MargaritaK]

Hello!
Could you please attach example of .htaccess file? And more detailed error from Apache.
Too less info to understand root cause.

 

[freaky@]

Hi there,

sample .htaccess:

Options FollowSymlinks

<IfModule mod_rewrite.c>
Options -MultiViews
RewriteEngine On

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
</IfModule>

And more detailed error from Apache.
Too less info to understand root cause.

Err afraid not. That's one of the largest issues with the issue .

After I removed index.pl from apache's DirectoryIndex directive there are no errors any more, you just get incomplete or non functional pages. PHP seems to die or something during the processing if it actually starts processing anything at all.

Before that it stated in the error_log:
[Mon Jul 01 10:16:45 2013] [error] [client 80.84.244.142] Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden: /var/www/vhosts/thedomain.nl/httpdocs/index.pl

Which is utterly useless as:
a) there is no index.pl, the fact it thinks there should be an index.pl probably has to do with the fastcgi wrapper script
b) FollowSymLinks is actually on

As stated after removing index.pl from DirectoryIndex there is no error whatsoever (at least not in the usual error log).

This customer for example has a protected area (the admin part). If I set PHP to as module (or let nginx run it under fpm) the page still craps out when logging on (due to file permissions probably - haven't corrected those to be compatible with running PHP as the webserver user) but you get a nice logon page (ie - one generate by PHP with nice HTML etc.). If PHP is set to fastcgi we get a basic authentication dialog (like when you configure basic authentication in the .htaccess). We also have sites where the page just stays blank, but the fact it returns an authentication header might indicate it does process at least a bit (then again - apache might send it).

 

[freaky@]

Btw there's many others that reported similar issues. See here for example: http://forum.parallels.com/showthre...erMatch-is-off-which-implies-that-RewriteRule

Been troubleshooting this for quite some time about 1,5 month ago. The best I could find was an explanation that it was hard to explain as it had to do with the internals of Apache, the way it and PHP handle URL in combination with the rewrites and even then only in specific cases. No solution was offered - probably to hard .

I've tried many suggestions on the forums without success yet. Maybe some people consider it solved when the error disappears from the log file though, although, at least in our case, that doesn't resolve the actual issue. No error, but the page still isn't correctly generated either.