Monthly Archives: October 2015

Linux

Install Bacula Server on Ubuntu 14.04

Leave a comment

How To Install Bacula Server on Ubuntu 14.04

Introduction

Bacula is an open source network backup solution that allows you create backups and perform data recovery of your computer systems. It is very flexible and robust, which makes it, while slightly cumbersome to configure, suitable for backups in many situations. A backup system is an important component in most server infrastructures, as recovering from data loss is often a critical part of disaster recovery plans.

In this tutorial, we will show you how to install and configure the server components of Bacula on an Ubuntu 14.04 server. We will configure Bacula to perform a weekly job that creates a local backup (i.e. a backup of its own host). This, by itself, is not a particularly compelling use of Bacula, but it will provide you with a good starting point for creating backups of your other servers, i.e. the backup clients. The next tutorial in this series will cover creating backups of your other, remote, servers by installing and configuring the Bacula client, and configuring the Bacula server.

If you’d rather use CentOS 7 instead, follow this link: How To Install Bacula Server on CentOS 7.

Prerequisites

You must have superuser (sudo) access on an Ubuntu 14.04 server. Also, the server will require adequate disk space for all of the backups that you plan on retaining at any given time.

If you are using DigitalOcean, you should enable Private Networking on your Bacula server, and all of your client servers that are in the same datacenter region. This will allow your servers to use private networking when performing backups, reducing network overhead.

We will configure Bacula to use the private FQDN of our servers, e.g. bacula.private.example.com. If you don’t have a DNS setup, use the appropriate IP addresses instead. If you don’t have private networking enabled, replace all network connection information in this tutorial with network addresses that are reachable by servers in question (e.g. public IP addresses or VPN tunnels).

Let’s get started by looking at an overview of Bacula’s components.

Bacula Component Overview

Although Bacula is composed of several software components, it follows the server-client backup model; to simplify the discussion, we will focus more on the backup server and the backup clients than the individual Bacula components. Still, it is important to have cursory knowledge of the various Bacula components, so we will go over them now.

A Bacula server, which we will also refer to as the “backup server”, has these components:

  • Bacula Director (DIR): Software that controls the backup and restore operations that are performed by the File and Storage daemons
  • Storage Daemon (SD): Software that performs reads and writes on the storage devices used for backups
  • Catalog: Services that maintain a database of files that are backed up. The database is stored in an SQL database such as MySQL or PostgreSQL
  • Bacula Console: A command-line interface that allows the backup administrator to interact with, and control, Bacula Director
Note: The Bacula server 
components don't need to run on the same server, but they all work 
together to provide the backup server functionality.

A Bacula client, i.e. a server that will be backed up, runs the File Daemon (FD) component. The File Daemon is software that provides the Bacula server (the Director, specifically) access to the data that will be backed up. We will also refer to these servers as “backup clients” or “clients”.

As we noted in the introduction, we will configure the backup server to create a backup of its own filesystem. This means that the backup server will also be a backup client, and will run the File Daemon component.

Let’s get started with the installation.

Install MySQL

Bacula uses an SQL database, such as MySQL or PostreSQL, to manage its backups catalog. We will use MySQL in this tutorial.

First, update apt-get:

  • sudo apt-get update

Now install MySQL Server with apt-get:

  • sudo apt-get install mysql-server

You will be prompted for a password for the MySQL database administrative user, root. Enter a password, then confirm it.

Remember this password, as it will be used in the Bacula installation process.

Install Bacula

Install the Bacula server and client components, using apt-get:

  • sudo apt-get install bacula-server bacula-client

You will be prompted for some information that will be used to configure Postfix, which Bacula uses:

  • General Type of Mail Configuration: Choose “Internet Site”
  • System Mail Name: Enter your server’s FQDN or hostname

