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.
For this purpose, you can use the command line tool
mysqldump can be used. A simple example for securing all data:
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
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.
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:
When restoring database contents, it may happen that MySQL/MariaDB aborts the process and shows an error message, as for example:
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:
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
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:
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.
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:
sudo service mysql stop
When the snapshot has been made was taken, the DBMS is started againrestarted:
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.