Strapi: Backing up data in a Strapi installation

ARJUNA’S CODING JOURNAL: I have started writing notes to myself when I code something and it works well, so that I can refer to it later. I figure in blog form they will also help others.

HOW TO THINK ABOUT BACKING UP A STRAPI INSTALLATION

I deployed Strapi to my Linode server. If you want to learn how to deploy Strapi to any cloud based hosting service you can read my blog post

Deploying Strapi Version 4, on Linode or any cloud host using PM2 via Github and accessing it from aSSL domain using Lets Encrypt and NGINX reverse proxy.

After deploying the Strapi application to the cloud my client entered a fair amount of data. Then I got user testing feedback. Based on this feedback i am to make changes to my Strapi application. However I did not want to lose any of the data that my client has entered. So I thought that I should back up the Strapi installation online to my local machine.

This article is about how I did that. The Strapi documentation is sorely lacking at this time. I had to experiment and figure out how to do this, I did not find any instructions online.

What I learned is that 2 items need to be backed up to backup the strapi data:

1. The database. In my case I deployed Strapi with a postgresql database so that had to be backed up and restored on my local machine.
2. The actual Strapi files. You cannot just backup the database and restore it and do a fresh install of Strapi. That does not work. Strapi actually creates folders under /src/api for every content type that you create.

Once each of these are backed up and restored properly you will have a full running backup or clone of your Strapi installation.

In summary, I have deployed my strapi V4 application using postgresql. So now my deployed application has some content types set up with data entered. Now I need to make some changes to the application. Since my deployed strapi sits on the server, I need to make those changes locally and re build and re upload to the server. However my deployed application on the server is what has the real data. So I need to transfer that data to my local install. At this stage I am not sure if I will lose my data if I rebuild and reupload because theoretically the data sits in the database and should not be affected by the Strapi re build. However consider the scenario where we change the structure of the content types locally, rebuild and reupload, this is likely to break the system. Therefore the need to get the data from the deployed version of strapi to the local version.

BACKING UP THE POSTGRESQL FOR THE STRAPI INSTALL THAT WE WANT TO COPY

Ssh into your server to the command prompt and then do

Connect to PostgreSQL

sudo su - postgres

Open Postgres prompt

psql

Check connection info (from within the postgres prompt)

\conninfo

You should see

You are connected to database “postgres” as user “postgres” via socket in “/var/run/postgresql” at port “5432”.

To see the list of databases do

\l 

The purpose of doing the above steps was to see the list of databases on the server so that you can note down the name of the strapidatabase. Note it down.

To quit the psql command line do

\q

To create a backup of the database on the server we need to be logged in as the postgresql user and we do this as follows

sudo su - postgres

From the above postgres prompt now lets backup the strapi database

pg_dump nameOfDatabase > nameOfDDatabase.sql

Offcourse replace nameOfDatabase with that of your strapi database.

This creates the .sql file. I found this file sitting in /var/lib/postgresql and once in my current directory and I am working in Ubuntu. Where this file is saved by the pg_dump command varies you could google that for your platform.

I moved this file to my home directory so that I could download it to my local machine

sudo mv /var/bin/postgresql/nameOfDatabase.sql /home/myusername

In the above again the nameOfDatabase.sql has to be that of your database and should match the .sql that you generated in the above steps and myusername is your username in your server so that you can put this in your home directory which normally has the permission for you to download files from.

Now download the .sql file using scp as follows

scp myusername@serveripaddress:nameOfDatabase.sql .

The above command reads copy the file from myusername@serveripaddress, the file to be copied is nameOfDatabase (Since it is sitting in the default home directory of the user we are not specifying a path to this file on the server) and transfer it to the current local directory. The above command is to be given from the local machine not from the ssh’d terminal on the server.

We now have backed up the strapi postgres database that from the strapi install that was deployed on our server and we have it downloaded on our local machine.

The next order of business is to Restore this file on our local machine and if all goes well we should have an exact copy of the data structure and data on the server, on our local machine.

