Hands-on with Zmanda Recovery Manager 3.0 on Ubuntu Server

In this article we present a hands-on try-out of the most important features of Zmanda Recovery Manager 3.0 (ZRM) on Ubuntu. We ran a series of backups and restores using a MySQL database for a popular multi-user WordPress blog. The primary database table (wp_posts) contained approximately 500K rows, averaging 2Kb per row. In order to run backups of our WordPress database, we first set up a ZRM backup server, as well as created a MySQL user account on our MySQL server host. The hardware and software configuration we used is shown in Table 1.

Installing Zmanda Recovery Manager

ZRM Enterprise edition provides two binary installation packages — ZRM server rapid installer (ZRM-enterprise-3.0-installer.bin) and ZRM client (mysql-zrm-enterprise-client_3.0-1_all.deb). First we will discuss the ZRM server installation, and then describe the ZRM client installation.

ZRM Server Installation

Figure 2: ZMC Rapid Installer

The rapid installer is a graphical interface which steps you through installation of the server software components: the ZRM server, Zmanda Management Console and its dependencies, and ZRM command-line tools. To launch the installer, we ran the following commands on our ZRM backup server host (tahoe).

root@tahoe:~# chmod +x ZRM-enterprise-3.0-installer.bin
root@tahoe:~# ./ZRM-enterprise-3.0-installer.bin

The installation process takes only a few minutes, during which the user must select how the Zmanda Management Console web server is accessed, whether by http or by https. The installation process ends with a dialog box prompting the user to launch the ZMC.

To complete the ZRM server installation, we downloaded the Zmanda License Key file (zmanda_license) and placed it in ‘/etc/zmanda/zmanda_license‘. We set file permissions to 644 (chmod 644 /etc/zmanda/zmanda_license) and changed file ownership to ‘root’ (chown root /etc/zmanda/zmanda_license).

ZRM Client Installation

The ZRM client for Ubuntu is a Debian package that you install using standard package management tools such as dpkg. The ZRM client should be installed if the MySQL server being backed up (ZRM backup client) is running on a separate machine from the ZRM backup server and you want to run raw backups. To install the ZRM client, we executed the following command on our MySQL server host (bigsky).

root@bigsky:~# dpkg -i mysql-zrm-enterprise-client_3.0-1_all.deb

Note that we configured the ‘mysql‘ system user on our MySQL server host (bigsky) with sudo privileges by editing the ‘/etc/sudoers‘ file and adding a line ‘mysql: ALL=(ALL) NOPASSWD: ALL‘. This grants the ‘mysql‘ user account permission to execute LVM system commands, necessary for Linux LVM-based filesystem snapshots.

Then we created a MySQL database user which ZRM used for backup and recovery on our MySQL server host (bigsky). Listing 2 shows the SQL statements we used to create the user account and grant privileges.

Listing 2: SQL statements to create user account and setup privileges

mysql> GRANT LOCK TABLES, SELECT, FILE, CREATE, DROP, INDEX, \
    -> SHUTDOWN, ALTER, INSERT, ALTER ROUTINE, CREATE ROUTINE, SUPER, RELOAD \
    -> ON *.* TO 'zrmbackup'@'tahoe.local.pri' IDENTIFIED BY 'somepassword';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT LOCK TABLES, SELECT, FILE, CREATE, DROP, INDEX, SHUTDOWN, \
    -> ALTER, INSERT, ALTER ROUTINE, CREATE ROUTINE, SUPER, RELOAD \
    -> ON *.* TO 'zrmbackup'@'bigsky.local.pri' IDENTIFIED BY 'somepassword';
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

We set up SSH for login without passwords by using public keys for the ‘mysql‘ system user on our MySQL server host (bigsky). This enabled the use of SSH connections, by the default SSH copy plugin, between the ZRM backup server (tahoe) and our MySQL server host (bigsky) for backup and restore tasks.

Doing backup and restore

The steps below are listed out in detail to serve as an example of how backups and restores can be performed with ZRM on Ubuntu.

Backup — Backup Level: Full, Backup Mode: Raw

