Book Image

Instant Debian - Build a Web Server

By : Jose Miguel Parrella
Book Image

Instant Debian - Build a Web Server

By: Jose Miguel Parrella

Overview of this book

Debian is one of the most popular Linux-based operating systems, with over 37 thousand software packages available in several architectures. This universal operating system provides the foundation for thousands of web servers. It is easy to install, stable and provides mechanisms for system security. Starting with an insightful discussion on the architectures and methods of installing Debian, we’ll also discuss cues to plan ahead for scalability. We’ll then explore how to configure and use APT to install necessary software, taking you all the way through to presenting scenarios for security, backup/restore and maintenance. Debian: Build a Web Server How-To will help you effectively setup and deploy a Debian-based Web server with strong foundations for the future of your Web application. It teaches concepts such as library and framework availability and suitability under the APT system, how to read and process logs and events and how to respond to security incidents. Additionally it also covers planning and executing a backup and restore strategy and how to deploy clusters and proxies. The book will help you navigate installation methods, understand how to configure APT and how to use it to deploy the application parts and how to tackle common management scenarios, ending up with a ready-to-go Web server running Debian.
Table of Contents (7 chapters)

Backing up your environment (Medium)

There are different types of backup. When you think of backing up your environment, it helps to think of how you want to restore it. Do you want to restore it quickly? Do you want to restore it from the bare bones? Do you want to invest more or less time doing the actual restoration process? Do you want to be granular about what you restore?

Getting ready

Debian has different software for all those types of backups. You should select the one that you feel comfortable with, and not try to find a feature-by-feature replica of what you had in your old environments, or try to use whatever the rest of the people are using on the Internet.

For a web server, you usually have two options: bare metal backup and restore or just web server filesystem backup and restore. The former is usually more comprehensive and complex to set up and maintain, and the latter is easier to get running but covers less recovery scenarios.

