This blog is about how to use BountySite for site migrations.
In my previous blog, we saw how to configure backup. We will use the same site and migrate to another service provider. In this case, we will migrate to a VPS.
New Hosting Account creation
We are going to migrate nsite.eseckraft.com to a dedicated VPS. We can create new FTP username and password or use previously existing credentials
It is a good practice to lower DNS TTL of website to 5min, just in case something goes wrong. Perhaps a missing php module! Though windows DNS cache doesn't respect DNS TTL, but it is still better.
Migrate files and database
Files can be uploaded to the new account, by simply changing backup configuration and performing a restore.
Run latest Backup
We will schedule a backup first, to get the latest version of the site on backup.
Change FTP Host
We can change the FTP hostname with Configure Backup, by going to Sidebar -> Manage sites and backups -> Configure Backup.
The new host supports FTPS, and is running on port 21. Hence, no other change to be made apart from FTP Hostname.
To be able to finish submitting the form, we need to enter the username and password, and validate by clicking on Verify FTP Details, to confirm that the credentials are working fine on new hosting account. We can now click Next and Finish the form.
To copy files to the new server, we will perform a restore, by going to Sidebar - > Manage sites and backup -> File Browser.
We will pick the latest version "2019-02-01" for restore, by clicking on Restore button. BountySite will first perform a pre-restore backup, which is going to be empty files on the new account. It will update backup repository with empty directory, and then initiate a differential restore, which in this case, is all files from previous snapshot. The latency between storage node and new hosting account is about 150ms. Restore took about 1hr to complete, at the rate of about 1file/second, with 3K files.
I encountered issues in creating same database credentials on new account. The new host had character limitation of 16, for username and password. Also we cannot MysqlOverPHPS, as we have not yet switched the DNS entry yet. Since, this is our managed VPS, we control firewall rules, and will open firewall for storage node to connect to new hosting server's mysql port.
We do the following:-
- Create a new database, user and password(with < 16chars), on new hosting account
- On BountySite control panel, we download database of latest revision. Sidebar -> Manage sites and backups -> File Browser. On top right side, choose database from dropdown
- Clicking on download initiates a download service, which happens behind the scenes. A download URL with password is sent over email, along with notification message.
- Open the download URL, and enter password as mentioned. Zip file download will be initiated.
- The zip file is password protected with FTP password of your account. Unzip the file with FTP password, to extract db files.
- Using the sql, we will perform a restore, with phpMyAdmin. Ghosh! we are thrown with an error message.
- We need to edit sql file and replace utf8mb4_unicode_520_ci with utf8mb4_unicode_ci. Then we will upload again.
- Since, our dbname has changed, we need to edit config file, which in our case is /wp-config.php on new account
- For future DB backup to work, we need to allow storage node to backup data. First we need the IP address of storage node. To get that we will go to DB Backup(Sidebard -> Manage sites and backup -> DB Backup), where the IP address is mentioned, that is to be used for Remote Mysql.
- Using the IP address obtained from above, allow IP in firewall rules
- Also allow Remote Mysql host for that IP.
- We can now delete the old database, by going to DB Backup and deleting.
Now, lets switch the domain name to new IP. And confirm by a lookup and browse.
This migration got tricky as we are moving from CPanel to a customized VPS account. CPanel to CPanel migration should be seamless, and with storage node closer(within in 50ms circle, as in most locations within US/UK/Canada), it should take much lesser time to complete migration. More blogs on migrations and backup to continue.