1. Create backup set — We created a new backup set using the “sets” screen within the “Admin” tab. In the “Create backup set” panel, we selected a ZRM userid from the “Backup Set Owner” drop-down list (admin). We then entered a “Backup Set Name” to identify this backup set (wordpress_backup). Finally, we saved the backup set configuration by clicking the “Add” button.
2. Configure backup set — We clicked the “Backup” tab. Doing so gets us to the screen labeled “what”.
   1. what — We filled in values for each panel — “MySQL Server Parameters”, “MySQL User Parameters”, and “What to backup”. Then clicked the “Save” button.
      • MySQL Server Parameters — select the “Server Type” (MySQL server), “Connection Type” (Port), “Port Number” (3306), “Host” (bigsky.local.pri), “MySQL Client Utilities Path” (/usr/bin)
      • MySQL User Parameters — “Username” (zrmbackup), “Password” (somepassword), “SSL Options” (leave blank)
      • What to backup — “Backup Source Type” (Specific Database(s)), “Select Database(s)” (mark checkbox next to wordpress_db).
   2. where — In the “Backup Where Parameters” panel, we filled in values for “Destination Directory” (/var/lib/mysql-zrm), “Temporary Directory” (/tmp), and “Retention Policy” (2 weeks). Then clicked the “Save” button.
   3. when — In the “Backup Schedule” panel, we filled in values for “Backup Level” (Full), “Time Range” (daily), and “Backup Time” (10Hr 15Mins). Then clicked the “Add Schedule” button to save these settings.
   4. how — Although we did not modify the default values on this screen, you should double-check values for “Backup Mode”, “SSH User”, and “Email Address” (if you are using email notification).
3. Application configuration file backup — As part of this backup set, we wanted to preserve the WordPress configuration file ‘wp-config.php‘. ZRM requires an intermediate text file that lists the full path to each configuration file to be backed up, separated by newlines. Therefore, we created ‘/etc/mysql-zrm/wordpress_backup/app_conf_files_list‘, with the full path to wp-config.php on the first line. Next, we edited the ZRM backup set configuration file ‘/etc/mysql-zrm/wordpress_backup/mysql-zrm.conf‘ (on tahoe) and added the line ‘config-file-list="/etc/mysql-zrm/wordpress_backup/app_conf_files_list"‘. Note that you can also dynamically generate the list of application configuration files using a pre-backup plugin script available from the Zmanda network.
4. With the steps above we had now scheduled a daily full raw backup of all the tables in the ‘wordpress_db‘ database every morning at 10:15am.

Figure 3: ZMC Backup screen

Backup — Backup Level: Incremental, Backup Mode: Raw

Before running an incremental backup, we added some blog posts to our running WordPress instance, in effect modifying the underlying database.

1. Configure backup set — Using the “Backup Set” drop-down list at the top left corner of the ZMC, we selected “wordpress_backup”. Doing so displays the screen labeled “what” within the “Backup” tab. Next, we scheduled another backup job via the screen labeled “when”. In the “Backup Schedule” panel, we filled in values for “Backup Level” (Incremental), “Time Range” (daily), and “Backup Time” (12Hr 00Mins). Then we clicked the “Add Schedule” button.

Monitoring

As we ran on-demand backups, we were able to track their progress using the monitoring feature available via the “Monitor” tab of the ZMC. The “Backup Run Details” pane is updated live as each phase of the backup completes.

Restore

1. Identify recovery point — Using the “db events” (viewer) within the “Report” tab of the ZMC, we clicked on the backup timestamp (TimeStamp: 21:53:24) hyperlink to begin configuring the details of the restore process. Clicking the timestamp hyperlink displayed the screen labeled “what” within the “Restore” tab.
2. Configure restore settings
   1. what — Information on this screen notified us that all databases would be restored from the last successful full backup. We clicked the “Next Step” button at the bottom to proceed further.
   2. where — We reviewed the connectivity and user settings for the MySQL server to which the data would be restored. All the default values were left unchanged. We then clicked the “Next Step” button to proceed further.
   3. how — The settings on this screen such as “Temporary Directory”, “MySQL Shutdown Options”, and “Copy Plugin Parameters” specify how your data is restored. The default values were left unchanged. We clicked the “Next step” button.
   4. restore — Once we reviewed the restore settings on this screen, we clicked the “Restore” button to actually start the process.
3. In a few easy steps we were able to successfully restore the WordPress database from a full raw backup.

Figure 4: ZMC Restore screen

Reports

After running numerous backups and restores, the pre-defined reports we found most useful include the “Backup Status Report” and the “Application Impact Report”.

Application Impact Report — Provides backup job statistics such as “Time Taken”, “Read Locks Time”, and “Flush Logs time” — all of which let you tune your backup schedules to avoid database peak usage periods.

Backup Status Report — Gives you an at-a-glance status overview for every backup job that has been run. This can prove very useful for quickly tracking down error conditions across all your backup jobs.

In Summary

Our exercise to backup and restore a moderately sized WordPress MySQL database has demonstrated that Zmanda Recovery Manager 3.0 is a capable MySQL backup and recovery solution for the enterprise Ubuntu user. Whether you are a system administrator or a seasoned DBA, you can easily use ZRM’s friendly and functional GUI to schedule and run your MySQL data backups.