Zmanda Recovery Manager for MySQL Amazon AMI

Accessing ZRM Server AMI and tools

To launch this Amazon Machine Image (AMI), you will need an Amazon AWS account and you'll need to subscribe to Amazon EC2. You will also need some tools to launch and manage AMIs. We suggest using Amazon AWS Management Console . You can also use the command line Amazon EC2 tools.

In this document, we provide examples using Amazon AWS Management Console.

Using AWS Management Console (Amazon account information is required), search for Zmanda Recovery Manager AMI. AMI can be found under Community AMIs (Click on EC2 Dashboard >> Launch Instances to see Community AMIs).

The ZRM AMI id isami-694fc300 (US East region). It runs RHEL 6 Linux distribution. Users can directly access the AMI by using Images >> AMIs from the options in left hand pane of AWS Management Console.

ZRM server AMI can use Amazon Elastic Block Store (EBS) volume to store ZRM backup images, catalog and configuration. This makes ZRM server data persistent across reboots and allows you to start ZRM server AMI only during backup window. You will need an EBS volume (appropriately sized) in the same availability zone as your EC2 instance. Now, you need to migrate ZRM catalog and configuration information to this EBS volume. A data migration script is available in Zmanda Network that performs this operation. The script also can reuse an existing volume that has ZRM data.

Please download the script and upload it to your S3 bucket.

Running ZRM AMI on the Amazon Cloud

ZRM AMI can be launched on Amazon EC2 using AWS Management Console.

• EC2 Key Pairs : Click on Key Pairs in AWS Management Console to generate a key pair. The key pair (private key) is used for ''ssh'' access to the virtual machine. Create a key pair for launching EC2 instances. Please note that this key pair is not same as access identifiers that is part of Amazon account.

• Security Group : Create a security group (a set of firewall rules) for the ZRM EC2 instance. You will need to allow ssh, http/https access as well as access for socket copy plugin. ZRM socket copy plugin uses port 25300. An example security group for ZRM EC2 instance is shown below.

Connection method	Protocol	From Port	To Port	Source IP
SSH	TCP	22	22	0.0.0.0/0
HTTPS	TCP	443	443	0.0.0.0/0
HTTP	TCP	80	80	0.0.0.0/0

• Launch EC2 instance : Select ZRM Server AMI using the AMI ID and launch the instance. Fill the security group and Key Pair. One small EC2 instance is sufficient for the backup server under most circumstances.

• ZRM License : The ZRM license file to be used for the ZRM server EC2 instance is available in the  Zmanda Network account. Login and Click Downloads tab. Download the License file. Use scp (-i option) with the private key to copy the license file to /etc/zmanda/zmanda_license on the ZRM server EC2 instance. The license file should be readable by the mysql user.

• EBS volume for ZRM catalog, configuration and backup images : It is important to use EBS volume for storing catalog, configuration and backup images on the ZRM server. Please create a EBS volume in the same availability zone (example: us-east-1a) as the ZRM server EC2 instance. Note down the EBS volume id. This migration script is required if the EBS volumes were not used for storing configuration/catalog/backup images during initial configuration. Download the data migration script from Zmanda network. Run the script after boot up to mount EBS volume as /etc/mysql-zrm on the ZRM server.

  ./migrate-to-ebs.pl <EBS volume id> <AWS account access key> <AWS account secret key>

You can automate this by creating a tinyurl to s3 bucket where the script is stored and running it at startup as
  runurl <tinyurl url> <EBS volume id> <AWS account access key> <AWS account secret key>

By default, the ZRM AMI doesn't start ZRM services at boot time. The data migration script starts the ZRM services after setting up ZRM to use the data on the EBS volume. If you are not using the data migration script, then you can start zrm services at boot time by setting the user-data field while launching the AMI:

 #! /bin/bash
 /etc/init.d/zmc_zrm restart

If you are using AWS console, the user-data field is present in the show advanced options section.

• ZRM server date and time : Please make sure that the system date and time on the ZRM server launched on EC2 is correct. Incorrect date and time will result in failure of EBS snapshots.

MySQL server requirements

• The MySQL data and log files should reside on non-partitioned EBS volumes on the MySQL server EC2 instance.

• All ZRM client software dependencies must be installed if there are already not installed. ZRM client requires xinetd, sudo, perl, perl-XML-Parser, perl LWP::UserAgent. You can install these packages and dependencies using distribution tools such as ''yum'' or ''apt-get''. For example: In RedHat or Fedora distributions, you can use following commands to install dependencies and start xinetd process.

  # yum install perl xinetd perl-Test-Mock-LWP perl-XML-Parser sudo
  # /etc/init.d/xinetd start

