You’ve already gone through environment matching, and are ready to start the initial sync. If you are following along on the 100-foot view of migrations, we are ready to “create any domains or accounts” on the new server.
But we already have domains or accounts set up on the old server. Can we use those as templates?
Of course!
Creating cPanel Backups
cPanel includes a really great resource for making backups of individual cPanel accounts which are complete and portable. The command line tool is /scripts/pkgacct.
For the purpose of migrations, though, we don’t quite need a complete backup. Some of the data is needlessly copied, compressed, decompressed, and recopied, when it could be streamed over to the new server directly using ssh or rsync. More importantly, you can’t guarantee how much disk space you might have on a system you don’t control. You might only have two or three gigs, and 900 GB of accounts to migrate! Trust me, it can happen!
So, our options for pkgacct are:
/scripts/pkgacct --skiphomedir --dbbackup=schema ${username}
The flags passed will skip the entire /home/${username} directory, which can instead be copied over outright, and the database contents, which can be streamed to the new server. It does include, though, the schema for the databases, which are the create statements, mappings, and grants.
When created in this fashion, even the largest cPanel accounts are backed up into a single gzipped tarball of around 2MB. I like to call this the ‘cPanel skeleton’ file. It contains everything not excluded from the backup, namely: the user itself and its password, database creation statements and grants, assigned sites, DNS zonefiles, FTP users, logs, historical bandwidth data, SSLs, userdata, package limits, and so on. Essentially, all of the metadata of the account, save the actual website files and databases.
Restoring cPanel Backups
These backups can then be copied to the new server using whatever method is convenient to you, and restored:
/scripts/restorepkg /path/to/cpmove-${username}.tar.gz
This will create the account and populate it with all the metadata added to it from the source server. If the account was owned by a reseller, and the reseller exists on the new server already, it will be assigned to that account owner, so I recommend migrating any cPanel resellers first.
Filling In The Gaps
The missing homedir data can be brought over using rsync. Here is the general structure for a single account:
rsync -avHPze 'ssh -p${port}' root@${ip}:/home/${username} /home/
This will sync the folder for the user directly onto the new server; no extra files or tarballs needed.
Next, the databases are streamed to the new server:
ssh -C -p${port} root@${ip} "mysqldump ${database}" | mysql ${database}
This command brings over a mysqldump for a specific database directly into stdin for mysql on the new server. This again avoids any bulky temporary data on either server.
Does this speed up migrations?
YES.
This method for cPanel account initial syncs is definitely one of the fastest. The –skiphomedir flag will bypass a large amount of compression and decompression time. It technically also skips a lot of network transfer time for copying the .tar.gz file, but this is re-used by the rsync function, and we use -z to compress compressable files for that transfer.
The –dbbackup=schema flag avoids all of the compression/decompression associated with the mysql backups as well. The mysqldump is still used, as is the network transfer time.
The MySQL line itself is also a time saver over other options. By using ssh -C, the highly compressable plaintext from mysqldump is made exponentially smaller. Temporary files on both sides are also avoided by using the pipeline, as is detailed in my article on this exact topic.
With your initial sync complete, you should be moving on to the testing phase next.
