Zmanda Recovery Manager for MySQL
Data protection is vital to database professionals. A well run database must have proper backup and recovery plans to ensure data availability and integrity in case of accidental data loss or destruction. In today’s business environment, explosive data growth combined with shorter backup and recovery windows makes the task more difficult. And, with MySQL supporting businesses running full throttle 24-hours a day, seven days a week, backup and recovery operations need to be conducted in such a way that is non-disruptive to users and applications.
ZRM for MySQL simplifies the life of a database administrator who needs an easy-to-use yet flexible and robust backup and recovery solution. ZRM is the only solution endorsed by MySQL.
With ZRM for MySQL you can:
Perform Flexible Backups
Easily schedule full, incremental, raw or logical backups
Use snapshot technologies to perform hot backup
Activate Continuous Data Protection (CDP) to enable instantaneous point-in-time recovery
Automatically optimize the backup method that best fits your environment
Provide Continuous Data Protection for Your MySQL Database
Deep integration between ZRM, underlying storage and MySQL binary logs enables you to perform highly efficient CDP with almost instantaneous point-in-time recovery
Backup Live MySQL Databases Without Impacting Applications & Users
Storage Snapshot support for Full Backups: Perform hot backup of live MySQL by taking advantage of Linux LVM, Microsoft VSS, Solaris ZFS, Symantec VxFS *, NetApp SnapManager * and EMC SnapView technologies *.
* Symantec VxFS, NetApp SnapManager, EMC SnapView technologies are available as Add-on Options.
Non-Blocking Backups: ZRM provides support for non-blocking backups of MySQL using Percona XtraBackup. This combination provides resource utilization management by providing throttling based on the number of IO operations per second. Percona XtraBackup based backups also allow for table level recovery even though the backup was done at the database level (needs the recovery database server to be Percona Server with XtraDB).
Incremental Backups (based on MySQL Binary Logs): ZRM integrates various full backup methods with incremental backups using MySQL Binary Logs. This allows you to take very frequent backups (e.g. hourly) as well as do a point-in-time restore between any two backups. No read or write lock is taken during incremental backups.
Perform One-Click Point-In-Time Recovery
ZRM provides unified point-in-time recovery for any type of backup method used
Flexible recovery level, i.e. recover the whole MySQL server, database, table or transaction
Identify point-in-time and initiate the recovery through Visual Log Analyzer
Automate backups across local, remote or clustered MySQL servers via an easy-to-use Web consoleCentralized Global Backup Management
Backup MySQL servers with MyISAM, InnoDB, NDB and other storage engines on Linux, Solaris, OpenSolaris, Windows and Mac OS X
Backup Configuration files for Applications
Easily set up backup & retention policies
Fast Backups of MySQL Running on Amazon EC2
If you are running your MySQL databases on the Amazon EC2 compute cloud, ZRM can perform fast full backups of these databases by using Elastic Block Store (EBS) Snapshots. ZRM takes only a momentary read lock on the MySQL database during the creation of the snapshot, in order to ensure consistency of the backed up database archive. MySQL Backups using Amazon EBS snapshots are taken very efficiently; only the blocks that have changed since the last backup (via EBS snapshot) will be saved in the subsequent snapshot. For example, if you have a database with 100 GBs of data, but only 5 GBs of data has changed since your last snapshot, only the 5 additional GBs of snapshot data will be stored back to Amazon S3 during the current full backup run.
ZRM automatically deletes EBS snapshots (containing full backups of MySQL) according to the configured retention policy. Just like other snapshot based full backups, ZRM intelligently correlates EBS Snapshots with incremental backups using MySQL logs, enabling the database administrator to recover their MySQL instances running on EC2 to any point in time.
ZRM can run on the same EC2 instance as the MySQL database. On the other hand, if you have multiple EC2 instances with MySQL databases, you can run ZRM on one centralized EC2 instance dedicated for backup purposes. In this case, backup configuration and management for all MySQL databases is performed via Zmanda Management Console from this centralized backup server.
Backups made using EBS snapshots can be recovered on the original EC2 instance or on a new EC2 instance. This also provides a quick and convenient mechanism to instantiate new MySQL database servers based on the database state from a desired point-in-time.
Maximize Data Security
Encrypt data-at-rest and data-in-transit using industry standard encryption technologies
Configure on-the-fly compression to meet your storage needs
Role-based access control provide added layers of security
Stay Informed Via Automated Alerts & Reports
Built-in monitoring & reporting functions
At-a-glance calendar view of all backup and recovery jobs
Receive real-time email and RSS notifications on the status of your backups
Easily fulfill audit or compliance requirements using highly configurable reports
Easily Deploy Your Backup & Recovery Solution
ZRM is quick and easy to install
Intuitive configuration with context sensitive help
Choose between Standard or Premium levels of support to best fit your requirements
Control Your Data. No Vendor Lock In
ZRM does not use any proprietary data formats. You can always recover your MySQL data even without ZRM being installed
ZRM for MySQL Cluster
ZRM for MySQL Cluster is the only consolidated backup and recovery solution designed for the stringent demands of MySQL Cluster and MySQL Cluster Carrier-Grade Edition (CGE). This edition of ZRM provides hot backup of MySQL cluster and consolidates backup data dispersed among all cluster nodes to a single system making it easier to recover data in case of emergency.