Tag Archives: Backups

Linux

How To Create Hot Backups of MySQL Databases with Percona XtraBackup on Ubuntu 14.04

Leave a comment

How To Create Hot Backups of MySQL Databases with Percona XtraBackup on Ubuntu 14.04

Introduction

A very common challenge encountered when working with active database systems is performing hot backups—that is, creating backups without stopping the database service or making it read-only. Simply copying the data files of an active database will often result in a copy of the database that is internally inconsistent, i.e. it will not be usable or it will be missing transactions that occurred during the copy. On the other hand, stopping the database for scheduled backups renders database-dependent portions of your application to become unavailable. Percona XtraBackup is an open source utility that can be used to circumvent this issue, and create consistent full or incremental backups of running MySQL, MariaDB, and Percona Server databases, also known as hot backups.

As opposed to the logical backups that utilities like mysqldump produce, XtraBackup creates physical backups of the database files—it makes a copy of the data files. Then it applies the transaction log (a.k.a. redo log) to the physical backups, to backfill any active transactions that did not finish during the creation of the backups, resulting in consistent backups of a running database. The resulting database backup can then be backed up to a remote location using rsync, a backup system like Bacula, or DigitalOcean backups.

This tutorial will show you how to perform a full hot backup of your MySQL or MariaDB databases using Percona XtraBackup on Ubuntu 14.04. The process of restoring the database from a backup is also covered. The CentOS 7 version of this guide can be found here.

Prerequisites

To follow this tutorial, you must have the following:

  • Superuser privileges on an Ubuntu 14.04 system
  • A running MySQL or MariaDB database
  • Access to the admin user (root) of your database

Continue reading How To Create Hot Backups of MySQL Databases with Percona XtraBackup on Ubuntu 14.04 →

Linux

Install Bacula-web on Ubuntu 14.04

Leave a comment

How To Install Bacula-web on Ubuntu 14.04

Introduction

Bacula-web is a PHP web application that provides an easy way to view summaries and graphs of Bacula backup jobs that have already run. Although it doesn’t allow you to control Bacula in any way, Bacula-web provides a graphical alternative to viewing jobs from the console. Bacula-web is especially useful for users who are new to Bacula, as its reports make it easy to understand what Bacula has been operating.

In this tutorial, we will show you how to install Bacula-web on an Ubuntu 14.04 server that your Bacula server software is running on.

Prerequisites

To follow this tutorial, you must have the Bacula backup server software installed on an Ubuntu server. Instructions to install Bacula can be found here: How To Install Bacula Server on Ubuntu 14.04.

This tutorial assumes that your Bacula setup is using MySQL for the catalog. If you are using a different RDBMS, such as PostgreSQL, be sure to make the proper adjustments to this tutorial. You will need to install the appropriate PHP module(s) and make adjustments to the database connection information examples.

Let’s get started.

Install Nginx and PHP

Bacula-web is a PHP application, so we need to install PHP and a web server. We’ll use Nginx. If you want to learn more about this particular software setup, check out this LEMP tutorial.

Update your apt-get listings:

sudo apt-get update

Then, install Nginx, PHP-fpm, and a few other packages with apt-get:

sudo apt-get install nginx apache2-utils php5-fpm php5-mysql php5-gd

Now we are ready to configure PHP and Nginx.

Configure PHP-FPM

Open the PHP-FPM configuration file in your favorite text editor. We’ll use vi:

sudo vi /etc/php5/fpm/php.ini

Find the line that specifies cgi.fix_pathinfo, uncomment it, and replace its value with 0. It should look like this when you’re done.

cgi.fix_pathinfo=0

Now find the date.timezone setting, uncomment it, and replace its value with your time zone. We’re in New York, so that’s what we’re setting the value to: Continue reading Install Bacula-web on Ubuntu 14.04 →

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

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 →