Next, you will be prompted for information that will be used to set up the Bacula database:

  • Configure database for bacula-director-mysql with dbconfig-common?: Select “Yes”
  • Password of the database’s administrative user: Enter your MySQL root password (set during MySQL installation)
  • MySQL application password for bacula-director-mysql: Enter a new password and confirm it, or leave the prompt blank to generate a random password

The last step in the installation is to update the permissions of a script that Bacula uses during its catalog backup job:

  • sudo chmod 755 /etc/bacula/scripts/delete_catalog_backup

The Bacula server (and client) components are now installed. Let’s create the backup and restore directories.

Create Backup and Restore Directories

Bacula needs a backup directory—for storing backup archives—and restore directory—where restored files will be placed. If your system has multiple partitions, make sure to create the directories on one that has sufficient space. Continue reading Install Bacula Server on Ubuntu 14.04 →

Linux

Redirect www to Non-www with Nginx on Ubuntu 14.04

Leave a comment

Introduction

When you have your web site or application up and running behind a domain, it is often desirable to also allow your users access to it via the plain domain name and the www subdomain. That is, they should be able to visit your domain with or without the “www.” prefix, e.g. example.com or www.example.com, in a web browser, and be presented with the same content. While there are a variety of ways to set this up, the best solution, for consistency and SEO considerations, is to choose which domain you prefer, plain or www, and redirect the other one to the preferred domain. This type of redirect is called a Permanent Redirect, or “301 redirect”, and can be easily set up by properly configuring your DNS resource records and web server software.

This tutorial will show you how to redirect a www URL to non-www, e.g. www.example.com to example.com, with Nginx on Ubuntu 14.04. We will also show you how to redirect in the other direction, from a non-www URL to www. The CentOS 7 version of this tutorial is available here.

If you want to perform this type of redirect with Apache as your web server, you should follow this tutorial instead: How to Redirect www to non-www with Apache on Ubuntu 14.04.

Prerequisites

This tutorial assumes that you have superuser privileges, i.e. sudo or root, on the server that is running Nginx. If you don’t already have that set up, follow this tutorial: Initial Server Setup on Ubuntu 14.04.

It is assumed that you have Nginx installed. If you do not already have this set up, there are several tutorials on the subject under the Nginx tag.

You must be able to add records to the DNS that is managing your domain. If you do not already have a domain, you may purchase one from a domain registrar, and manage it with the registrar’s DNS or DigitalOcean’s DNS. In this tutorial, we will use the DigitalOcean DNS to create the necessary records.

Let’s get started by configuring your DNS records.

Configure DNS Records

In order to set up the desired redirect, www.example.com to example.com or vice versa, you must have an A record for each name.

Open whatever you use to manage your DNS. For our example, we’ll use the DigitalOcean DNS.

If a domain (also known as a zone) record does not already exist, create one now. The hostname should be your domain, e.g. example.com, and the IP address should be set to the public IP address of your Nginx server. This will automatically create an A record that points your domain to the IP address that you specified. If you are using another system to manage your domain, you may need to add this manually.

Next, add another A record with “www” as the hostname (or “www.example.com” if the partial subdomain doesn’t work), and specify the same IP address.

When you have created both records, it should look something like this:

Required A records

Note: This will also work with CNAME records, as long as the canonical name’s A record refers to the IP address of your Nginx web server.

Now your server should be accessible via the www and non-www domain, but we still need to set up the redirect. We’ll do that now. Continue reading Redirect www to Non-www with Nginx on Ubuntu 14.04 →

Linux

Initial Server Setup with Debian 8

Leave a comment

Introduction

When you first create a new Debian 8 server, there are a few configuration steps that you should take early on as part of the basic setup. This will increase the security and usability of your server and will give you a solid foundation for subsequent actions.

Step One — Root Login

To log into your server, you will need to know your server’s public IP address and the password for the “root” user’s account. If you have not already logged into your server, you may want to follow the first tutorial in this series, How to Connect to Your Droplet with SSH, which covers this process in detail.

