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.
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:
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
The data (i.e. a full dump of the MySQL database)
The .xml delta file
The automated backup scheme can be adjusted in the iTop
configuration file, in the section
|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|
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:
# 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-126.96.36.199\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
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.
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>
<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
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.
--single-transactionhas 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.
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.
If you backup the iTop database on a Windows server, all the
database table names will be in lowercase. When restored on Linux,
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
This should no longer occur starting with iTop 2.0 beta 2, since all the tables are now in lowercase.