Pleskrestore error on .tar

[DieterV]

Hey,

i am trying to restore a plesk backup restore with the following command on a ubuntu 10.04

sudo /opt/psa/bin/pleskrestore --restore /home/ds/wtf10/converted_info_1103021949.xml -level all -verbose -debug

converted_info_1103021949.xml is my pleskbackup form 9.5 converted to 10.x. The problem is the the users and everything is corrected restored but when it comes to unpack the data files from the physical hosting i get the following errors

tar: ./httpdocs/plesk-stat: Cannot utime: Operation not permitted
tar: ./httpsdocs/plesk-stat: Cannot utime: Operation not permitted
tar: ./anon_ftp/conf: Cannot utime: Operation not permitted
tar: ./var/tmp: Cannot utime: Operation not permitted
tar: ./var: Cannot utime: Operation not permitted
tar: ./opkotingent.be_httpdocs.tar: Cannot open: Permission denied
tar: .: Cannot utime: Operation not permitted
tar: Exiting with failure status due to previous errors

i am logged in as root. has some any idea form where this problem is comming from? dus plesk restore user an other user then currently logged in whit in? it seems that the data is converted correct but i was wondering if i need to anything at this error or not.

 

[IgorG]

Is it Virtuozzo VPS? In that case it can be related to quota issue and should be corrected from Virtuozzo side. Also make sure that /bin/tar has correct permissions.

 

[comicmaus]

Hi,

are there any news on this topic? I'm asking because I see similar errors during a command line migration of single domains from Plesk 9.5.x to 10.1. The behaviour is also the same, all accounts are created but the content and the configuration files are missing.

Some example lines:

tar: conf/webalizer.conf: Kann open nicht ausühren: Keine Berechtigung
tar: conf/vhost.conf: Kann open nicht ausführen: Keine Berechtigung
tar: conf/httpd.include: Kann open nicht ausführen: Keine Berechtigung

 

[comicmaus]

This is a bug in Plesk!
I wrote a small wrapper around the tar binary to check which permissions are used for the different tar calls during a restore. The contents of a virtual host directory is unpacked with the rights of the virtual hosts ftp user, which has no permission to write to conf and statistics directory.
To avoid this, a wrapper could be used, giving the tar operation the right permissions or the unwritable files must be copied via rsync from another host or backup into the right places.

This is also NOT fixed with Plesk 10.2.

 

[argonius]

FIX needed SOON!

Hey Parallels,