• ZRM client software must be installed on the MySQL EC2 instance. ZRM client software is available on the Zmanda Network under your account. For example: ZRM client rpm can be installed using rpm command.

# rpm -ivh MySQL-zrm-enterprise-client-3.5-1.noarch.rpm

• The MySQL server EC2 instance must have socket copy plugin port 25300 and MySQL port (default: 3306) open. Amazon EC2 security group should be configured appropriately before the instance is launched. For example:

• Configure /etc/sudoers for Amazon EBS snapshot ZRM plugin.
  • Remove ''requiretty'' line or comment it out.
  • Add the following line to ''/etc/sudoers'' file to allow ''mysql'' user to execute df, xfs_freeze, mount and unmount commands without prompting for passwords.

mysql ALL=NOPASSWD:/bin/df,NOPASSWD:/usr/sbin/xfs_freeze,NOPASSWD:/usr/bin/mount,NOPASSWD:/usr/bin/umount

• Please make sure that the system date and time on the MySQL server launched on EC2 is correct. Incorrect date and time will result in failure of EBS snapshots and hence the backups.

Configuring the EC2 MySQL server backup set

Login to Zmanda Management Console (default user and password is admin/admin) using a browser. The url will be  https://<zrm server ec2 instance public DNS name>/  The ZRM server EC2 instance public DNS name will have following format - ec2-<string>-.compute-1.amazonaws.com The ZRM server EC2 instance public name can be found in AWS Management Console.

The ZRM web server certificate is a self signed certificate. This certificate has to be added as an exception.

For each MySQL server running in EC2 that needs to be backed up, a backup set has to be created. A default backup set demo-EBS-backup has been configured. This backup set can be edited or duplicated to create new backup sets.

• Backup What page :  Fill in the MySQL server name - EC2 public or private DNS name will work. If the MySQL server is configured in different port other than 3306, change the Port. MySQL backup and restore user name and password must be configured. The MySQL user should have permission to access the database from the ZRM server machine (Use GRANT SQL command to grant privileges to the user). An example backup what page is shown below. You can select all databases or a specific database or specific tables in the database to be part of the backup set.

• Backup Where page: When ZRM AMI is launched, a new directory ''/etc/mysql-zrm/zrm-backup-data'' is created.  To make backup images persistent across ZRM server boots, EBS volume should be used to store ZRM backup images and catalog. As mentioned in the earlier section, please use the migrate-to-ebs script available from the Zmanda network.  If the EBS volume is mounted in different directory, please modify the '''Destination''' field in this page as shown below.

• Backup How page: The location of MySQL binary logs on the MySQL server should be filled in as '''Binary Log''' value. The full backups are performed using Amazon EBS snapshots. Amazon account access identifiers - secret key and access key are needed. The instance id for MySQL server EC2 instance is also required. Compression and Encryption of backup images cannot be performed for EBS snapshot backups. An example Backup How page is shown below.

• Backup Summary page: This page provides a summary of all parameters as well as validates the ZRM configuration.

Backing up EC2 MySQL server

Backup can be scheduled in Backup When page or performed immediately from Backup Summary page.  Both full backup as well as incremental backups can be performed. Full backup is done using Amazon EBS snapshots. The full backup time taken depends on time to create EBS snapshots.  The incremental backup is performed by copying incremental backups to ZRM server. This transfer is within Amazon cloud and should be quick. Full and incremental backups are hot backups. The Monitor page shows the backup phases when backup run is in progress.

Custom Reports page allow user to customize the backup reports across backup runs. The Backup runs can be exported as CSV file for analysis.

Recovering EC2 MySQL server

ZRM supports complete recovery of a MySQL server or recovery few database events. The database events in the incremental backups can be searched and selected for restoration using the Database event reports page. 

Restoration process is similar to backup. Information for Restore what, where and how have to be provided. When restoration is being done to EC2 MySQL server, the Amazon Instance id of the restoration EC2 target must be provided in the Restore Where page. The Restore Where page also provides users to change where the MySQL data, logs Amazon EBS volumes should be mounted. On this page, you can specify the new disk device name which would be attached to the MySQL server instance after restoration from EBS snapshot is complete. The EC2 instance where the complete MySQL server is being restored to should have MySQL server processes running.



After completing Restore What, Where and How pages, the restore process can be started in Restore Restore page. The full backup and incremental backups can be restored to a point in time or to a specific database event. If only some database events are being restored from incremental backups (as can be done in '''Restore What''' page), the data is not restored from full backups and the EBS snapshot device maps are not used.