If you are not already connected to your server, go ahead and log in as the root user using the following command (substitute the highlighted word with your server’s public IP address):

  • ssh root@SERVER_IP_ADDRESS

Complete the login process by accepting the warning about host authenticity, if it appears, then providing your root authentication (password or private key). If it is your first time logging into the server, with a password, you will also be prompted to change the root password.

About Root

The root user is the administrative user in a Linux environment that has very broad privileges. Because of the heightened privileges of the root account, you are actually discouraged from using it on a regular basis. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident.

The next step is to set up an alternative user account with a reduced scope of influence for day-to-day work. We’ll teach you how to gain increased privileges during the times when you need them.

Step Two — Create a New User

Once you are logged in as root, we’re prepared to add the new user account that we will use to log in from now on.

This example creates a new user called “demo”, but you should replace it with a user name that you like:

  • adduser demo

You will be asked a few questions, starting with the account password.

Enter a strong password and, optionally, fill in any of the additional information if you would like. This is not required and you can just hit “ENTER” in any field you wish to skip.

Step Three — Root Privileges

Now, we have a new user account with regular account privileges. However, we may sometimes need to do administrative tasks.

To avoid having to log out of our normal user and log back in as the root account, we can set up what is known as “super user” or root privileges for our normal account. This will allow our normal user to run commands with administrative privileges by putting the word sudo before each command.

Install Sudo

Debian 8 doesn’t come with sudo installed, so let’s install it with apt-get.

First, update the apt package index:

  • apt-get update

Then use this command to install sudo:

  • apt-get install sudo

Now you are able to use the sudo and visudo commands.

Grant Sudo Privileges

To add these privileges to our new user, we need to add the new user to the “sudo” group. By default, on Debian 8, users who belong to the “sudo” group are allowed to use the sudo command.

As root, run this command to add your new user to the sudo group (substitute the highlighted word with your new user):

  • usermod -a -G sudo demo

Now your user can run commands with super user privileges! For more information about how this works, check out this sudoers tutorial.

The next step in securing your server is to set up public key authentication for your new user. Setting this up will increase the security of your server by requiring a private SSH key to log in.

Generate a Key Pair

If you do not already have an SSH key pair, which consists of a public and private key, you need to generate one. If you already have a key that you want to use, skip to the Copy the Public Key step.

To generate a new key pair, enter the following command at the terminal of your local machine (ie. your computer):

  • ssh-keygen

Assuming your local user is called “localuser”, you will see output that looks like the following:

ssh-keygen output
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/localuser/.ssh/id_rsa):

Hit return to accept this file name and path (or enter a new name).

Next, you will be prompted for a passphrase to secure the key with. You may either enter a passphrase or leave the passphrase blank.

Note: If you leave the passphrase blank, you will be able to use the private key for authentication without entering a passphrase. If you enter a passphrase, you will need both the private key and the passphrase to log in. Securing your keys with passphrases is more secure, but both methods have their uses and are more secure than basic password authentication.

This generates a private key, id_rsa, and a public key, id_rsa.pub, in the .ssh directory of the localuser‘s home directory. Remember that the private key should not be shared with anyone who should not have access to your servers!

Copy the Public Key

After generating an SSH key pair, you will want to copy your public key to your new server. We will cover two easy ways to do this.

Option 1: Use ssh-copy-id

If your local machine has the ssh-copy-id script installed, you can use it to install your public key to any user that you have login credentials for.

Run the ssh-copy-id script by specifying the user and IP address of the server that you want to install the key on, like this:

  • ssh-copy-id demo@SERVER_IP_ADDRESS

After providing your password at the prompt, your public key will be added to the remote user’s .ssh/authorized_keys file. The corresponding private key can now be used to log into the server.

Option 2: Manually Install the Key

Assuming you generated an SSH key pair using the previous step, use the following command at the terminal of your local machine to print your public key (id_rsa.pub):

  • cat ~/.ssh/id_rsa.pub