please submit a solution for this problem.
I have to restore >1200 domains from one server to another, but config/* is not stored back.
I am getting permission denied, 'cause webuser has no write permission under conf/

fix it soon please!! we are paying much money for many different plesk, plesk-additional and virtuozzo
licencses and expecting a working product, 'cause this is major release 10?!?!?!

THANKS!

 

[IgorG]

As I see in initial post there was sudo used. I assume that problem in that sudoers rules was not correctly defined. You should run CLI commands only as root user without sudo.
I have checked all our internal resources for many years and not found any mentions of similar problem. Therefore I suppose that it is not Plesk bug but some misconfiguration on your server.

 

[argonius]

we are not using sudo

hi,

on the old system we are running
ubunut 8.04 with plesk 9.5 backup is done without sudo, we are just logged in as root over ssh

on the new system we are using centos 5 x64 with plesk 10.2
everything seems to be fine while importing the backup via pleskrestore, but in the end, there come
the permission denied messages for statistics/* and conf/* files and directories.

there is no special configuration, so please investigate this!

thx

 

[lingho]

This problem is still there at 10.4.x. I worked around it by setting setuid on /bin/tar (chmod a+x /bin/tar). But make sure it's is changed back after the restore is done. What a frustrating exercise trying to backup and restore to a different host.

 

[burnleyvic]

You can forget about it. Parallels developers can't fix it, so they decided it's a feature request with no ETA. Company's response is:
A feature request has been created for this issue and bug id is 101752. We are unable to provide any ETA, when it will get fixed.[...]
I am marking this ticket as "Resolved – Pending for Customer Confirmation". Feel free to reply back in case you need further clarifications.
What a fantastic job I've got, spending more time with Plesk issues than doing something useful for my employer and our customers.

 

[IgorG]

You can forget about it. Parallels developers can't fix it, so they decided it's a feature request with no ETA. Company's response is:
A feature request has been created for this issue and bug id is 101752. We are unable to provide any ETA, when it will get fixed.[...]
I am marking this ticket as "Resolved – Pending for Customer Confirmation". Feel free to reply back in case you need further clarifications.
What a fantastic job I've got, spending more time with Plesk issues than doing something useful for my employer and our customers.

Please do not mislead people. You have already reply from Support Team that it is not considered as Feature Request and this problem currently under developers investigation. Your ticket is not resolved and Support Team still working on your problem.
Please be objective and fair in relation to our efforts.

 

[burnleyvic]

Igor, that message I cited was received before Alexei stepped in to clarify the communication issue between Parallels L1 & L2 support departments.

 

[IgorG]

Igor, that message I cited was received before Alexei stepped in to clarify the communication issue between Parallels L1 & L2 support departments.

Ok. I hope all will be fixed now.

 

[tkalfaoglu]

PLESK 10.4 , it is still not fixed

The restore returns:

tar: statistics/logs/xferlog_regular.processed.1.gz: Cannot open: Permission denied
tar: statistics/logs/xferlog_regular: Cannot open: Permission denied
tar: statistics/logs/access_log.processed.1.gz: Cannot open: Permission denied
tar: statistics/logs/access_log.processed.5.gz: Cannot open: Permission denied
tar: statistics/logs/xferlog_regular.processed.5.gz: Cannot open: Permission denied
tar: statistics/logs/error_log.1.gz: Cannot open: Permission denied
tar: statistics/logs/access_log: Cannot open: File exists
tar: statistics/logs/access_log.processed.4.gz: Cannot open: Permission denied
tar: statistics/logs/xferlog_regular.processed.3.gz: Cannot open: Permission denied
tar: statistics/logs/error_log.4.gz: Cannot open: Permission denied
tar: statistics/logs/xferlog_regular.processed.4.gz: Cannot open: Permission denied
tar: statistics/logs/access_log.processed.3.gz: Cannot open: Permission denied
tar: statistics/logs/error_log.3.gz: Cannot open: Permission denied
tar: statistics/logs/error_log.5.gz: Cannot open: Permission denied
tar: statistics/logs/error_log: Cannot open: File exists
tar: statistics/anon_ftpstat/index.html: Cannot open: File exists
tar: subdomains/tiresutkoop/httpsdocs: Cannot mkdir: Permission denied
tar: subdomains/tiresutkoop/httpsdocs/index.html: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/css: Cannot mkdir: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/css/style.css: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/css/tabs.css: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img: Cannot mkdir: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img/common: Cannot mkdir: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img/common/top_bg.gif: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img/common/arrow.gif: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img/common/footer_right_bg.png: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img/common/footer_bg.gif: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img/common/content_bg.gif: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img/common/banner.jpg: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img/common/pws_box.jpg: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img/common/pdfm_box.jpg: Cannot open: No such file or directory
tar: subdomains/tiresutkoop/httpsdocs/img/common/def_plesk_logo.gif: Cannot open: No such file or directory

 

[tkalfaoglu]

Furthermore, tar extraction of a small hosting seems to take minutes for some reason..

[19:40:05|INFO: 5714.log] Check file /var/lib/psa/dumps/clients/lemi//domains/pyro-world.com/lemi_pyro-world.com_vhost_1205101727.tgz is gzipped
[19:40:05|INFO: 5714.log] File is gzipped
[19:40:05|INFO: 5714.log] Executing utility: tar -z -f /var/lib/psa/dumps/clients/lemi//domains/pyro-world.com/lemi_pyro-world.com_vhost_1205101727.tgz -xvm -C /var/www/vhosts/pyro-world.com --wildcards --anchored --exclude-from=/tmp/repo_transport_tmp_XVFPvK
[19:41:57|INFO: 5714.log] The utility executed with the return code 0

 

[tkalfaoglu]

Actually, I was wrong -- it's AFTER TAR that it's hopelessly slow.. It just waits and waits, a good ten minutes or more, while the GUI shows "in progress".. and nothing appears in the migration log during that time. However, "deployer" is using the %100 of the CPU of a i2600 during these good 20 minutes.

Note the time stamps between the two spaces I added in the log:

[19:40:05|INFO: 5714.log] File is gzipped
[19:40:05|INFO: 5714.log] Executing utility: tar -z -f /var/lib/psa/dumps/clients/lemi//domains/pyro-world.com/lemi_pyro-world.com_vhost_1205101727.tgz -xvm -C /var/www/vhosts/pyro-world.com --wildcards --anchored --exclude-from=/tmp/repo_transport_tmp_XVFPvK
[19:41:57|INFO: 5714.log] The utility executed with the return code 0


[20:03:16|INFO: 5714.log] Unpack file to '/var/www/vhosts/pyro-world.com' User: 'apache', group '0'
[20:03:16|INFO: 5714.log] repositoryUnpacker:unpack 'domains/pyro-world.com[vhost]: lemi_pyro-world.com_vhost_1205101727.tgz,' to '/var/www/vhosts/pyro-world.com'
[20:03:16|INFO: 5714.log] Unpack with user 'apache' permissions
[20:03:16|INFO: 5714.log] Includes:

 

[OwenMM]

Is there any news on this issue? We are experiencing the exact same problem with our Plesk 10.4 deployment. In our case, the deployer process claims 100% of one of our CPUs for an extended period before relinquishing the CPU to the tar process which then claims 100% of one of the CPUs indefinitely. When hovering over the tar process in the System Monitor, we get the same information as posted above for one of our websites (sub our domain for the aforementioned one):

tar -z -f /var/lib/psa/dumps/clients/lemi//domains/pyro-world.com/lemi_pyro-world.com_vhost_1205101727.tgz -xvm -C /var/www/vhosts/pyro-world.com --wildcards --anchored --exclude-from=/tmp/repo_transport_tmp_XVFPvK

We've tried both a gui and cmd line approach, we've adjusted the permissions associated with the backup files from the associated user to root to match those of the other sites and the fact that we're launching the job as root. We're finding that the Plesk Panel logs seem to offer little in the way of insight or clues.

We're in the process of procuring panel licensing from our hosting provider, but if this issue persists with no resolution, we will be forced to rebuild our VM with an alternative to the Plesk Panel to move our project forward. Any news on the progress and any assistance here would be greatly appreciated.

 

[tkalfaoglu]

The PLESK migration almost killed me. I first did it with migration manager twice, which migrated about half of the folks, then client level which migrated a few more, then domain level which migrated one by one, the remaining unlucky ones. Allow several weeks of hair pulling.

 

[IgorG]

Why you do not try Free Migration Assistance?

 

[tkalfaoglu]

I had no idea a such beast existed.. The downside was that many customers now hate me, the upside was I became an expert on the subject

 

[OwenMM]

We fought with the migration as well. Plesk managed to pull the site files and panel configs over, but only partially transferred the database. As a result, we had to manually transfer the database to get everything working.

Now we're fighting the backup and restore functionality. The backup seems to have completed successfully, but upon closer inspection of the backup files, I suspect we will encounter a similar database challenge upon a successful restore if we ever get to that point.

I found an interesting blog post on blogspot entitled "Move a site from a server to another without Plesk." While we could potentially script a solution here, I would ask the question: why would we pay for a license if we have to constantly work around the panel? I hope that Parallel will present a solution or work with us here to find one in the near future. In the time it's taking us to fight what should be a simple and straightforward backup/restore operation, I could have rebuilt our VM with an alternate panel and taken it live. Reaching out here and to our rep is our last resort before we write the product off altogether and move in another direction. My hope is that Parallel will step up and escalate this to figure out what's going on before we are forced to do so.