diff --git a/docs/manual/backing-up-the-server/index.md b/docs/manual/backing-up-the-server/index.md
index 2d7786b43..6a82d6762 100644
--- a/docs/manual/backing-up-the-server/index.md
+++ b/docs/manual/backing-up-the-server/index.md
@@ -1,5 +1,5 @@
 The following shell commands can be used for database backup and restore on a
-running *PostgreSQL* server in an Airtime system.
+running *PostgreSQL* server in an Libretime system.
 
 You can dump the entire database to a zipped file with the combination of the
 **pg\_dumpall** command and **gzip**. The **pg\_dumpall** command is executed
@@ -11,7 +11,7 @@ is separated from the **gzip** command with the pipe symbol.
 This command can be automated to run on a regular basis using the standard
 **cron** tool on your server.
 
-When restoring a production database on a cleanly installed Airtime system, it
+When restoring a production database on a cleanly installed Libretime system, it
 may be necessary to drop the empty database that was created during the new
 installation, by using the **dropdb** command. Again, this command is executed
 with **sudo** as the user *postgres*: 
@@ -19,7 +19,7 @@ with **sudo** as the user *postgres*: 
     sudo -u postgres dropdb airtime
 
 This **dropdb** command above is necessary to avoid 'already exists' errors on
-table creation when overwriting an empty Airtime database in the next step.
+table creation when overwriting an empty Libretime database in the next step.
 These errors might prevent some data from being restored, such as user account
 data.
 
@@ -29,19 +29,19 @@ command as the *postgres* user:
     gunzip airtime-backup.gz
     sudo -u postgres psql -f airtime-backup
 
-You should now be able to log in to the Airtime web interface in the usual way.
+You should now be able to log in to the Libretime web interface in the usual way.
 
 For safety reasons, your regular database backups should be kept in a directory
 which is backed up by your storage backup tool of choice; for example, the
 */srv/airtime/database\_backups* directory. This should ensure that a storage
-restore can be made along with a matching and complete version of the Airtime
+restore can be made along with a matching and complete version of the Libretime
 database from the day that the storage backup was made. 
 
 Storage backup
 --------------
 
-Backing up the Airtime database with **pg\_dumpall** will not back up the
-Airtime media storage server, which is likely to need a great deal more backup
+Backing up the Libretime database with **pg\_dumpall** will not back up the
+Libretime media storage server, which is likely to need a great deal more backup
 space. Creating a compressed file from hundreds of gigabytes of storage server
 contents is likely to take a very long time, and may have little benefit for the
 amount of CPU power used, if the media files are already stored in a highly
@@ -49,8 +49,8 @@ compressed format. It is also impractical to copy very large backup files across
 the network on a daily basis.
 
 Instead, it is preferable to use an incremental backup technique to synchronize
-the production Airtime server storage with a backup server each day or night. If
-the backup server also contains an Airtime installation, it should be possible
+the production Libretime server storage with a backup server each day or night. If
+the backup server also contains an Libretime installation, it should be possible
 to switch playout to this second machine relatively quickly, in case of a
 hardware failure or other emergency on the production server.