In any case, you should also add special considerations for backing up your databases and caches, as they usually store information in memory that needs to be flushed to the disk. In some cases like in Postgres (, it is not easy to flush cache manually; you need to stop the database altogether.

In general, it's best to back up a stopped system. That's why it's important to have a scalability strategy for your application so it can keep running while you back up masters.

For the bare metal recovery solution, we'll use Bacula. We will also share some tips on how to use rsync for a web backup scenario. The reason why rsync might make sense here is that you don't have a large datacenter with lots of different servers and operating systems; most likely, you have Debian running a web application, with any number of similar hardware running slaves.

Bacula is distributed, so you can have a director, a storage daemon (server where backups are stored) and several file daemons (clients to be backed up); for the purpose of this guide, we'll consider you have the director and storage together. Also, the director can use different backends for metadata storage. It could make sense to use the same database as your web application to potentially re-use existing DBA skills. We'll use MySQL.

Besides /var/www and /var/lib/mysql or /var/lib/postgres, you'd usually want to back up several critical folders such as /etc, which contains configuration for your setup. /var may also be a good idea especially if you're using other caches or software with variable data. The rest of your system, particularly /usr and /lib, are usually not modified and come prepackaged on Debian packages; /tmp is volatile (clears out with each restart) and /dev is autogenerated.

Of course, if you're going with a bare metal strategy, then you recover your setup from the ground up.. More on that in the next recipe, Restoring your environment.

How to do it…

In this section, you will install and configure Bacula Director, Storage Daemon and Console, with a MySQL backend:

  1. In your backup server, install all Bacula components using apt-get: sudo apt-get install baculabacula-director-mysqlbacula-sd-mysqlbacula-console.

  2. In the sudo editor, enter /etc/bacula/bacula-director.conf.

  3. Browse to the Client {} group, the first one will be the server itself, and the second one is commented out. You can uncomment it and change the directives:

    • Name: It should match the name in /etc/bacula/bacula-fd.conf of the client

    • Address: It is the IP address or FQDN for the client

    • Password: It should match the one of the client, or you can make your own

  4. Also, in /etc/bacula/bacula-sd.conf, make sure an IP address or FQDN is used, and that the name under Device | Archive Device and the password matches the one in director.conf.

  5. Restart Bacula by using the service bacula-director restart and sudo service bacula-sd restart commands.

  6. In your client server (your web application server), install the Bacula file daemon components using the command, sudo apt-get install bacula-fd.

  7. Open the /etc/bacula/bacula-fd.conf configuration file, set Bacula to listen on your internal backup address and set the hostname and password of the allowed director: sudo editor /etc/bacula/bacula-fd.conf.

  8. Browse to the Director {} group, change Name to the name of the director (found under Director/Name in /etc/bacula/bacula-director.conf on the server) and take note of the password (it needs to match the one on the server).

  9. Browse to the FileDaemon {} group, change FDAddress to a non-loopback IP address where the director can reach you.

  10. Issue a sudo service bacula-fd restart command.

  11. To test it on the director, run:


    Type in: 3 (for client)

    Type in: 2 (usually your client will be #2)

  12. Bacula will show a picture similar to the following one. You should see no error messages and no jobs running.

  13. Bacula uses FileSet, which are lists of files and folders to backups; Schedule, which define when to run backups; and Jobs, JobDefs, and JobSets (groups of Jobs). We are going to create a simple FileSet, a simple JobDefs and a simple Job. You can copy and paste from the existing content of /etc/bacula/bacula-director.conf. The content of the JobDefs should look as shown in the following screenshot:

    The Job type, on the other hand, should reference the JobDefs type, as illustrated here:

    And finally the FileSet type, which is referenced from the JobDefs type, should look like this:

  14. This creates a weekly backup for web01 that brings (incrementally) the contents of /var/www to the server. After setting it up, you need to issue a sudo service bacula-director restart command. Now in bconsole, navigate to Status | Director where you should see:

  15. You should also label the volume using bconsole first and then the label. Pick a name for your volume (since you are using file storage, this is not incredibly important except for reference reasons) and choose the File pool.

  16. With Bacula, you can issue manual backups when necessary using bconsole. Just use run and select the job you created, then hit Yes. The output should look as in the following screenshot:

  17. Your job should end soon, and you can check it by navigating to Status | Director in bconsole. An OK status (no errors) is pictured as shown in the following screenshot:

  18. For rsync, you will also need a storage server. You can initiate the back up from either side, and the good news is that the restore works the same just by inverting some parts of the rsync command line. Let's suppose you are initiating the back up from the client (web server):

    rsync –avz /var/www user@backup:/var/backups/webapp
    rsync –avz /var/lib/mysqluser@backup:/var/backups/mysql

The -avz options are the most popular set of options passed to rsync. z enables compressions and a enables the archive mode that will preserve useful things such as symlinks. v is verbose and will show filenames and the sent/received tally as well as the bandwidth used.

There's more…

As mentioned before, you should be careful about data not written to disk. Here are some tips:

  • Stop your database using the service mysql stop or service postgresql stop, or flush MySQL tables ( with FLUSH TABLES tbl_list WITH READ LOCK (remember to use UNLOCK TABLES after the back up) if your engine and application model supports it

  • If your application does not handle database unavailability, you might have to stop your web server as well using the command, service apache2 stop

Alternatively, use Bacula's application-specific scripts for MySQL (, which uses full dumps (this may take a lot of time depending on your database size and uses a lot of disk I/O, which you'll definitely consume either way since you're backing up a disk)

You should also check on bacula-director.conf where you want your files restored. Bacula will put a dummy path (something like /nonexistent/path/…), but you should put something like /var/backups/restore or something meaningful to you. We chose /bacula-restores.

We suggest that Debian users back up their installed package lists and their responses to debconf, the Debian configuration interface. You can use the following to prepare a file that can be later backed up by Bacula or manually:

debconf-get-selections > debconf.txt
dpkg –get-selections > packages.txt