RESTORE THE BACKED UP POSTGRES DATABASE TO ANOTHER LOCATION

Now that we have the mydatabase.sql file created by pg_dump process downloaded to our local machine. We will restore the database on our local machine. These steps can be followed to restore the database on any machine.

First lets switch the postgres user on the local machine

sudo su - postgres

Now lets get a list of all the databases

psql

Then from the postgres command line that the above command invokes

\l

Now we get a list of all the databases.

If this database already exists locally we should delete it because we are going to import another database with the same name. If it does not exist ignore this step.

DROP DATABASE nameOfDatabase;

Now lets see that the database is dropped by listing all the databases.

\l

Before restoring the database that we backed up using pg_dump we have to create an empty database with the same name.

CREATE DATABASE nameOfDatabase;

Lets see that the database is added by listing all of the databases.

\l

If all is good thus far let us proceed to restore the database from the .sql file we generated using pg_dump.

\q

The above takes you out from the psql command line to the postgresql user prompt and from there do

psql nameOfDatabase < nameOfDatabase.sql

It may be possible to just stay in the psql command line and just do nameOfDatabase < nameOfDatabase.sql

but I haven’t tried it.

Also you must provide the path to the .sql file in the above command like /home/arjuna/nameOfDatabase.sql

Now the database will be restored and you should see a whole bunch of output on the terminal as the database is restored one command at a time from the .sql file.

This restore includes the database structure and the data.

BACKING UP AND RESTORING THE STRAPI CODEBASE

First I had done an install of Strapi on my local machine and developed the content-types and when I was ready with my strapi I realized that no could access it or enter data into it unless it were deployed online. So I deployed it online, the link to the post showing how I did that is posted above I will post it here for your convenience

Deploying Strapi Version 4, on Linode or any cloud host using PM2 via Github and accessing it from aSSL domain using Lets Encrypt and NGINX reverse proxy.

After this was deployed my client started entering data online. Very soon I got user testing feedback and I had to change my Strapi application structure. Those changes would be done on my local install of Strapi and then pushed to the cloud production install using git. However I thought that I ran the risk of overwriting or deleting the data that had been entered in the production version. So I needed to backup the data and ensure that it works by restoring on my local machine.

The way to approach this is via git which allows “branches” to try out experimental features. So what I did was to create a branch on my production install of Strapi on the cloud.

SSH into a terminal on the cloud. Assuming git is installed on the cloud version of Strapi.

Create a branch of the code by doing

git checkout -b branchname

You can do the following to see your branches

git branch -a

Now that we have a branch on the production install of Strapi we want to push this to github which we are treating as a central repository, just as a convention.

git push -u origin branchname

The -u is shorthand for — sct-upstream which needs to be inserted into the command the first time we are pushing a repo to github.

This essentially pushes all of the strapi code from the production cloud install of strapi to github.

Now go to github and use the GUI to switch to the newbranch. If you go to the /src/apis folder, here you will see each of the content types listed. If they are here this means that you have successfully transferred your production strapi install to github.

You can check your remote branches by doing

git branch -r

Now you simply go to your local install and fetch the branch from the github repo.

git fetch remoterepository remotebranchname

Now you can switch to this branch on your local machine

git checkout remotebranchname

We are doing this on the local machine and this switches to the newly fetched branch. Then we can go to /src/apis and see if our content types are listed there. If they are all is good. We can merge the fetched changes by doing

git checkout master
git merge remotebranchname

The above first switches to the master branch and then merges the remotebranchname into master.

If the above is confusing, study up on git and you can do this in your own way. The concept is that in order to backup your strapi installation you also need to backup the entire strapi codebase and this can be done by creating a branch on the production cloud install of strapi, pushing it to github and from there pulling it to your local machine. Viola you have the production changes on your local machine.

If you have any questions, don’t understand something or are stuck somewhere please feel free to reach out to me Arjuna at brahmaforces@gmail.com. Happy coding!