User Tools

Site Tools

:: Version 2.6.0 ::

2_6_0:admin:backup

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

2_6_0:admin:backup [2019/01/09 16:40] (current)
Line 1: Line 1:
 +====== 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:​
 +
 +{{ backup-menu.png?​nolink |}}
 +
 +This administration page reminds you the current settings, and lists the backup files:
 +
 +{{ backup_page.png?​nolink |}}
 +
 +<note important>​Scheduled backups rely on the background process ''​cron.php''​. Refer to [[2_6_0:​admin:​cron|Background tasks]] for more information about how this is configured.</​note>​
 +
 +Click on **Backup now!** to perform a backup (no confirmation requested):
 +
 +{{ backup_running.png?​nolink |}}
 +
 +
 +==== 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)
 +  * The .xml delta file
 +
 +<note tip>
 +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. 
 +</​note>​
 +
 +<note warning>
 +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.
 +</​note>​
 +
 +
 +===== 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: <​nowiki>​__HOST__</​nowiki>,​ <​nowiki>​__DB__</​nowiki>,​ <​nowiki>​__SUBNAME__</​nowiki>​. Timing information can be given based on [[http://​php.net/​manual/​en/​function.strftime.php|PHP/​strftime]] specifications. | <​nowiki>​__DB__-%Y-%m-%d_%H_%M</​nowiki>​ |
 +| itop_root | string | If backup fails, create a ticket in this iTop. Empty value to use the current iTop. |
 +
 +
 +<note tip>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)</​note>​
 +
 +<note important>​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.</​note>​
 +
 +<note warning>​When the scheduled backups are disabled, the status page still reports the configuration as if it were enabled.</​note>​
 +===== 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:
 +<code php 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)
 +#
 +# 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 : config file param '​itop_backup_incident'​
 +# 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
 +</​code>​
 +
 +<​note>​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.</​note>​
 +
 +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.
 +
 +<note warning>​check-backup.php requires that you have installed the Incident Management module on the installation of iTop targetted by the config parameter //​itop_backup_incident//​ (which can be different than the iTop on which the backup is to be performed).</​note>​
 +
 +===== 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:
 +
 +<​code>​
 +/​usr/​bin/​mysqldump --opt --default-character-set=utf8 --single-transaction --add-drop-database –-user=<​user>​ --password=<​password>​ <DB> | gzip > <​file>​
 +</​code>​
 +
 +On windows systems:
 +
 +<​code>​
 +mysqldump.exe --opt --default-character-set=utf8 --single-transaction --add-drop-database –-user=<​user>​ --password=<​password>​ <DB> > <​file>​
 +</​code>​
 +
 +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.
 +
 +<note warning>
 +  * Make sure that you export the data in UTF-8 MB4 (''<​nowiki>​--</​nowiki>​default-character-set=utf8mb4''​) otherwise accentuated characters will be lost.
 +  * The option ''<​nowiki>​--</​nowiki>​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.
 +</​note>​
 +
 +===== Restoring a backup =====
 +
 +To restore a backup just re-import the MySQL dump and restore the configuration file.
 +
 +<note warning>​**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.</​note>​
 +
 +
 +<note tip>​**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.</​note>​
2_6_0/admin/backup.txt · Last modified: 2019/01/09 16:40 (external edit)

";