Abgrenzung

Nachfolgende Beschreibung bezieht sich auf den Einsatz der Komponente Akeeba-Backup im Umfeld von Joomla. Als dieses kleine Wiki entstand, wurde die Durchführung getestet in einer Joomla-Version 2.5.16 und mit Akeeba Backup 3.8.2. Ich gehe davon aus, dass es unverändert auch in späteren Versionen funktionieren wird. Da die Entwickler der Komponente recht rührig sind und Anregungen auch gern umgesetzt werden, kann es sein, dass dieses Vorhaben für spätere Versionen noch mal vereinfacht wird oder gar automatisiert ablaufen könnte. Spätestens dann ist dieser Beitrag überholt.

Ich werde hier nicht auf Einzelheiten eingehen, die zum Grundwissen des Umgangs mit der Komponente Akeeba-Backup gehören. Hierfür findet man gute Anleitungen in der Akeeba-Dokumentation.

Weiterhin nutze ich ausschließlich die Pro-Version von Akeeba. Ob meine Tipps und Anleitungen auch mit der Core-Version umsetzbar sind, weiss ich nicht - habe ich nicht getestet. Wer diese Komponente wie nachfolgend beschrieben intensiv nutzen will, sollte ruhig mal ins Geldsäckel greifen und den Entwicklern mit dem Kauf der Pro-Version eine kleine Zuwendung zukommen lassen. Es lohnt sich.

Weiterhin gehe ich davon aus, dass Quell- und Zielprojekt auf einem Webserver liegen, so dass Sie auf die Backup-Archive kreuzend zugreifen können. Bei mir ist es üblich, dass Akeeba unterhalb des Webspace-Verzeichnisses des Kunden in einem gemeinsamen Order KundeA/Akeeba-Backup/ und dortige Unterordner für die jeweiligen Sub-Projekte des Kunden schreiben (z.B. KundeA/Akeeba-Backup/ProjektA/).

 

Problembeschreibung / Aufgabenstellung

Mitunter hat man Projekte die aus verschiedenen Gründen teilweise gleiche Daten nutzen. Hier mal zwei praktische Situationen die typisch sind für die Aufgabenstellung:

Situation 1: Für Kunden supporte ich z.B. Projekte bei den in zwei verschiedenen Projekten (andere Domains, andere Templates) teilweise gleiche und teilweise unterschiedliche Daten vorhanden sind. Z.B. wird im Projekt A ein VirtueMart-Shop betrieben, bei dem Produkte für Endverbraucher (B2C) angeboten werden und im Parallelprojekt für B2B-Kunden. Nun möchte der Kunde nicht alle Produkte in beiden Projekten pflegen müssen. Bei 3000 Produkten und fast genauso vielen Kategorie wäre das doppelter Aufwand.

Situation 2: Der Kunde nutzt ein Entwicklungs-Projekt um Daten zu pflegen, weil hier viel ausgetestet werden muss, ehe die neuen Produkte veröffentlicht werden. Von Zeit zu Zeit sollen dann die Produkte in das Produktivsystem übertragen werden - aber eben nur die Produkt- und Kategoriedaten, nichts sonst. Würden z.B. die Kundentabellen mit übertragen, wären ständig auf dem Livesystem die Neukundenzugänge oder aktuelle Bestellungen verloren.

Weitere Situation wären denkbar.

Wenn diese Datenübertragung häufig stattfinden muss, denkt man natürlich darüber nach, wie man diesen Vorgang vereinfachen oder teilautomatisieren kann, ohne den Kunden auch noch phpAdmin oder Adminer oder andere Dumping-Tools zuzumuten. Hier braucht man eine möglichst ungefährliche und elegante Vorgehensweise, die der Kunde auch selbst praktizieren kann. Hierfür soll eine Lösungsvorschlag angeboten werden, der ganz ohne Programmierung funktioniert und den schon guten Funktionsumfang der Backup-Komponente Akeeba verwendet.



 

Anleitung zur Umsetzung des teilweisen Datentransfers

Wie gesagt, die Komponente Akeeba-Backup ist sehr leistungsfähig und bietet die beiden, für unsere Zwecke notwendigen Bausteine an:

  1. Ein Feature mit dem ich ein selektives Backup erstellen kann - also ein Datenbank-Dump aus ausgewählten Tabellen erstellen kann.
  2. Ein Feature mit dem das Einlesen dieses Archives/Dumps über einen Backend-Installer erfolgen kann.

Beide Schritte sind hier beschrieben. Das Know-How besteht aber darin, die richtigen Einstellungen auszuwählen, damit das auch wie gewünscht gelingt und der Akeeba-Backup-Installer die richtien Daten erhält und korrekt arbeiten kann.

 

Schritt 1: Erstellen eines Teil-Backups im Quellprojekt