This should print your public SSH key, which should look something like the following:

id_rsa.pub contents
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf [email protected]

Select the public key, and copy it to your clipboard.

Add Public Key to New Remote User

To enable the use of SSH key to authenticate as the new remote user, you must add the public key to a special file in the user’s home directory.

On the server, as the root user, enter the following command to switch to the new user (substitute your own user name):

  • su – demo

Now you will be in your new user’s home directory.

Create a new directory called .ssh and restrict its permissions with the following commands:

  • mkdir .ssh
  • chmod 700 .ssh

Now open a file in .ssh called authorized_keys with a text editor. We will use nano to edit the file:

  • nano .ssh/authorized_keys

Now insert your public key (which should be in your clipboard) by pasting it into the editor.

Hit CTRL-X to exit the file, then Y to save the changes that you made, then ENTER to confirm the file name.

Now restrict the permissions of the authorized_keys file with this command:

  • chmod 600 .ssh/authorized_keys

Type this command once to return to the root user:

  • exit

Now you may SSH login as your new user, using the private key as authentication.

To read more about how key authentication works, read this tutorial: How To Configure SSH Key-Based Authentication on a Linux Server.

Step Five — Configure SSH

Now that we have our new account, we can secure our server a little bit by modifying its SSH daemon configuration (the program that allows us to log in remotely) to disallow remote SSH access to the root account.

Begin by opening the configuration file with your text editor as root:

  • nano /etc/ssh/sshd_config

Here, we have the option to disable root login through SSH. This is generally a more secure setting since we can now access our server through our normal user account and escalate privileges when necessary.

To disable remote root logins, we need to find the line that looks like this:

/etc/ssh/sshd_config (before)
#PermitRootLogin yes

You can modify this line to “no” like this if you want to disable root login:

/etc/ssh/sshd_config (after)
PermitRootLogin no

Disabling remote root login is highly recommended on every server!

When you are finished making your changes, save and close the file using the method we went over earlier (CTRL-X, then Y, then ENTER).

Reload SSH

Now that we have made our changes, we need to restart the SSH service so that it will use our new configuration.

Type this to restart SSH:

  • systemctl restart ssh

Now, before we log out of the server, we should test our new configuration. We do not want to disconnect until we can confirm that new connections can be established successfully.

Open a new terminal window. In the new window, we need to begin a new connection to our server. This time, instead of using the root account, we want to use the new account that we created.

  • ssh demo@SERVER_IP_ADDRESS

You will be prompted for the new user’s password that you configured. After that, you will be logged in as your new user.

Remember, if you need to run a command with root privileges, type “sudo” before it like this:

  • sudo command_to_run

If all is well, you can exit your sessions by typing:

  • exit

Where To Go From Here?

At this point, you have a solid foundation for your Debian 8 server. You can install any of the software you need on your server now.

Sumber: https://www.digitalocean.com/community/tutorials/initial-server-setup-with-debian-8

Linux

Building for Production: Web Applications — Centralized Logging

Leave a comment

Building for Production: Web Applications — Centralized Logging

Introduction

We’re finally ready to set up centralized logging for our production application setup. Centralized logging is a great way to gather and visualize the logs of your servers. Generally, setting up an elaborate logging system is not as important as having solid backups and monitoring set up, but it can be very useful when trying to identify trends or problems with your application.

Centralized Logging Diagram

In this tutorial, we will set up an ELK stack (Elasticsearch, Logstash, and Kibana), and configure the servers that comprise our application to send their relevant logs to the logging server. We will also set up Logstash filters that will parse and structure our logs which will allow us to easily search and filter them, and use them in Kibana visualizations.

Prerequisites

If you want to access your logging dashboard via a domain name, create an A Record under your domain, like “logging.example.com”, that points to your logging server’s public IP address. Alternatively, you can access the monitoring dashboard via the public IP address. It is advisable that you set up the logging web server to use HTTPS, and limit access to it by placing it behind a VPN.

