The (probably) easiest way: Just migrate your website

Here we will just be creating a new server based on a Ubuntu Jammy image and migrate your website/app data as we would do when moving between any two servers.

Pre-requisites

• You have access to control DNS for any domains that point to your server.
• You don't need to, or it would be easy to migrate core components or special server configurations.

Usually, this approach is the easiest. You will have to judge what is right for you.

Set up a new Ubuntu Jammy server and copy your data

With Webdock it is easy to get a fresh LAMP (Apache) or LEMP (Nginx) web server based on Ubuntu Jellyfish. Simply create a server, and you are ready to go

Usually, it is easy to migrate a standard website. Your configuration may differ, so this guide may not be right for you, but in general, the steps are:

1. SSH into your server and go to /var/www/html
2. Become root user by executing “sudo su”

3. Run

    # mysqldump -u USER -pPASSWORD DATABASENAME > mydb.sql
   

4. Run

    # zip -r mysite.zip .
   

5. Now SSH into your new server and go to /var/www/html. Then execute “sudo su” to become root user.

6. Run

    # wget https://mywebsiteaddress.vps.webdock.cloud/mysite.zip
   

   Replace the .cloud alias with your old server alias.

7. Unzip all your data

    # unzip mysite.zip 
    # rm mysite.zip
   

8. Set correct ownership of files

    # chown -R www-data:www-data .
   

9. Import your database

    # mysql -u USER -pPASSWORD DATABASENAME < mydb.sql
   

   Remember this is the username and password on the NEW server.

10. Remember to delete the sql dump

    # rm ./mydb.sql
    

11. Update your website config with the new database name, user, and password.

12. Now point your DNS records to your new server, set your server identity, and re-generate SSL certificates.

Alternatively:

Simply download your files using FTP and export your DB data using PHPMyadmin and then transfer it to your new server. This will be a lot slower than the method above.

Remember to update your website configuration to use the new database credentials, point over your DNS to the new server, and re-generate SSL certificates.

The riskier / harder way: Upgrade your system

This guide works for Webdock LAMP/LEMP server stacks. Your results may vary.

With Webdock it is easy to do this in a safe manner. What you would do is make a new snapshot of your existing webserver. Next, you would create a new server based on this image. Now you have a staging server on which you can run the upgrade and make sure everything works.

Next, you can re-do the steps on your live system if you feel brave, or you can simply take a new snapshot of your staging server and use that to restore your live server. If you have done everything correctly, you should now see no more than ~2-5 seconds of downtime while your live server reboots after being restored.

Start the upgrade

All commands shown here are run as root. If you are logged in as a non-root sudo user, then simply run "sudo su" to become root, or prepend sudo before each command shown below.

We are opening port 1022 as when you are doing the upgrade over SSH the upgrade tool will open an emergency SSH connection on that port in case anything goes wrong.

# apt update; apt upgrade -y; apt install update-manager-core -y; ufw allow 1022; do-release-upgrade -d;

Once the first point release of Ubuntu Focal has been released, you should omit the -d switch to do-release-upgrade as otherwise you may get an error and it will refuse to start the upgrade.

If during the upgrade you are prompted about what to do about config files, e.g. for Nginx/Apache or PHP-FPM, just hit enter / accept defaults (keep existing configuration).

If you get the message

# do-release-upgrade -d
Checking for a new Ubuntu release
Please install all available updates for your release before upgrading.

Then execute

# apt-get dist-upgrade

And reboot, followed by

# do-release-upgrade -d

In order to start the upgrade

Answer the questions on-screen

Continue running under SSH? 

This session appears to be running under ssh. It is not recommended 
to perform an upgrade over ssh currently because in case of failure it 
is harder to recover. 

If you continue, an additional ssh daemon will be started at port 
'1022'. 
Do you want to continue? 

Continue [yN] <-- y

Starting additional sshd 

To make recovery in case of failure easier, an additional sshd will 
be started on port '1022'. If anything goes wrong with the running 
ssh you can still connect to the additional one. 
If you run a firewall, you may need to temporarily open this port. As 
this is potentially dangerous it's not done automatically. You can 
open the port with e.g.: 
'iptables -I INPUT -p tcp --dport 1022 -j ACCEPT' 