Damit wir ein teilweises Backup-Archiv unser Quelldaten erstellen können, müssen wir einige Vorbereitungen treffen. Damit diese notwendigen Vorbereitungen nicht bei jedem fälligen Transfer erneut gemacht werden müssen, und auch der Kunde dies nicht machen muss, nutzen wir eine Fähigkeit von Akeeba, Profile anzulegen und speziell zu konfigurieren.

  1. Wir erzeugen also zunächst ein neues Profil über die Profilverwaltung. Nennen wir es z.B. Teiltransfer v. Projekt A zu Projekt B. Dieses neue Profil ist dann nötig, wenn wir über das Default-Profil unsere übliche Projektkomplettsicherung machen wollen. Wer nicht mehrere Profile benötigt, kann auch das Default-Profil modifizieren - was ich aber auch aus anderen Gründen nicht empfehle.
  2. Dieses Profil aktivieren wir in der Aktives Profil Pulldownliste und beginnen danach mit dessen Konfiguration. Ich gehe nicht alle Optionen im Detail durch. Davon ausgehend, dass Sie die Standardeinstellungen, die bei der Installation vorgeschlagen/optimiert ermittelt wurden verwenden, benenne ich nur die notwendigen Abweichungen davon.
  3. Eine Option die wir nicht ändern, die aber unbedingt so eingestellt sein muss, sei erwähnt. Unter der Konfiguration gibt es die Option Art der Sicherung. Diese muss auf Gesamte Seite (Dateien und Datenbank) stehen! Das ist sehr wichtig! Bei meinen Versuchen war ich erst der Auffassung, es würde genügen, Nur die Datenbank oder gar nur Alle angebebenen Datenbanken auszuwählen. In diesen Fällen wird aber ein DB-SQL-Dump erzeugt, der keinen Installer enthält(!). Das macht das Restoring kompliziert und nicht über den ABI möglich. Also aufpassen!
  4. Hilfreich für das spätere Auffinden der Archive anhand eines sprechenden Dateinamens kann man unter der Option Name für die Sicherungsdatei noch den Aufbau des generierten Archivnames anpassen. Ich empfehle z.B. eine folgende Syntax: projektA_2_projektB-[HOST]-[DATE]-[TIME].
  5. Als nächstes wählen wir den Bereich Datenbanktabellen ausschließen über das Icon auf dem Profil-Dashbord. In dem dortigen Dialog schließen wir alle Tabellen aus, die nicht mit ins Transferarchiv gepackt werden sollen.
  6. Auch dieser Schritt ist nun wieder etwas ungewöhnlich. Eigentlich sprachen wir ja davon nur Daten zwischen den Projekt übertragen zu wollen - kein Scripte oder sonstige Projektdateien. Trotzdem müssen wir genau das tun, denn das stellt überhaupt erst sicher, dass der benötigte ABI mit ins Installationsarchiv gepackt wird! Unter dem Dashbord-Icon Ausschluss von Dateien und Verzeichnissen können wir festlegen welche Dateien ausgeschlossen werden sollen. Wir machen uns mal die Mühe und schließen alle aus, bis auf ein oder zwei Dateien, die aber so gewählt werden sollten, dass diese gänzlich unbedeutend sind und keine Auswirkungen auf das Zielprojekt haben. Das sind z.B. die README.txt und LICENCE.txt im Joomla-Root-Verzeichnis. Nur diese beiden lassen wir ins Archiv packen.

Das war's nun schon zur Konfiguration des Profils. Nun kann man über Jetzt sichern mit diesem Profil ein Backup-Archiv erstellen und der erste Schritt wäre erledigt.

Wer möchte kann dann mittels Akeeba das Archiv gleich noch in einem Cronjob regelmäßig automatisiert erstellen lassen (s. Akeeba-Dokumentation).



 

Schritt 2: Einlesen des Dumb-Archives in das Zielprojekt

Unser Archiv liegt nun im Backup-Pfad, wie oben beschrieben z.B. im Verzeichnis ~/kundeA/Akeeba-Backup/projektA/. Dieses Teil wollen wir nun ins Zielprojekt holen. Wir nutzen dafür die Wiederherstellen-Funktion innerhalb des Sicherung verwalten - Bereiches von Akeeba.

  1. Zunächst müssen wir dieses Archiv der Akeeba Sicherungen-Verwaltung bekannt machen. Das erfolgt durch die Nutzung von der Dateien importieren-Funktion unter Sicherung verwalten. Hier also den Pfad zurück gehen zu unserem Kunde-Webspace-Root und von dort in das benachbarte Unterverzeichnis für Akeeba-Backup/projektA/ gehen. Dieses Verzeichnis nutzen und dann dort nach Dateien suchen lassen. Im der Trefferliste finden wir nun unser oben erstelltes Archiv projektA_2_projektB-.....jpa und wählen es für den Import aus.
  2. In der Verwaltungsliste für unser Sicherungen ist nun auch dieses Archiv eingebunden. Über den Funktionsbutton Wiederherstellung beginnen wir den Restoring-Prozess.
  3. Hier wird nun also der komplette und übliche Akeeb-Restore-Prozess durchlaufen, der hier ebenfalls nicht beschrieben wird, weil er Bestandteil des allg. Akeeba-Wissens ist und entspr. dokumentiert ist. Wichtig ist jedoch zu beachten, dass man die Zieldatenbank im Prozess auswählt - eben nicht die Quelldatenbank verwendet und ggf. auch den Tabellen-Präfix anpasst, wenn dieser zw. Quell- und Zieldatenbank unterschiedlich verwendet wird. Ansonsten unterscheidet sich nichts von der Vorgehensweise einer üblichen Wiederherstellung.

Und das war es dann auch schon. Aus Interesse kann man auf dem Zielsystem mal ins Joomla-Root-Verzeichnis schauen und stellt fest, dass die o.g. README.txt und LICENCE.txt mit dem Datum des Quellsystem angelegt wurden - als ein Zeichen einer erfolgreichen "Wiederherstellung" (Achtung! Akeeba stellt das Dateidatum so wieder her wie es auf dem Quellsystem war).

 

Abschließende Anmerkungen

Wer diesen Vorgang wirklich oft durchführt, sollte evtl. in beiden Projekt den gleichen Tabellen-Präfix verwenden. Das spart dann zumindest beim Import die notw. manuelle Anpassung, und vermeidet diese Stolperfalle. Zu spät, Ihre Präfixe sind schon unterschiedlich und Sie wollen diese nicht aufwändig umbenennen? Hier ein kleines feines Script, mit dem Sie mit einem Ruck sämtliche Präfixe z.B. einer Joomla-Projekt-Datenbank umbenennen können.