Simple Solutions to Complex Problems

for later reference by

Here's an attempt to collect essential commands for backing up instances of various types. Following this guide should cover you in any unforeseen event, a compromised server for example. The procedures are very easy and can be performed in less than an hour. As the procedures followed carefully won't do any harm, it's a good idea to perform them and then spend a bit more time learning the details about restoring your site afterward.

Be advised that the measures listed here may be insufficient or not valid in your case, so please familiarize yourself with the latest information before relying completely on any one piece of advice. Consult the references in this article, update procedures or the general documentation related to the software you may be using.1, 2, 3, 4, 5

These procedures were applied to Pleroma, Plume, WriteFreely, and Friendica instances that rely on Mariadb or Postgresql and Nginx. Data was archived, copied to a local machine for safekeeping then transferred to a different server where the instances were restored successfully. I've chosen to use nginx 6 on my instances. I'm unfamiliar with procedures for backing up an Apache directory 7 .

Procedure map

  1. SSH into working machine terminal
    • If the instance runs as its own user, then login to that user
    • Change into root of the working directory
    • Create the .bk directory
    • 1.1 Archive the working folder into a .bk directory
    • 1.2 Dump the database – append the dump file to .bk directory
    • 1.3 Append configuration (instance' files & reverse proxy) into .bk directory
  2. Save the data to a safe location (a local machine or another VPS)
    • Open terminal on the second machine
    • Create the .bk directory
    • Copy from remote machine to the second (backup or place of restoration)
    • Restore to the new location (procedures outside the scope of this article)

1.1 Backup the Instance configuration files

Login to the user that runs the instance 8, 9 . Change into the root directory for the instance.

sudo su - writefreely
cd ~

List the contents of the root directory where the working directory exists. Identify the folder and special files that you need to backup. In the case of friendica, config/local.config.php and .htaccess file (apache installations) are inside the friendica folder, so backing up the entire folder is wise. When restoring, the folders and content to be re-built by an update can always be stripped before uploading, leaving the configuration and image files in the folders.

In this example, the friendica instance runs as root in /var/www


1.2 Dump the Database

Identify if your instance relies on MariaDB or PostgreSQL, then proceed to use the dump command for your type of database. Confirming this detail is useful even when the type of database is known. To run the dump command, the database password is also required. To identify the database type, the database names and database users which the instance relies on by doing something like this.

Make a note of the user and database information shown in the terminal, after running these commands.

1.2.1 MySQL or MariaDB

Login to mysql to identify the databases

mysql -u root -p

Now, from the MariaDB prompt

MariaDB [(none)]> SHOW DATABASES;
MariaDB [(none)]> SELECT user,host FROM mysql.user;
MariaDB [(none)]> EXIT;

Once identified, use the dump command for mysql 10 . Do this in the directory where you saved the tar.gz earlier, i.e. “NAMEOFINSTANCE_bk”

cd /var/www/friendica_bk
mysqldump --no-tablespaces -u [username] -p [database name] > [database name].sql
mysqldump --no-tablespaces -u friendicauser -p friendica > friendica_db.msql.sql

1.2.2 Postgresql

Identify the databases. Become root. Login to postgres user. Then login to postgres prompt.

sudo -s            
su - postgres       
psql -U postgres

Now, from the postgres prompt

postgres=> \l

Once identified, use the dump command for postgresql 11

sudo -Hu postgres pg_dump -d <pleroma_db> --format=custom -f </path/to/backup_location/pleroma.pgdump>

1.3 Configuration files & Reverse proxy

Apply this to any config files unless these were already included in the instance folder tar.gz. In the case of friendica, you'd also want


(where 7.x is the php version)

Whatever it is you are saving, change into the relevant directory

cd /etc/nginx/sites-available

Identify the name of the nginx file. You might want to nano to examine it. Then tar it or copy it to the NAMEOFINSTANCE_bk directory

sudo tar -pcvzf /var/www/friendica_bk/nginx.sites-available.tar.gz friendica

There should be three items in the NAMEOFINSTANCE_bk directory.

ls /var/www/friendica_bk
friendica.tar.gz  friendica_db.msql.sql  nginx.sites-available.tar.gz

2. Transfer archives to a second machine

Open a terminal for the machine where the backup will be saved. Create a backup location directory, NAMEOFINSTANCE_bk Note: SSH must be working to allow the local terminal to call the data archived on the remote machine.

In this command, the remote machine absolute path of the archived files appears first. The local 'save location' appears second. A wildcard* can be used (eg. the first command) to securely copy all the archives created in steps 1.1~1.3 above.


scp user@ ~/PATH_TO_DIR/writefreely_bk

scp user@ ~/PATH_TO_DIR/writefreely_bk

scp user@* ~/PATH_TO_DIR/friendica_bk

MySQL v.8 – tags not working at time of publication WF 335 #WriteFreely #plume #pleroma #friendica #nginx #mariadb #mysq #postgresql Work by licensed under CC BY-SA 4.0 Image credit: Fediverse icons by Gadgeteer under CC BY-NC-SA 4.0


1 Friendica guthub, releases 2 Friendica github, update procedures 3 Pleroma documentation, backup and restore 4 Plume documentation 5 WriteFreely, new releases 6 Nginx, official 7 Apache, backup and restore 8 Write Freely updating 9 Archive using tar 10 Mysql MariaDB 11 PostgreSQL