Pleskbackup vs. psadump filesize discrepancy

[Limedrink]

Before upgrading from Plesk 7.5.4 to Plesk 8.0.1, I performed a full backup using psadump. After the upgrade, I used the new pleskbackup tool and did the same thing.

My psadump totalled 40 GB.

My pleskbackup totalled 29 GB.

There must be some new compression in the new utility, or something must have gone wrong.

Additionally, I ran pleskbackup right in the SSH session, and there was no ouput or logs so I was not able to determine if there were any errors during the process.

Anyone have any ideas to explain what had happened?


Regards,

Limedrink.

 

[0031]

psadump used base64-encoding of the content. pleskbackup is using binary encoding. Size difference between them should be near 30%

Logs:
1. export PLESKBACKUP_DEBUG=1
2. run pleskbackup
3. look in /var/lib/psa/dumps/tmp - there should be plenty of them

 

[Limedrink]

I ran the commands again, but the directory is still empty!

 

[Limedrink]

I contacted SWsoft support regarding the issue and they refused to offer me any support because I'm licensed through my datacenter.

I really hope these full server backups are being created correctly...

I could try a test restore on another server, but I'd need another license for that.

If anyone has any other ideas, please let me know.


Regards,

Limedrink.

 

[0031]

Fresh info from SWsoft support:

To obtain logs in /var/lib/psa/dumps/tmp

1. Create temp (/tmp/backup for example) directory anywhere
2. cp -r psa/PMM/agents/PleskX/* /tmp/backup
3. cp -r psa/PMM/agents/shared/* /tmp/backup
4. chmod +x /tmp/backup/PleskX.pl
5. For domain backup: /tmp/backup/PleskX.pl -dd domain1.com -o backup.gz

 

[Limedrink]

Thank you for your response, 0031.

That is for individual domain backups.

How about for full server backups through the pleskbackup utility?


Thanks again.

 

[0031]

PleskX.pl -da -o backup.gz

Just run PleskX.pl --help

 

[Limedrink]

Hmmm....

I just set up another box to test the backup process -- I figured this would definitively answer all of the questions and concerns I have.

To my surprise, the restore process was easy.

All the data looked there, HOWEVER:

Production server "/": 60 GB
Test backup server "/": 35 GB

That amounts for a 25 GB difference! This is where the problem starts.

I realize that I have to take the following into consideration:

1. Log files were not backed up
2. I have my own files in /home/root/ etc. on the production server (not too many)
3. This is a backup that is a week old, so I need to give/take a few GBs

However, I looked into some accounts that looked wayyyy too small compared to their original. It seems as if the httpdocs folder just contained the skeleton files and no subdomains were restored! Oh no!

I don't understand how this has happened. From what I can see, not too many accounts are affected. I compared the accounts from one server to the other directly, and all the mail accounts and databases restored fine, however, the httpdocs/subdomains weren't restored.

I anticipate that the problem is relative to the backup process and not the restore process.

Anyone know any possible reasons for this?


Thanks,

Limedrink.

 

[Limedrink]

Ok, so I did investigate a little further on this issue. Here is what I've come up with:

I created individual domains backups through the Backup Manager, 1 for a domain that I know restored successfully through pleskbackup and 2 that I know didn't.

The domains that did restore successfully from pleskbackup, restored this individual domain file from the Backup Manager with no problems.

The domains that didn't restore successfully from pleskbackup, gave an error upon restoring the invidiual domain file from the Backup Manager. That error states:

DetailsDomain [domain] has been restored

domain [domain]


Execution of /usr/local/psa/bin/domain_pref --update info-[domain] -wuscripts

true -at-access true failed with return code 1.
Stderr is
filemng: Unable to recieve real path for

'/var/www/vhosts/[domain]/httpdocs/at_domains_index.html'

System error 2: No such file or directory
An error occured during updating domain preferences: Unable to set at domains index

file: Unable to resolve path to file

/var/www/vhosts/[domain]/httpdocs/at_domains_index.html

I hope that helps in figuring out what might be the cause of the issue.

Thanks again.


Regards,

Limedrink.

 

[gijsbert]

I figured out it has to do with web_users. Go to web_users and click 'preferences'.

(de)Select the option Enable webuser@<domain> access format and click OK. You will see a similar error-message.

I'm still not sure how to fix this.

 

[Limedrink]

Thanks gijsbert, that worked!

I was able to copy the at_domains_index.html file from another working account into the httpdocs and httpsdocs folders on the domain that gets the error.

I can then uncheck the Enable webuser@domain option and then the files disappear. The account is fixed!

However, it won't let me re-enable it either. It seems to be a Plesk related problem. This is actually good, because if someone were to delete their own at_domains_index.html file the domain won't backup properly and then obviously won't restore. This prevents them from enabling the option to begin with .


Regards,

Limedrink.

 

[gijsbert]

Yep, I figured this out also. If you ever need to check that option again (I have no idea what it means), simply copy the at_domains_index.html file to the httpdocs and httpsdocs (yes, it's in both directories) and check the option under preferences of the web_users

In case someone is interested: If you use the migration manager and you receive an error like:

------
Execution of /usr/local/psa/bin/domain_pref --update <domain> -at-access true failed with return code 1.
Stderr is filemng: Unable to recieve real path for '/var/www/vhosts/<domains>/httpdocs/at_domains_index.html'
------

do the following to fix it:

1. Make sure the at_domains_index.html is on the 'old' server in http(s)docs
2. Go to web_users and then preferences
3. Uncheck the option "Enable webuser@<domain> access format
4. Make sure the at_domains_index.html is gone in http(s)docs
5. Migrate the domain without errors

And if you need to enable the option mentioned in (3) again, just copy the at_domains_index.html to the http(s)docs and check the option "Enable webuser@<domain> access format under preferences of web_users

That's it, but it took hours to figure out what happened

 

[BiGWill]

thanks, that fixed the issue.