Skip to main content

Backup WordPress Database And Filesystem Data On Linux With Scripts

f you’re like me, you run a WordPress blog and are terrified of the thought of something going wrong.  With core updates, theme updates, plugin updates, and server component updates, there is a lot of room for error.  This is where a WordPress backup could help ease your mind.
WordPress recommends taking a backup of your blog before any of these are done and there are even some popular plugins that will do this for you.  For example, you could use the popular UpdraftPlus or similar, but I believe there is room for error in those as well.  While I could be wrong, I think WordPress must be in good shape for backup plugins to be successful.
The alternative would be to create your own backup scripts that run on a cron schedule.  We’re going to see how to do this for WordPress instances running on a Linux machine.

Creating the Backup Script

There are two core components that need to be backed up in case of a catastrophe.  You need to backup the WordPress files which can include plugins, themes, and uploads, as well as the data that resides on your database.
Create the following backup.sh script somewhere on your server:

#!/bin/bash
 
TODAY=`date '+%Y%m%d'`
TEMP_DIR=/home/nraboy/backups/temp
 
BACKUP_NAME="blog"
DB_NAME="DATABASE_NAME_HERE"
DB_USER="DATABASE_USERNAME_HERE"
DB_PASS="DATABASE_PASSWORD_HERE"
SITE_PATH=/var/www
 
echo "Starting Backup..."
 
mkdir $TEMP_DIR
 
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME > $TEMP_DIR/database.sql
 
tar --exclude="updraft" -zcf $TEMP_DIR/files.tar.gz $SITE_PATH
 
tar -zcf $BACKUP_NAME-$TODAY.tar.gz -C $TEMP_DIR .
 
rm -Rf $TEMP_DIR
 
echo "Backup Complete [$(du -sh $BACKUP_NAME-$TODAY.tar.gz | awk '{print $1}')]"


So what is happening in the above script?
First we are obtaining the date which will be used when naming our backups.  In my scenario I had never planned to take more than one backup per day.  We also need to define a temporary directory which will contain each of the backup components.
The next section we define the backup name which you can use to identify the backup.  The end result will be a file named something like blog-20161230.tar.gz, based on what I have in the script.
The SITE_PATH should be the location where your WordPress blog or website resides on the server.  A common location is the /var/www directory if you’re unsure.  Within the path there should be a file called wp-config.php which contains the database information.
Everything so far was initialization.
When the script runs, the temporary directory will be created and the MySQL database will be dumped into a SQL file.  This dump contains table structure and data.  Once the database is dumped all the WordPress files are archived into a tar file, excluding directories that we define.  Excluded directories could be other backup directories, cache directories, etc.
With two files in our temporary directory, we can create our single and final tar archive from them.
Now that you have a script that will create and bundle a file and database backup, you need to configure it to run on a schedule using crontab.
Execute crontab e on your server and add the following line:

The above line will execute our backup script every day at 2:00am.  You’ll end up with a backup in the current working directory unless you specify the output directory in our script, which we did not.
We could easily do something like this in our script:

tar -zcf /home/nraboy/$BACKUP_NAME-$TODAY.tar.gz -C $TEMP_DIR .

In the event that something bad happens and you need to restore your WordPress blog from this backup, you could extract the files and replace what you currently have, then import the SQL file into MySQL.  This is a full snapshot, not an incremental backup.

Conclusion

While there are many free and paid WordPress backup plugins available, sometimes it takes a good old fashioned Linux script to make you feel at ease about your website or blog.  I personally only take backups on a weekly or monthly basis, but your needs may be different than mine.  Just note that because these are not incremental, they may take a bit of space on your hard drive.

Comments

Popular posts from this blog

Python and Parquet Performance

In Pandas, PyArrow, fastparquet, AWS Data Wrangler, PySpark and Dask. This post outlines how to use all common Python libraries to read and write Parquet format while taking advantage of  columnar storage ,  columnar compression  and  data partitioning . Used together, these three optimizations can dramatically accelerate I/O for your Python applications compared to CSV, JSON, HDF or other row-based formats. Parquet makes applications possible that are simply impossible using a text format like JSON or CSV. Introduction I have recently gotten more familiar with how to work with  Parquet  datasets across the six major tools used to read and write from Parquet in the Python ecosystem:  Pandas ,  PyArrow ,  fastparquet ,  AWS Data Wrangler ,  PySpark  and  Dask . My work of late in algorithmic trading involves switching between these tools a lot and as I said I often mix up the APIs. I use Pandas and PyArrow for in-RAM comput...

Ingesting IoT Sensor Data Into S3 With an RPI3

StreamSets Data Collector Edge is a lightweight agent used to create end-to-end data flow pipelines. We'll use it help stream data collected from a sensor. Due to the increasing amount of data produced from outside source systems, enterprises are facing difficulties in reading, collecting, and ingesting data into a desired, central database system. An edge pipeline runs on an edge device with limited resources, receives data from another pipeline or reads the data from the device, and controls the device based on the data. StreamSets Data Collector (SDC) Edge, an ultra-lightweight agent, is used to create end-to-end data flow pipelines in StreamSets Data Collector and to run the pipelines to read and export data in and out of systems. In this blog, StreamSets Data Collector Edge is used to read data from an air pressure sensor (BMP180) from an IoT device (Raspberry Pi3). Meanwhile, StreamSets Data Collector is used to load the data into Amazon's Simple Storage Service ...

Real-Time Talk: Windows 10 IoT Core Background Tasks and ASP.NET Core Web Apps

Display useful information from your Windows 10 IoT Core application in an ASP.NET Core web app, essential for integrating IoT data into a solution. Windows 10 IoT background task talk with a web application using WebSockets. Problems As my path to this solution has been troublesome, I am listing here the main problems I faced so my dear readers have a better idea of dead-end streets along the way: I was not able to make the ASP.NET Core web application run under a Windows 10 IoT background service. I found no information about when or if it will be supported in the near future. ASP.NET MVC and ASP.NET Core have different SignalR implementations. I was not able to make a SignalR client for .NET Core work with SignalR hosted on a web application. I was able to make things work by directly using a WebSocket. It’s not as nice a solution as I had in my mind, but it works until things get better. Making the Background Task and Web Application Talk I worked out sim...