Fully automated backup and restore
First and foremost: you do not need a GoDaddy FTP backup account to backup and restore your server, although they would love to sell you one, and it may make sense for you to have such a service anyway if you require robust backup services (which I don’t require). Plesk includes an automated backup and restore utility for your convenience. Note that this did not work for me, as explained below. However, it may work for you because I had some very specific problems, and you should try this before the semi-automated method.
Log into your old virtual server as root through SSH, and execute the following command:
./usr/local/psa/bin/pleskbackup all /var/www/vhosts/ineedattention.com/httpdocs/plesk.backup
Replace “ineedattention.com” with the name of one of the domains on your virtual private server. This may take a while, so I suggest you get some coffee or do some push-ups. When the server is done making the backup, log into your new virtual server as root, and execute the following command:
cd /usr/local/psa/bin/
wget http://ineedattention.com/plesk.backup
This will copy the server backup file from your old virtual server to your new virtual server. The connection between the two servers is very fast, but for large sites, this will take some time. Go grab another coffee or do some sit-ups if there is a wait ahead of you.
Once the backup file is transferred, you can restore your files and settings to the new server. If you are upgrading from a Plesk 7.5.4 host or older, you will need to execute the following commands first:
mv plesk.backup plesk.backup.old
backup-convert.py convert -o plesk.backup.old plesk.backup
If you were already running Plesk 8.0 on your older server, you can skip the last step, and proceed to restore your files and settings directly. Run the following commands to restore your files and settings to your new server:
./pleskrestore --create-map plesk.backup -map pleskbackup.map
./pleskrestore --restore plesk.backup -map pleskbackup.map -level all /var/www/vhosts/ineedattention.com/httpdocs/plesk.backup
According to the Plesk documentation, data will be restored without disruption of hosting services and downtime. The server configuration settings and all user data (including the content of Web sites and messages in mailboxes) will be overwritten. I wasn’t so lucky — my configuration settings and user data were overwritten, with my files restored properly. However, there was one major problem: this method didn’t restore my SSL certificates on two domains.
SSL certificates are crucial for e-commerce applications and if these are not transferred properly, it could mean the difference between doing business and not doing business online. Every major browser down to the Nintendo Wii’s version of Opera will notify the user that they cannot connect to sites if those sites lack properly installed and signed SSL certificates.
I couldn’t figure out why the certificates wouldn’t map properly, but to be fair, I did notice that the certificates were installed in the server’s certificate repository on the old server, and the new server wanted certificates to be mapped to a particular domain name or IP address repository. This may have been something again related to the Plesk version difference — my old virtual server was running Plesk 8.1.1 and my new server was running Plesk 8.2.1.
Yet another major issue was the mapping of old and new IP addresses. You may notice that in one step above you create a file called pleskbackup.map. This file contains the server configuration and links certain changed values between your old and new virtual servers. This is necessary because the new and old server will have different IP addresses, for example. My old server had three IP addresses: one exclusive to me, and two shared amongst my clients. I allocated three IPs for the new server, and attempted to make one exclusive and two shared in the Plesk server configuration page before performing the restore command. But for some reason, no matter how many times I re-provisioned the server and adjusted the mapping file, the restore command would map all my domains to a single shared IP address (which I didn’t want).
Since the Plesk backup/restore server utility didn’t work, I had to try an alternate method.
Continue reading: Previous page Next page
3 responses so far ↓
1 Pete // Mar 4, 2008 at 12:53 pm
I am facing this exact problem right now. Upgrading to Fedora Core 7 on a Virtual Go Daddy Server. I know nothing about this stuff at all and I’m thinking I should just forget it. I cannot have things screwed up for 3 months, or even 3 days. I just became aware of the Fedora change option and I do not want to do it. I will stick with the old Fedora 4 thank you very much. I have spent too much time manually finding and changing the “PHP ON” areas of the server code and that was beyond a nightmare. As for starting over with a new server and migrating…. I can’t remember all the stuff I have to migrate. There must be a better way, and why must we change the operating system in the first place?
Terminal codes, shell codes, FTP codes… what’s a regular person to do? Go Daddy should offer a per incident support fee for BIG trouble items like this, not leave us all hanging like Chads in the wind. I give them a 0/10 for this fiasco!
2 Time to ditch GoDaddy? // Mar 12, 2008 at 10:34 pm
[…] a GoDaddy VPS customer, and amateur tutorial author and reviewer, this upset me, so I wrote a note on GoDaddy’s public relations feedback […]
3 DrewryNewsNetwork // Oct 26, 2010 at 10:55 am
Hopefully, everything you said will help me upgrade my server, in making php & mysql 5 work on the VPS!
Leave a Comment