Data backup

In iTop all the data (including the uploaded documents) are stored in the MySql database. Therefore it is highly recommended to have a database backup in place on a regular basis.

Integrated backups

Starting with iTop 2.1.0, a special menu “Scheduled backups” is available to the administrators:

This administration page reminds you the current settings, and lists the backup files:

Scheduled backups rely on the background process cron.php. Refer to Background tasks for more information about how this is configured.

Click on Backup now! to perform a backup (no confirmation requested):

What does a backup contain?

A backup is made of a single zip file.

It contains all the data that is necessary to restore the application:

The configuration (i.e. the configuration file itop-config.php)
The data (i.e. a full dump of the MySQL database)

If you have installed new modules after running a backup, restoring the backup is equivalent to uninstalling the modules. Run the setup again if you wish to have the modules back into the iTop.

If you have upgraded iTop or any of the modules since the backup has been made, then it is not garanteed that restoring will work fine. In any case it is safer to run the setup again.

Configuration

The automated backup scheme can be adjusted in the iTop configuration file, in the section itop-backup:

Parameter	Type	Description	Default Value
mysql_bindir	string	Directory of the MySQL binaries if not in the “path”. Used both for the scheduled backups and as the default value for the REST services
week_days	string	CSV list of week days (lowercase) when the automated backup must be performed	monday, tuesday, wednesday, thursday, friday
time	string	24h based time when the automated backup must be performed	23:30
retention_count	int	Number of backup files that will be kept in the target directory	5
enabled	bool	Switch on/off the automated backups	true
file_name_format	string	Name of the backup (zip), only for the scheduled backups. The following placeholders are supported: __HOST__, __DB__, __SUBNAME__. Timing information can be given based on PHP/strftime specifications.	__DB__-%Y-%m-%d_%H_%M

To check the configuration, have a look the backup administration page: the configuration summary will explain how the configuration is interpreted (or report the issue if any is found)

Changes in the scheduling (including disabling the feature) will be taken into account at the next time a backup was planned before the change took place.

When the scheduled backups are disabled, the status page still reports the configuration as if it were enabled.

Custom scheduling

An alternative to the automatic scheduling is to implement your own scheduling, relying on the provided REST services to perform the backup or to monitor the process.

A file backup.params.distrib is provided to explain the parameters:

backup.params.distrib

# Parameters file for backup.php and check-backup.php
#
# Usage:
# backup.php --param_file=<this file>[,<another one>]
# or
# http://.../itop-backup/backup.php?param_file=<this file>[,<another one>]
#
# If a parameter is given both in the file and in the arguments,
# then the value given as argument is retained
#
# Note: most of the default values provided here should work fine
#       if you have created sample data with the setup program

# MySQL coming with Easy PHP (Windows)
mysql_bindir = C:\Program Files\EasyPHP-5.3.6.0\mysql\bin
 
 
# Authentication
auth_user = admin
auth_pwd = admin
 
# Target file - path and filename (optional, could be a relative directory when used in CLI mode)
#
# Formatting rules:
# %Y-%m-%d => 2011-01-25... see PHP documentation of strftime()
# Placeholders:
#    __HOST__      MySQL server
#    __DB__        Database name
#    __SUBNAME__   Tables prefix
# 
backup_file = /var/log/__DB__-%Y-%m-%d
 
# Check thresholds (check-backup.php)
#
check_size_min = 20000 # bytes
check_size_reduction_max = 10 # percentage

# Ticket creation (check-backup.php)
#
# If the backup has failed, a ticket will be created
# This process relies on the SOAP service "CreateIncident"
#
# Root URL of an instance of iTop, into which the ticket will be created
check_ticket_itop = http://localhost/myiTop 
# Any of the above paramaters are mandatory
check_ticket_login = admin # must have the right to create an Incident Ticket
check_ticket_pwd = admin
check_ticket_title = Backup check failed
check_ticket_customer = Demo
check_ticket_service = Computers and peripherals
check_ticket_service_subcategory = Repair
check_ticket_workgroup = Hardware support
check_ticket_impacted_server = dbserver1.demo.com

By default, mysql_bindir is taken in the configuration of the module. If it is specified in the parameters file or the command line, then that value will have precedence. On the other hand, the file name must be specified either in a parameters file or in the command line. Moreover, the filename must be specified along with the full path, or relatively to the current directory.

About check-backup.php: This is a monitoring utility. It must be executed after backup.php. It verifies that the file does exist as per the filename specifications. Also, it aims at detecting suspicious changes in the file size.

check-backup.php requires that you have installed the Incident Management module on the installation of iTop targetted by the parameter check_ticket_itop (which can be different than the iTop on which the backup is to be performed).

Creating your backups using mysqldump

As in previous versions of iTop, you can still create your own backups using the mysqldump command line utility which comes with MySQL.

You can run a full backup of the database using the following mysqldump command:

On Linux systems:

/usr/bin/mysqldump --opt --default-character-set=utf8 --single-transaction --add-drop-database –-user=<user> --password=<password> <DB> | gzip > <file>

On windows systems:

mysqldump.exe --opt --default-character-set=utf8 --single-transaction --add-drop-database –-user=<user> --password=<password> <DB> > <file>

Where:

<user> is the user name to connect to MySQL
<password> is the corresponding password
<DB> is the name of the database in which iTop is installed
<file> is the name of the archive file to produce

Once the content of the database is dumped, just archive this dump and the file conf/production/config-itop.php to keep a full image of your iTop instance.

Make sure that you export the data in UTF-8 (--default-character-set=utf8) otherwise accentuated characters will be lost.
The option --single-transaction has two effects: it produces a consistent backup since all tables are exported in one transaction, and it provides a workaround for the error 1449 (definer does not exist) which may happen if you export a database that was already re-imported from another system or created by a no longer existing user.

Restoring a backup

To restore a backup just re-import the MySQL dump and restore the configuration file.

Passwords encryption

If the datamodel uses password fields with reversible encryption, then be sure that the same encryption algorithm is used on the new and old systems: if the mcrypt PHP extension was present on the old system, then the mcrypt extension must be present on the new system as well. If mcrypt was not present, it must not be present either.

Note: User accounts passwords use a one-way encryption and are not affected by the presence of mcrypt.

Restoring a Windows Backup on Linux (iTop 1.x and 2.0 beta 1 only)

If you backup the iTop database on a Windows server, all the database table names will be in lowercase. When restored on Linux, the table priv_internalUser will be spelled priv_internaluser, which is different. In you cannot log into iTop after restoring a backup, check that the table is properly spelled. If needed, remane the table to priv_internalUser.

This should no longer occur starting with iTop 2.0 beta 2, since all the tables are now in lowercase.

Sidebar