Daten sichern und wiederherstellen#
Da sich in der IT-Dokumentation wichtige, für die tägliche Arbeit benötigte Daten befinden, ist ein Backup und Recovery von i-doit unablässig. Daher sollte i-doit bei der bereits bestehenden Backup-Strategie berücksichtigt werden.
Hierbei müssen drei Bereiche abgedeckt werden: die Datenbanken, die Dateien von i-doit und die Systemkonfiguration.
Sollte i-doit aus einem kompletten Backup wiederhergestellt werden müssen, dann nutzen Sie bitte die Migrations Artikel
Backup und Recovery der Datenbanken#
Hierzu kann das Kommandozeilen-Tool mysqldump verwendet werden. Ein einfaches Beispiel zum Sichern aller Daten:
1 | |
Das entsprechende Recovery:
1 | |
Während eines Backups sollte i-doit nicht verwendet werden, um die Backups nicht zu korrumpieren. Für die Zeit des Backups bzw. des Wiederherstellens kann der Webserver deaktiviert werden. Auf Debian-basierten Linux-Distributionen führt man
1 | |
aus. Nach dem Backup/Recovery kann mit
1 | |
der Webserver wieder aktiviert werden. Sind Cronjobs für i-doit eingerichtet, sollten diese ebenfalls während der Sicherung deaktiviert und nach Abschluss wieder aktiviert werden.
Komprimieren
Viel Speicherplatz kann man sparen, indem die SQL-Dumps komprimiert werden. Die obigen Befehle könnten demnach so aussehen
Backup:#
1 | |
Recovery:#
1 | |
Foreign Key Constraints
Beim Wiederherstellen von Datenbank-Inhalten kann es vorkommen, dass MySQL/MariaDB mit einer Fehlermeldung abbricht, etwa: errno: 150 "Foreign key constraint is incorrectly formed"
Dies liegt daran, dass die Daten und Strukturen nacheinander, d. h., Tabelle für Tabelle wiederhergestellt werden. Zwischenzeitlich existieren demnach alte neben neuen (wiederhergestellten) Daten. Das Datenbank-Modell von i-doit enthält sehr viele Verknüpfungen von Tabellen untereinander, für die Foreign Keys Constraints verwendet werden. Diese Referenzierung von beispielsweise einem Datensatz A in Tabelle 1 auf Datensatz B in Tabelle 2 unterliegt bestimmten Automatismen, wenn A oder B aktualisiert oder gar gelöscht werden. Die Reihenfolge spielt dabei eine wichtige Rolle, wann A und wann B wiederhergestellt werden. Alte und neue Referenzen können allerdings dieselben Indizes verwenden, auch wenn sie unterschiedliche Referenzierungen ausdrücken. Dadurch kann es zu oben genannten Fehlern kommen.
Als Workaround bietet es sich an, die Datenbanken vor der Wiederherstellung explizit zu löschen:
-- Standard-Name der System-Datenbank:
1 | |
-- Standard-Name der ersten Mandanten-Datenbank:
1 | |
Backup und Recovery der Dateien#
Es empfiehlt sich, das gesamte Verzeichnis von i-doit zu sichern und bei Bedarf wiederherzustellen. Mittels
1 | |
kann ein komprimiertes Tar-Archiv erstellt werden.
Das entsprechende Recovery:
1 | |
Backup und Recovery der Systemkonfiguration#
Wichtig für den unmittelbaren Betrieb von i-doit ist es, die Konfigurations-Dateien vom Apache Webserver, von PHP und von MySQL/MariaDB zu sichern und bei Bedarf wiederherzustellen. Bestenfalls hast du bereits bei der Installation von i-doit die entsprechenden Anpassungen an den Konfigurationsdateien dokumentiert und sicher hinterlegt.
Backup mittels VM-Snapshots#
Häufig wird i-doit auf einer virtuellen Maschine (VM) installiert. Für ein Backup und Recovery reicht es allerdings nicht aus, schlicht Snapshots der VMs im laufenden Betrieb zu erstellen. Das Problem liegt in der Konsistenz der Datenbanken: Die Daten liegen eventuell im Arbeitsspeicher und befinden sich (noch) nicht im nichtflüchtigen Speicher. Sie werden demnach durch die Sicherung oftmals nicht erfasst und gingen im Fall des Falles verloren.
Soll auf Snapshots dennoch nicht verzichtet werden, muss vorher das DBMS MySQL/MariaDB gestoppt werden. Auf Debian-basierten Linux-Betriebssystemen erledigt dies der Befehl:
1 | |
Nach dem Snapshot wird das DBMS wieder gestartet:
1 | |
Sicherlich hinreichend bekannt, aber dennoch wichtig zu erwähnen: Backups sollten niemals auf dem System verbleiben, das gesichert wird.