Skip to content

Backup and Recovery#

Since the IT-documentation contains important data required for daily work, the backup and recovery of i-doit is essential. Therefore it is important to consider i-doit with regard to the existing backup strategy.

In this context, the following three areas need to be covered: databases, files of i-doit and the system configuration.

If you need to restore i-doit from a complete backup, please use the Migration article

Backup and Recovery of Databases#

For this purpose, you can use the command line tool mysqldump. A simple example for securing all data:

1
mysqldump -hlocalhost -uroot -p --all-databases > backup.sql

The corresponding recovery is this:

1
mysql -hlocalhost -uroot -p < backup.sql

You should not use i-doit during the backup process in order not to corrupt the backup. The Webserver can be deactivated for the time of the backup/recovery. On Debian-based Linux distributions the command

1
sudo service apache2 stop

is executed. When the backup/recovery is finished, the command

1
sudo service apache2 start

can be used to reactivate the Webserver. If applicable, you should also deactivate Cronjobs, which are set up in i-doit, during the data securing process and reactivate them afterwards.

Compressing

A lot of disk space can be saved by compressing the SQL-dumps. For example, the commands mentioned above could look as follows:

Backup:#

1
mysqldump -hlocalhost -uroot -p --all-databases | gzip -9 > backup.sql.gz

Recovery:#

1
gunzip < backup.sql.gz | mysql -hlocalhost -uroot -p

Foreign Key Constraints

When restoring database contents, it may happen that MySQL/MariaDB aborts the process and shows an error message, as for example: errno: 150 "Foreign key constraint is incorrectly formed"

This is caused by the fact that data and structures are restored one after another (meaning table after table). In the meantime, old data exists additionally beside new (restored) data. The database model of i-doit contains many links of tables between each other for which Foreign Key Constraints are used. This reference of, for example, a dataset A in table 1 to a dataset B in table 2, underlies specific automatism when A or B is updated or even deleted. The order is important to determine when A is restored and when B is restored. Old and new references can however use the same indexes even if they express different references. This may lead to the errors mentioned above.

Deleting the databases explicitly before restoring is a suitable workaround for this:

-- Default name of the system database:

1
DROP DATABASE idoit_system;

-- Default name of the first client database:

1
DROP DATABASE idoit_data;

Backup and Recovery of Files#

We recommend securing the complete i-doit folder and - if needed - restoring the complete folder. By using

1
tar -czvf i-doit.tar.gz /path/to/i-doit

you can create a compressed tar-archive.

The corresponding recovery is this:

1
tar -xzv i-doit.tar.gz

Backup and Recovery of the System Configuration#

It is important for the immediate operation of i-doit to secure the configuration files of the Apache Webserver, PHP and MySQL/MariaDB and restore them, if needed. In the best case, you already documented the corresponding changes of the configuration files and stored them safely during the installation process of i-doit.

Backup via VM-Snapshots#

i-doit is often installed on a virtual machine (VM). However, for backup and recovery purposes it does not suffice to simply make snapshots of the VM during operation. The problem is the consistency of the databases: The data may be stored in the working memory but is not (yet) located in the non-volatile memory. Therefore it may be the case that data is not covered by the backup and thus lost if the backup is needed.

If you still do not want to do without snapshots, the DBMS MySQL/MariaDB needs to be stopped beforehand. On Debian-based operating systems this is carried out via the following command:

1
sudo service mysql stop

When the snapshot was taken, the DBMS is restarted:

1
sudo service mysql start

It is surely well understood but still important to mention: Backups should never stay on the system that is being secured.