Helm's Technology Blog

Cpanel is a good system for administrating a server with many sites on it, i’ve used ensim, webmin and a couple of others in years gone by (Plesk and parallels were disasters for me!).  However occasionally something that you think should work just doesn’t and for no obvious reason.

The Cpanel system has a feature to migrate accounts from another server – be it Cpanel or another webhosting panel – this often works, recently though I’ve had a problem with using it for Cpanel to Cpanel where it would connect but fail to transfer the backup file.

Fortunately it’s really easy to use the commandline with cpanel and you can do it manually (actually it’s easier than the wizard!)

On the server you are migrating from just type (while logged in as root!)

/scripts/pkgacct username

This will create a tar.gz in the /home directory on the server – just copy this to the new server (it could take a while – it has everything from the account you are copying).

On the destination server just type in

/scripts/restorepkg username

This creates (or overwrites the account!) on the server – and your done!.  But what if you have a dedicated IP (due to SSL?)

Easy just use this instead

/scripts/restorepkg –ip=y username

This gives it the next free dedicated IP address (make sure you have one free!)

And that’s it – it is honestly easier than the wizard which requires you to add more info to establish the transfer link.

One thing to note is that you should ensure that the versions of cpanel are as near as you can get – otherwise it might fail or do things a little weird.

An incident earlier this week has made me review the backup systems in place for my wifes company (www.ihelm-enterprises.co.uk).

One of our clients doesn’t exclusively use us and so had a problem when another host lost a server and had no backups – the client also doesn’t backup frequently and had hoped that the server hosts would have some form of backup – but of course they didn’t.

We have always been a bit unusual in that we have routinely done backups – however we don’t do them every day and they do frequently fail – as we have a mixture of servers we had a rather un-orthodox way of doing them.

Server 1 performed its backup by transferring to Server2
Server 2 then transferred server 1 and server 2′s backup to the next server etc… until the final resting place was a repository where only the final server could get teh files – this was backed up by a 3rd party regularly.

However after hearing of our clients problems I thought I would try our system to see if we could easily recover – and found that
a) our repository was full and I hadn’t had any notification of this.
b) geting the files off was extremely difficult as some of the files are very large and the server will access to the repository didn’t have a lot of space…
c)  Some of the servers have not been notifying me of messages encountered during the backup so no idea of the files were complete or not.

So decided to re-think this a bit.

Now our servers transmit to our office computers – one of which is on 24hrs – this then uses windows file sharing (despite it being a linux computer ) to copy the files over to a new NAS which is located somewhere the office.

We have already seen some benefits from this – we can easily see what files are on the NAS & restoring is simple, also each server has a set time to transfer its files – so any problems we only need to look at that server and re-run specific backups.

The bottom line is – if you do provide backups or just to backup your own work – do check your backup system every now and again – ours had been in place over a year after the previous model was un-doable with the adsl we had at the time – but since then the cheapness of Network Attached Storage devices has meant we can affordably implement this as well.

Backup – Backup – Backup – Check – Review – Backup – Backup – Backup – Check – Review, this is now my new mantra!