Install ELK on Logging Server

Set up ELK on your logging server by following this tutorial: How To Install Elasticsearch, Logstash, and Kibana 4 on Ubuntu 14.04.

If you are using a private DNS for name resolution, be sure to follow Option 2 in the Generate SSL Certificates section.

Stop when you reach the Set Up Logstash Forwarder section.

Set Up Logstash Forwarder on Clients

Set up Logstash Forwarder, a log shipper, on your client servers, i.e. db1, app1, app2, and lb1, by following the Set Up Logstash Forwarder section, of the ELK tutorial.

When you are finished, you should be able to log into Kibana via the logging server’s public network address, and view the syslogs of each of your servers. Continue reading Building for Production: Web Applications — Centralized Logging →

Linux

Building for Production: Web Applications — Monitoring

Leave a comment

Introduction

Now that we have our production application server setup, a recovery plan, and backups, let’s look into adding monitoring to improve our awareness of the state of our servers and services. Monitoring software, such as Nagios, Icinga, and Zabbix, enables you to create dashboards and alerts that will show you which components of your application setup need attention. The goal of this is to help you detect issues with your setup, and start fixing them, before your users encounter them.

Monitoring diagram

In this tutorial, we will set up Nagios 4 to as the monitoring software, and install the NRPE agent on the servers that comprise our application.

For each server in our setup, we will set up monitoring to check if the server is up and if its primary process (i.e. apache, mysql, or haproxy) is running. While this monitoring guide isn’t comprehensive—you will probably want to set up additional checks that we won’t cover here—it is a great place to start.

Prerequisites

If you want to access your logging dashboard via a domain name, create an A Record under your domain, like “monitoring.example.com”, that points to your monitoring server’s public IP address. Alternatively, you can access the monitoring dashboard via the public IP address. It is advisable that you set up the monitoring web server to use HTTPS, and limit access to it by placing it behind a VPN.

Install Nagios on Monitoring Server

Set up Nagios on your monitoring server by following this tutorial: How To Install Nagios 4 and Monitor Your Servers on Ubuntu 14.04. If you prefer, you may also use Icinga, which is a fork of Nagios.

Stop when you reach the Monitor an Ubuntu Host with NRPE section.

Continue reading Building for Production: Web Applications — Monitoring →

Linux

Building for Production: Web Applications — Backups

Leave a comment

Building for Production: Web Applications — Backups

Introduction

After coming up with a recovery plan for the various components of your application, you should set up the backup system that is required to support it. This tutorial will focus on using Bacula as a backups solution. The benefits of using a full-fledged backup system, such as Bacula, is that it gives you full control over what you back up and restore at the individual file level, and you can schedule backups and restores according to what is best for you.

Backup Diagram

Solutions such as DigitalOcean Droplet Backups (snapshot backups of your entire Droplet) are easy to set up and may be sufficient for your needs, if you only require weekly backups. If you opt for DigitalOcean Backups, be sure to set up hot backups of your database by following the Create Hot Backups of Your Database section.

In this part of the tutorial, we will set up a Bacula to maintain daily backups of the required backups of the servers that comprise your application setup (db1, app1, app2, and lb1), defined previously in our recovery plan—essentially, this is a tutorial that shows you how to use Bacula to create backups of a LAMP stack. We will also use Percona XtraBackup to create hot backups of your MySQL database. Lastly, we will use rsync to create a copy of your backups, on a server in a remote data center. This will add two servers to your setup: backups and remotebackups (located in a separate data center).

Let’s get started. Continue reading Building for Production: Web Applications — Backups →

Linux

Building for Production: Web Applications — Recovery Planning

Leave a comment

Building for Production: Web Applications — Recovery Planning

Introduction

Now that we have our example application setup, we should devise a recovery plan. A recovery plan is a set of documented procedures to recover from potential failures or administration errors within your server setup. Creating a recovery plan will also help you identify the essential components and data of your application server setup.

