Easy Database Backups with Zmanda Recovery Manager for MySQL

Zmanda Recovery Manager makes it easy to dump your database and that homegrown backup solution you've been using and meaning to replace.

Recently, I had a chance to test the community edition of Zmanda Recovery
Manager for MySQL. I was partly testing to make sure it worked with
MariaDB, Monty Program's drop-in replacement for MySQL, but I also
was testing to see whether it would work well for our own database backups.

Monty Program has arguably the most in-depth knowledge of the MySQL
codebase on the planet. But apart from some large servers we use for
performance and other testing, our actual database usage and needs are
similar to many other small- to medium-size companies. For our Web sites,
we need only a couple small database servers. The datasets for each
database are not large, a couple hundred megabytes each. But, we still
don't want to lose any of it, so backups are a must.

I've long used a homegrown set of shell scripts to manage backing up our
databases. They're simple and work well enough to get the job done. They
lack some features that I've never gotten around to implementing, such as
automated retention periods and easy restores. The setup process also
is more involved than I would prefer. They get the job done, but I've always
wanted something a little better, and I've never had the time to
do it myself.

This is where Zmanda Recovery Manager for MySQL enters the picture. ZRM
Enterprise edition was reviewed by Alolita Sharma in the September
2008 issue of Linux Journal, but I'm never very interested in
Enterprise editions. They always have proprietary bits, and I've never
trusted GUI tools as much as their command-line counterparts. Luckily,
where there is an “enterprise” version there almost always is a
“community” version lurking somewhere in the shadows.

Like many other community editions, Zmanda Recovery Manager for
MySQL, Community Edition (let's just call it ZRM) lacks the
“flashy bits”. Things like the graphical
“console” application,
Windows compatibility, 24x7 support and other high-profile features
of its Enterprise sibling are missing in the Community version. But the
essentials are there, and it has one big feature I like: it is fully
open source (GPL v2). The key metric, however, is does it do what I need
it to do?

To find out, I set up a small test environment (I didn't want to test
on live, production databases) and gave it a spin. See the
Setting Up a Test Environment sidebar for details on what I did prior to
installing and testing ZRM.

Setting Up a Test Environment

For testing and evaluating ZRM, I set up three virtual servers running Ubuntu 10.04
LTS, installed MariaDB on them, and then downloaded the example
“employees”
test database from launchpad.net/test-db.

Installing MariaDB is easy on Debian, Ubuntu and CentOS because of some MariaDB
repositories maintained by OurDelta.org. The site has instructions on how to
configure your system to use the repositories. For Ubuntu 10.04, I did the
following:

Installing mariadb-server looks and acts just like installing mysql-server.

With the database server installed, I loaded the test database. To load the
employees test database into MariaDB, I first downloaded and untarred it and then
used the mysql command-line program to load it into MariaDB like so:

The employees test database uses a couple hundred megabytes of disk space. This is
in line with the size of our “real” databases. But more important than the comparative
size, the employees test database comes with a handy verification script
that
lets me test that the data is correct. Verifying the data is as simple as this:

mysql -u root -p -t < test_employees_sha.sql

With the test database servers set up, I then created a fourth virtual
machine with a base Ubuntu Server install on it to act as my backup
server. Now I was ready to test using ZRM for backup and recovery with
the ability to verify that the recovery was successful.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.