AppDynamics Application Intelligence Platform

3.9.x Documentation


Learn by Watching

Doc Maps

Skip to end of metadata
Go to start of metadata

About Controller Backups

AppDynamics strongly recommends that you perform routine data backups of the Controller installation environment. Backups help to improve the disaster recovery preparedness of your organization. Any data generated since the last backup may be lost.

There are two general approaches to backing up the system, using a disk snapshot mechanism, such as Linux Volume Manager, or using database backup tools. The BackupTools section describes tools that support each approach. While most backups are taken to guard against data loss in the event of a failure, they can also be used when upgrading the Controller and when migrating the Controller from one server to another.

This page provides an overview of the tasks and considerations related to backing up the Controller. For information specific for your environment and situation, contact AppDynamics Support

Best Practices for Backups

Backing up the entire system each night may not be feasible when dealing with the large amount of data typically generated by a Controller deployment. To balance the risk of data loss against the costs of performing backups, a typical backup strategy calls for backing up the system at different scopes at different times. That is, you may choose to perform partial backups more frequently and full backups less frequently, relatively speaking.

The scope of a Controller backup can be categorized into these levels:

  • Level 1: A light backup of the installation environment only
  • Level 2: A metadata backup involving all metadata associated with the installation except big data tables.
  • Level 3: Backs up all data, either by performing a cold backup of the /data directory or a hot backup using a third-party tool.

Given these levels, a possible backup strategy would be to perform a level 1 and level 2 backup very frequently, say nightly, and a level 1 and level 3 backup about once a week. The following sections provide more details about these levels.

Light Backup (Level 1)

A light backup targets Controller configuration files like db.cnf and domain.xml. This type of backup lets you avoid having to reconfigure the Controller in case of machine failure.

To perform this type of backup, simply copy everything in the Controller installation directory EXCEPT the data directory.

While it is recommended that you copy the entire Controller home except the data directory when performing a light backup, particularly before performing a Controller upgrade, there are scenarios in which you may wish to copy only site-specific configuration files. This may be the case if you are migrating an existing Controller configuration to a new Controller installation, for example. For a list of those files, see Migrate the Controller between Machines.   

Metadata Backup (Level 2)

A metadata backup exports the data that encapsulates the environment monitored by the Controller. Metadata defines the applications monitored by the Controller, business transactions, policies, and so on. It does not include what can be thought of as "runtime data", the big data tables that contain the metrics, snapshots, events, and top summary stats (top SQL, top URLs, and so on) generated in the monitored environment. By backing up metadata, you can avoid having to reconfigure monitored applications in the Controller in the event of a failure.

To perform this type of backup, run the script described in Using mysqldump to back up the Controller.

Complete Backup (Level 3)

A complete backup saves all runtime data associated with the Controller installation. It captures the actual metrics data, snapshots, and so on.

The AppDynamics Controller uses the default storage engine for MySQL, InnoDB. Since InnoDB supports transactions (in contrast to MyISAM), you cannot simply copy data files directly while the Controller is running. You need to stop the Controller before copying data files. However, some third-party backup tools, such as Percona XtraBackup, do not rely on transactions so you can perform a hot backup of your system (that is, back up the Controller database while it is running).

You can perform a complete backup as either:

  • A cold backup of the /data directory. A cold backup means that, with the Controller app server and database shut down, you create an extra copy of the Controller database using, for example, the "cp -r" command, the tar utility, rsync, or others.  
  • A hot backup, which means the Controller is running. For a hot backup, use a third-party tool such as Xtrabackup, LVM snapshotting, or other third-party tool.

This type of backup allows you to skip the Level 2 backup, since it will include the metadata tables, but you would still need to perform the Level 1 backup to back up the Controller home directory.

Backup Tools

This section lists a few third-party tools that you can use to back up Controller data. The list is not exhaustive; you can use any tool capable of backing up MySQL data with the Controller. However, the tool should back up the data as binary data. 

For Linux systems:

For Windows systems:

An alternative to using a database backup tool is to use a disk snapshot tool to replicate the disk or partition on which the Controller data resides. Options are:

Details for performing this type of backup are beyond the scope of this documentation. For more information, refer to administration documentation applicable to your specific operating system.

Also, contact AppDynamics Support for scripts that can automate back up tasks in your environment. 

Using mysqldump to Back Up the Controller

The mysqldump utility is a MySQL backup tool that is included with the Controller instance of MySQL.

While mysqldump is not recommended for use on large data tables, such as the Controller metric data tables, it is useful for backing up Controller metadata. Metadata defines the monitored domain for the Controller, including applications, business transactions, alert configurations, and so on.

The following instructions assume that the binary path for the Controller's MySQL instance is in the PATH variable. The path to the Controller's instance of MySQL must precede any other MySQL path on your system. This prevents conflicts with other database management systems on your machine, such as a MySQL instance included by default with Linux.

The database binary files for the Controller database are in <controller_install_dir>/db/bin.

To use mysqldump:

  1. Get the root user password for the Controller database. You can get the password for the root user from the following file: 

  2. Run the mysqldump executable, passing the root username, password, and output file. The executable is located in the following directory:

    The command should be in the form:

    mysqldump -u root -p<password> <ignore-table_statements> > /tmp/metadata_dump.sql

For a full example that shows which tables to exclude for a metadata backup, see the contents of the metadata backup script described in the next section.

Sample mysqldump Script

The following script illustrates how to use mysqldump to export Controller metadata while excluding runtime data tables by script. 

To use the script, download the version appropriate for your operating system and modify it as described in the script comments. 

Import Data with mysqldump

After generating a mysqldump export file, you can import it into an empty database as follows:

$install/db/bin/mysql -u controller -psingcontoller controller < metadata_dump.sql

Using a Backup to Migrate to a New Physical Server

You can use either a hot or cold backup procedure to migrate Controller data to a new server. However, we recommend performing cold backups. While a hot backup does not bring down the Controller for an extended amount of time, it does introduce the possibility of data loss, since hot backups capture the state of the data only when the hot backup starts.

To perform a cold backup, simply shut down the Controller and back up the data directory located in <Controller_Installation_Directory>/db.

Learn More


  1. Unknown User (

    The link to the mysqldump script for Windows is wrong, links to the Linux .sh file, this works though:

    1. Thanks for noting this, Michael. The link is fixed.