A very basic recovery plan for a server failure could consist of the list of steps that you took to perform your initial server deployment, with extra procedures for restoring application data from backups. A better recovery plan might, in addition to good documentation, leverage deployment scripts and configuration management tools, such as Ansible, Chef, or Puppet, to help automate and quicken the recovery process.

Recovery Plan Diagram

In this part of the tutorial, we will demonstrate how to create a basic recovery plan for the example WordPress application that we set up. Your needs will probably differ, but this should help you get started with devising a recovery plan of your own.

Recovery Plan Requirements

Our basic requirements are that we are able to recover from the loss of any server in the setup, and restore the application functionality and data (up to a reasonable point in time). To fulfill this goal, we will create an inventory of each server, determine which data needs to be backed up, and write a recovery plan based on our available assets. Of course, if any of these recovery plans are executed, the application should be tested to verify that it was restored properly. Continue reading Building for Production: Web Applications — Recovery Planning →

Linux

Building for Production: Web Applications — Deploying

Leave a comment

Building for Production: Web Applications — Deploying
Introduction

In this part of the tutorial, we will deploy our example PHP application, WordPress, and a private DNS:

DNS + Application Diagram

Your users will access your application over HTTPS via a domain name, e.g. “https://www.example.com”, that points to the load balancer. The load balancer will act as a reverse proxy to the application servers, which will connect to the database server. The private DNS will enable us to use names to refer to the private network addresses of our servers which ease the process of configuration of our servers.

We will set up the components that we just discussed on six servers, in this order:

  • Private DNS (ns1 and ns2)
  • Database Server (db1)
  • Application Servers (app1 and app2)
  • Load Balancer (lb1)

Let’s get started with the DNS setup.

Private DNS Servers

Using names for addresses helps with identifying the servers you are working with and becomes essential for the maintenance of a larger server setup, as you can replace a server by simply updating your DNS records (in a single place) instead of updating countless configuration files with IP addresses. In our setup, we will set up our DNS so we can reference the private network addresses of our servers by name instead of IP address.

We will refer to the private network address of each server by a hostname under the “nyc3.example.com” subdomain. For example, the database server’s private network address would be “db1.nyc3.example.com”, which resolves to it’s private IP address. Note that the example subdomain is almost completely arbitrary, and is usually chosen based on logical organization purposes; in our case, we “nyc3” indicates that the servers are in the NYC3 datacenter, and “example.com” is our application’s domain name.

Set this up by following this tutorial, and adding DNS records for each server in your setup:

After completing the DNS tutorial, you should have two BIND servers: ns1 and ns2. If you already know the private IP addresses of all of the servers in your setup, add them to your DNS now; otherwise, add the appropriate DNS records as you create your servers.

Now we’re ready to set up our database server.

Set Up Database Server

Because we want to load balance the our application servers, i.e. the ones running Apache and PHP, we need to decouple the database from the application servers by setting it up on a separate server. Decoupling the database from the application is an essential step before horizontally scaling many types of applications, as explained in this blog post: Horizontally Scaling PHP Applications: A Practical Overview.
Continue reading Building for Production: Web Applications — Deploying →

Linux

Building for Production: Web Applications — Overview

Leave a comment

Building for Production: Web Applications — Overview

Introduction

This 6-part tutorial will show you how to build out a multi-server production application setup from scratch. The final setup will be supported by backups, monitoring, and centralized logging systems, which will help you ensure that you will be able to detect problems and recover from them. The ultimate goal of this series is to build on standalone system administration concepts, and introduce you to some of the practical considerations of creating a production server setup.

If you are interested in reviewing some of the concepts that will be covered in this series, read these tutorials:

While the linked articles provide general guidelines of a production application setup, this series will demonstrate how to plan and set up a sample application from start to finish. Hopefully, this will help you plan and implement your own production server environment, even if you are running a different application on a completely different technology stack. Because this tutorial covers many different system administration topics, it will often defer the detailed explanation to external supporting articles that provide supplemental information.

