Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Table of contents, text review
Div
outlinetrue
stylenonewidth: 30%; float: right;
idtoc
Panel
titleContents

Table of Contents
outlinetrue
stylenone
printablefalse

 

Since the IT-documentation contains important data which is necessary required for daily work, the backup and recovery of i-doit is essential.  Here 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.

Backup and Recovery of Databases

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

...

Code Block
mysql -hlocalhost -uroot -p < backup.sql 

In You should not use  i-doit during the backup process , i-doit should not be used 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

...

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

Code Block
languagebash
sudo service apache2 start

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

Tip
titleCompressing

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

Code Block
languagebash
# Backup:
mysqldump -hlocalhost -uroot -p --all-databases | gzip -9 > backup.sql.gz
 
# Recovery:
gunzip < backup.sql.gz | mysql -hlocalhost -uroot -p

Note
titleForeign 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 to the beside new (restored) data. The database model of i-doit contains many links of tables to 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 automatisms if 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. So it can This may lead to the errors mentioned above.

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

Code Block
languagebash
-- Default name of the system database:
DROP DATABASE idoit_system;
 
-- Default name of the first client database:
DROP DATABASE idoit_data;

 

Backup and Recovery of

...

Files

It is recommended to secure the whole folder of We recommend securing the complete i-doit folder and restore it - if needed . Using- restoring the complete folder. By using

Code Block
languagebash
tar -czvf i-doit.tar.gz /pfad/zu/i-doit

you can create a compressed tar-archive can be created.

The corresponding recovery is this:

Code Block
languagebash
tar -xzv i-doit.tar.gz

Backup and Recovery of the System Configuration

It is important for the immediate use 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 in during the installation process of i-doit.

Backup via VM-Snapshots

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

If snapshots are you still do not to be given upwant to do without snapshots, the DBMS MySQL/MariaDB needs to be stopped before making thembeforehand. On Debian-based operating systems this is done carried out via the following command:

Code Block
languagebash
sudo service mysql stop

When the snapshot has been made was taken, the DBMS is started againrestarted:

Code Block
languagebash
sudo service mysql start

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