To continue please press [ENTER] <-- ENTER

Third-party sources disabled 

Some third-party entries in your sources.list were disabled. You can 
re-enable them after the upgrade with the 'software-properties' tool 
or your package manager. 

To continue please press [ENTER] <-- ENTER

Here you can hit d to see which packages will be removed from the system. It is generally a good idea to do so, so you know what you might need to re-install later. Hit q to return to the upgrade.

Fetching and installing the upgrade can take several hours. Once the 
download has finished, the process cannot be canceled. 

 Continue [yN]  Details [d] <-- y

 ┌───────────────────────────────────────────────┤ Configuring libc6 ├───────────────────────────────────────────────┐
 │                                                                                                                   │
 │ There are services installed on your system which need to be restarted when certain libraries, such as libpam,    │
 │ libc, and libssl, are upgraded. Since these restarts may cause interruptions of service for the system, you will  │
 │ normally be prompted on each upgrade for the list of services you wish to restart.  You can choose this option    │
 │ to avoid being prompted; instead, all necessary restarts will be done for you automatically so you can avoid      │
 │ being asked questions on each library upgrade.                                                                    │
 │                                                                                                                   │
 │ Restart services during package upgrades without asking?                                                          │
 │                                                                                                                   │
 │                                  <Yes>                                     <No>                                   │
 │                                                                                                                   │
 └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

On the next prompt, just hit OK and then choose an LXD version to track, if you use nested LXD.

Configuration file '/etc/sudo.conf'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sudo.conf (Y/I/N/O/D/Z) [default=N] ? <-- ENTER

Configuration file '/etc/sudoers'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sudoers (Y/I/N/O/D/Z) [default=N] ? <-- ENTER

If you have Redis installed, you will be asked this question:

Configuration file '/etc/redis/redis.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** redis.conf (Y/I/N/O/D/Z) [default=N] ? <-- ENTER

 ┌────────────────────────────────────────────────────────────────┤ Configuring openssh-server ├────────────────────────────────────────────────────────────────┐                          
 │ A new version (/tmp/tmp.KWWctRFm5L) of configuration file /etc/ssh/sshd_config is available, but the version installed currently has been locally modified.  │                          
 │                                                                                                                                                              │                          
 │ What do you want to do about modified configuration file sshd_config?                                                                                        │                          
 │                                                                                                                                                              │                          
 │                                                     install the package maintainer's version                                                                 │                          
 │                                                     keep the local version currently installed                                                               │                          
 │                                                     show the differences between the versions                                                                │                          
 │                                                     show a side-by-side difference between the versions                                                      │                          
 │                                                     show a 3-way difference between available versions                                                       │                          
 │                                                     do a 3-way merge between available versions                                                              │                          
 │                                                     start a new shell to examine the situation                                                               │                          
 │                                                                                                                                                              │                          
 │                                                                                                                                                              │                          
 │                                                                            <Ok>                                                                              │                          
 │                                                                                                                                                              │                          
 └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Next, you can hit d to see which packages will be removed from the system. It is generally a good idea to do so, so you know what you might need to re-install later. Hit q to return to the upgrade.

Remove obsolete packages? 

78 packages are going to be removed. 

 Continue [yN]  Details [d] <--y

Restart required 

To finish the upgrade, a restart is required. 
If you select 'y' the system will be restarted. 

Continue [yN] <--y

You will now be disconnected. You can ping your server to watch when it comes back up. A Webdock server should come up in less than 10 seconds.

Close the firewall port we opened earlier

# ufw deny 1022

Please use sudo if you are logged in as a non-root user.

Your server is now upgraded!

Your server is now upgraded and you should test that everything works. You can check the Ubuntu version by executing:

# lsb_release -a

If you encounter any problems or inaccuracies in this guide, please be in touch with Webdock Support.

We can upgrade your server for you

Be in touch with Webdock support and we will sort out a custom Service Level Agreement that works for you!