Our Goal

By the end of this set of tutorials, we will have a production server setup for a PHP application, WordPress for demonstration purposes, that is accessible via https://www.example.com/. We will also include servers that will support the production application servers. The final setup will look something like this (private DNS and remote backups not pictured):

Production Setup

In this setup, the servers in the Application box are considered to be essential for the application run properly. Aside from the recovery plan and the remote backup server, the remaining components—backups, monitoring, and logging—will be added to support the production application setup. Each component will be installed on a separate Ubuntu 14.04 server within the same DigitalOcean region, NYC3 in our example, with Private Networking enabled.

Continue reading Building for Production: Web Applications — Overview →

Linux

Back Up a LAMP Server with Bacula on Ubuntu 14.04

Leave a comment

Introduction

After getting your application server up and running, an important next step is to set up a backup system. A backup system will allow you to create periodic backup copies of your data, and restore data from those backups. As data can be lost due to user error or the eventual hardware failure that any computer system is prone to, you will want set up backups as a safety net.

This tutorial will show you how to create proper backups of a PHP application, running a LAMP stack on a single Ubuntu 14.04 server, by using a separate backups server that is running Bacula. One of the benefits of using a backup system like Bacula is that it gives you full control of what should be backed up and restored, at the individual file level, and the schedule of when the backups should be created. Having file-level granularity when creating backups allows us to limit our backup selections to only the files that are needed, which will save disk space compared to backing up the entire filesystem.

Backup Diagram

If this seems excessive to you, you may want to consider DigitalOcean Droplet Backups (snapshot backups of your entire Droplet), which must be enabled when you create your Droplet. These backups are easy to set up and may be sufficient for your needs if you only require weekly backups. If you opt for DigitalOcean Backups, be sure to set up hot backups of your database by following the Create Hot Backups of Your Database section—this is necessary to ensure that your database backups will be consistent (usable).

Prerequisites

This tutorial assumes that you are running a PHP application, such as WordPress, that is running on a LAMP (Linux, Apache, MySQL/MariaDB, and PHP) stack on a single Ubuntu 14.04 server, with private networking enabled. We will refer to this as the LAMP server. For our example, we will be creating backups of a WordPress server that was created by following these tutorials:

If you are running a different PHP application, or using Nginx instead of Apache, this tutorial will still work fine assuming that you make any necessary adjustments to your backup selection.

Of course, you will need sudo access to a server that the Bacula server software will be installed on, which we’ll refer to as the backups server. Ideally, it will be in the same data center as your LAMP server, and have private networking enabled. The backups that are created will live on this server, so it will need enough disk space to store multiple copies of your backup selection.

Backup Selection

As mentioned in the introduction, our backup selection—the files that will be copied every time a backup is created—will consist only of the files that are necessary to restore your application to a previous state. In short, this means we will backup the following data:

  • PHP Application Files: This will be the DocumentRoot of your web server. On Ubuntu, this will be /var/www/html by default
  • MySQL Database: While the MySQL data files are typically stored in /var/lib/mysql, we must create a hot backup of the database in another location. The hot backups will be part of our backup selection

As a matter of convenience, we will also include the Apache and MySQL configuration files in our backup selection. If you have any other important files, such as SSL key and certificate files, be sure to include those too.

The rest of the files on the server can be replaced by following the software installation steps of the initial setup. In the case of a server failure, we could create a replacement LAMP server by following the prerequisite tutorials then restoring the backups, and restarting the appropriate services.

If you are not sure why we are including the aforementioned files in the backup selection, check out the Recovery Planning segment of the multi-part Building for Production: Web Applications tutorial series. It describes how a recovery plan can be developed for a web application, using a multi-server setup as its example.

Let’s set up the hot backups of our database. Continue reading Back Up a LAMP Server with Bacula on Ubuntu 14.04 →