Da ich nicht weiß, wie lange die ursprünglichen Websites noch “am Netz” sind, möchte ich auf dieser Seite alle Ressourcen zusammentragen.

Drush-Session v1.0 in Deutsch

Beim Drupal Day MV im März 2011 hielt ich den Drush-Vortrag zum ersten Mal und in Deutsch.

• Vorstellung der Session auf der DrupalDay-Website
• Drush – Website-Administration leicht gemacht als PDF
• Drush-Website-administrationLeichtGemacht, der Video-Mitschnitt auf archive.org

Drush-Session v2.0 in Englisch

Ich hatte die Session vom Drupal Day MV noch mal für das DrupalCamp in Berlin eingereicht, diesmal in Englisch. Die Gelegenheit habe genutzt, die “Folien” nicht nur ins Englische zu übersetzen, sondern auch inhaltlich zu überarbeiten und mit meinem Wissensstand abzugleichen. Dem Englisch-Kundingen empfehle ich also dieses PDF (aber nicht das Video ;)

• Vorstellung der Session auf der DrupalCamp-Website
• Drush – managing drupal – the easy approach als PDF,
• Drush – managing drupal – the easy approach, der Video-Mitschnitt auf Vimeo.

Damit haben ich (nahezu) alles zu Drush gesagt, für meine nächste Session werde ich mir ein neues Thema suchen. Wenngleich die site aliases mit ihrer Mächtigkeit noch ein paar Blogposts verdient hätten. :)

“Multisite” ist eine raffinierte Funktion, um mehrere Drupal-Websites aus einer Codebasis zu betreiben: Im Webserver werden mehrere Domainnamen auf das selbe Drupal-Installationsvverzeichnis konfiguriert. Beim Seitenaufruf ermittelt Drupal den Domainnamen zum Request, sucht im Ordner sites/ den passenden Ordner mit den Konfigurationsdaten. Wenn es für die gesuchte Domain keinen Ordner gibt, dann wird im Ordner sites/default/ nachgesehen. Die im Konfigurationsordner vorhandene Datei settings.php enthält unter anderem die nötigen Datenbank-Informationen und Drupal liefert mit den in der Datenbank abgelegten Daten schließlich die Webseite aus. Eine detaillierte Beschreibung zu Multisites liefert das Handbuch auf drupal.org sowie die Linkliste am Podcastbeitrag.

Diese Funktion war ein unverzichtbares Hilfsmittel, als Festplattenkapazität auf dem Server kostbar war und FTP die einzige administrative Zugriffsmöglichkeit auf den Server war: Bei der Installation einer neuen Website braucht man nur einen neuen Konfigurationsordner anlegen, die settings.phpdorthin kopieren und anpassen und eine neue Datenbank befüllen. Beim Update eines Moduls kopiert man die von drupal.org heruntergeladene Modulversion per FTP auf den Server und ruft für jede Website die Updatefunktion im Browser auf. Und genau diese Arbeitserleichterng ist das Problem mit Multisites: Nach dem Austauschen der Moduldateien muss man sofort die Datenbank-Updates auf allen Websites durchführen. Das kann natürlich einige Zeit dauern, und so lange sind unter Umständen (bis zu n-1) Websites dieser Multisite-Installation zerbrochen. Und man muss darauf vertrauen, dass das Modul-Update keine der Websites “zerbricht” — also gleich noch testen, was wiederum wieder viel Zeit beansprucht. Und wie geht man vor, wenn nun Eine der Multisites nach dem Update nicht mehr funktioniert? Viel Handbareit und eine erstmal zerbrochene Website bleiben zurück.

Seit rund 3 Jahren betreibe ich (fast) alle meine Drupal-Sites auf Webhostings, bei denen ich mich per ssh auf dem Server einloggen und die Websites administrieren kann. Bei den großen Anbietern bekommt man solch ein Hosting ab ~10 Euro je Monat. Alternativ dazu kann man sich für den Preis auch einen vServer klicken. Ich bin großer uberspace-Fanboy, dort bekommt man ein Webhosting mit ssh-Zugang (und sehr vielem mehr) für den Preis, den mit das Angebot wert ist. Ich folge mittlerweile der Empfehlung der Betreiber und habe für jede Website einen eigenen Uberspace (also ein eigenes Benutzerkonto auf einem der Uberspace-Server), weil auch die E-Mail-Konfiguration per Uberspace erfolgt und ich so jedem Kunden problemlos Ssh-Zugang zu “seinem” Uberspace geben kann.

Nun fragt Ihr vielleicht, wie viel mehr Zeit ich für ein so verteiltes Hosting investieren muss? Deshalb hier noch ein paar Ausführungen dazu. Ich bin bekanntermaßen begeistert von drush, dem Kommandozeilenwerkzeug für Drupal. Natürlich ist drushauf allen Uberspaces installiert. Ich pflege eine Vorlage für ~/.drush auf meinem lokalen Rechner und die wird — zusammen mit weiteren Konfigurationsdateien — in jeden neuen Uberspace kopiert. Aktualisierung des Setups ist auch schnell getan:

cd ~/uberspace_template   
for i in $(uberspaces)   
do
  echo "*** $i ***"
  rsync -var . $i:
done

Das $(uberspaces) habe ich kürzlich beschrieben.

Auf dem Uberspace kann ich nun mit drush schnell ein Backup der Website machen, Module aktualisieren und ein fälliges Update in Sekundenschnelle auf einer Kopie der produktiven Website testen.

drush rsync @live @test   
drush sql-sync @live @test
drush @test up views
# und nun Testen
drush @live bam-backup
drush @live up views

Details dazu und den obligatorischen Hinweis auf environment_indicator.module findet Ihr in dem frühren Blogbeitrag.

Um herauszufinden, welche meiner Drupal-Installationen von einem nötgen Update betroffen sind, läuft dieses Sktipt von meinem lokalen Rechner aus:

for i in $(uberspaces)
do
  echo "*** $i ***"
  ssh $i "find /var/www/virtual/$i -type f -name modulname.module"
done

Um es noch einfacher zu haben, habe ich alle Dateien aliases.drushrc.php vom Server auf meinen lokalen Rechner kopiert und den Namen des Uberspaces als Prefix vorangestellt

for i in $(uberspaces)
do
  echo "*** $i ***"
  scp $i:.drush/aliases.drushrc.php ~/.drush/$i.aliases.drushrc.php 
done

Dann noch die Paramater remote-hostund remote-user in den Aliases ergänzen und ich kann vom lokalen Rechner aus Drush-Kommandos auf dem Uberspace ausführen, ohne mich vorher dort anmelden zu müssen:

drush @uberspacename.live st

Das vergangene halbe Jahr seit meinem Umzug zu uberspace.de mit strengen Separation aller Websites auf eigene Benutzerkonten (Accounts) hat gezeigt, dass dieser Workflow robust ist und mit drush, git, komfortablem Backup auf Systemebene und all den anderen Helferlein keinen Mehraufwand gegenüber einem eigenen Server mit allen Websites unter /var/www bringt. Dafür aber Zuverlässigkeit der Plattform, schnell durchgeführte Drupal-Updates und einen freigestellten Linux-Admin.

Nun bin ich auf Deine Meinung gespannt. Wie administrierst Du Deine Drupal-Sites? Was für Hosting-Pakete favorisierst Du wie passt Dein Provider zu Dir? Und: Nutzt Du noch Multisites und ich habe irgend ein cooles Feature aus den Augen verloren?

Mittlerweile habe auch ich meine erste Website auf der Codebasis am Start. Ein paar weitere Module habe ich per git submodule vom Repository git://git.drupalcode.org/ nach installiert.

Und die erste Bewährungsprobe hat das Setup schon mit Bravour bestanden: Das Drupal-Update vor einer Woche und die Views-Sicherheitsaktualisierung zur gleichen Zeit waren in Bestzeit mit

# git pull
# drush updatedb

aktualisiert. Das geht noch schneller als mit einem reinen Drush-Workflow. Und als Website-Betreiber hat man die Gewissheit, dass die Module in der Konfiguration zusammenpassen und das Update schmerzfrei sein kann. Ein Dank für den Service an Freistil Consulting!

Ich installiere Drush üblicherweise ins Verzeichnis /usr/local/share/drush, was mit

# cd /usr/local/share
# git clone git://git.drupalcode.org/project/drush
# ln -sf ../share/drush/drush /usr/local/bin/drush
# cd drush
# git tag
...
6.x-4.0-rc1
6.x-4.0-rc3
7.x-1.0-rc2
...
# git checkout 6.x-4.0-rc3

geschieht. Der Befehl git tag zeigt die Drush-Releases an, mit git checkout 6.x-4.0-rc3 wird die gewünschte Release eingestellt (in einem lokalen Git-Repository sind ja alle Versionen und damit auch alle Releases des Projekts enthalten).

Nun kann mit git pull jederzeit das Repository aktualisiert und eine neuere Drush-Version eingestellt werden. Und sollte es mit dem Releasekandidat (rc) Probleme geben, dann schaltet man einfach mit git checkout 6.x-3.3 die aktuelle stabile Version aus.

Geht es einfacher? ;-)

Update: Bei dem hier beschriebenen Setup gehe ich davon aus, dass der Rechner (ein Server?) von mehreren Benutzern genutzt wird. Deshalb die Installation unter /usr/local. Nutzt nur ein Benutzer auf dem Rechner drush, dann kann das der Benutzer gern in seinem Heimatverzeichnis installieren.

In Drupal lässt sich ja mit drush site-aliases und den drush-Kommandos rsync und sql-sync elegant ein Setup mit Staging-Site und Live-Site auf einem Server umsetzen, wie kürzlich hier beschrieben. Ziel war dabei, schnell eine Kopie einer Drupal-Website zu erstellen, um daran z.B. Modul-Updates zu testen oder neue Konfigurationen, Module und Themes auszuprobieren.

Das Prinzip lässt sich nun leicht auf den eigenen Rechner ausdehnen. Ich habe z.B. viele meiner aktiv zu entwickelnden Website-Projekte auf meinem Notebook dabei und kann unabhängig von Internet-Verbindung und ssh-Latenz daran weiter arbeiten.

Vesa Palmu hat sehr gut und umfassend beschrieben, wie man sich unter Mac OS eine Drupal-Entwicklungsumgebung einrichtet. Er nutzt die nativen Werkzeuge des OS, eine Alternative ist MAMP. Linux-Benutzer haben auch meist alle Dienste installiert und müssen evtl. lediglich MySQL nach installieren. Windows-Anwender sollten wohl auch XAMPP setzen, um damit zum Erfolg zu kommen. Acquia bietet für alle genannten Betriebssysteme den Acquia Drupal Stack-Installer, der sicher auch eine sehr gute Wahl ist. Ich mag es nativ und habe den erstgenannten Weg gewählt.
Anmerkung: Drush soll auch unter Windows lauffähig sein. Ich habe das nicht getestet.

Nun legt man im Heimatordner den Ordner .drush an und installiert dort drush. Vorzugsweise via Git, weil damit die Aktualisierung der Drush-Installation am einfachsten ist.

cd ~/.drush
git clone git://git.drupalcode.org/project/drush.git
cd drush
git checkout 6.x-4.0-rc3

Der letzte Befehl aktiviert die derzeit neueste drush-Version. Alle verfügbaren Versionen in einem Projekt werden getaggt und können so leicht ermittelt werden:

git tag

Nun noch die Datei aliases.drushrc.php vom im Ordner ~/.drush anlegen (oder vom Server kopieren). Dort werden die beiden Drupal-Installationen auf dem Server eingetragen, in den Feldern remote-host und remote-user die ssh-Zugangsdaten zum Server ergänzen und einen Eintrag für die lokale Installation auf dem Notebook hinzugefügt.

<?php
$aliases['test'] = array(
  'uri' => 'test.beispiel.de',
  'root' => '/var/www/test.beispiel.de',
  'remote-host' => 'www.beispiel.de',
  'remote-user' => 'ich',
);
$aliases['live'] = array(
  'uri' => 'beispiel.de',
  'root' => '/var/www/beispiel.de',
  'remote-host' => 'www.beispiel.de',
  'remote-user' => 'ich',
);
$aliases['dev'] = array(
  'uri' => 'l.beispiel.de',
  'root' => '/Users/drue/Sites/test.beispiel.de',
  'db-url' => 'mysql://web1:MySecret@localhost/usr_web1_3',
);

Ich definiere für jede meiner lokalen Projekt-Websites als Domainname den ursprünglichen Domainname mit einem vorangestellten “l.”. Der Domainname, hier l.beispiel.de wird in /etc/hosts (bei Mac OS und Linux, Windows-User müssen die Datei hosts irgendwo unter c:\windows suchen) eingetragen.
Der Datenbank auf dem lokalen Rechner gebe ich üblicherweise den selben Namen und das selbe Passwort wie auf dem Originalsystem. Da es auf dem lokalen Rechner noch keine Drupal-Installation und damit keine Datei settings.php gibt, muss die Datenbank-URL hier angegeben werden und wird dann in die Datei settings.php übernommen. Die Datenbank muss im MySQL-Server angelegt werden und die Zugriffsberechtigungen korrekt eingestellt werden.

Nun muss dem Apache noch gesagt werden, was er bei Aufrufen der Domain l.beispiel.de ausliefern soll (hier als Minimalversion).

<VirtualHost *:80>
  ServerAdmin dirk@rueweb.de
  DocumentRoot /Users/drue/Sites/l.beispiel.de
  ServerName l.beispiel.de
</VirtualHost>

Nun kann der Transfer der Drupal-Site starten:

drush rsync @live @dev
drush sql-sync @live @dev

Fertig. Nun kann man immer an einer Website arbeiten, ohne immer Verbindung zur Server haben zu müssen.

Achja, nochwas: Wenn das Server-OS nicht gleich lokalen OS ist, bei mir Linux und Mac OS, dann kann es zu einem Problem beim sql-sync kommen, da die Pfade zum Ordner für temporäre Dateien kommen, bei Linux /tmp und bei Mac OS /private/tmp.

mysqldump: Can't create/write to file '/private/tmp/beispiel.de_usr_web1_3.sql.TjyIrx' (Errcode: 2)

Ich habe das nur so lösen können, indem ich auf dem Server das Verzeichnis angelegt habe, welches auf dem Client für temporäre Dateien genutzt wird.

mkdir /private/tmp
chmod 0777 /private/tmp

Drush ist erste Wahl bei der Administration einer Drupal-Website. Und seit Drush auch Site-Aliases kennt, kann man auch “Server voller Drupal-Sites” entspannt verwalten. Bei den Lullabots  ist eine sehr gute Beschreibung zu site-aliases zu finden.

Nun lassen sich diese Site-Aliases nutzen, um zu einer vorhandenen Website eine Testversion anzulegen. Das Ziel ist dabei, eine Kopie einer Website anzulegen, an der man neue Module ausprobieren, Themes überarbeiten oder Konfigurationen testweise ändern kann (und ich könnte hier noch viele andere Gründe nennen…).

Anmerkung: Bei dieser Beschreibung nehme ich an, dass die Live-Website unter der Domain “beispiel.de” erreichbar ist und die Staging-Website unter “test.beispiel.de” aufrufbar sein soll.    Für dieses Setup nutze ich nicht Drupals Multisite-Funktion, sondern zwei getrennte Verzeichnisse. So kann man auf der Staging-Site leicht Module aktualisieren oder austauschen, ohne die Funktion der Live-Site zu gefährden.

Die Einrichtung dieses Setups ist recht einfach.  Zuerst erstellt man die Datei $HOME/.drush/aliases.drushrc.php und beschreibt dort die beiden Websites.

<?php   
$aliases['test'] = array(   
  'uri' => 'test.beispiel.de',   
  'root' => '/var/www/test.beispiel.de',   
);   
$aliases['live'] = array(   
  'uri' => 'beispiel.de',   
  'root' => '/var/www/beispiel.de',   
);   
?>

Die Schlüsselwerte des Arrays $aliases sind die Site-Aliases, in unserem Fall “live” und “test”. Diese werden mit vorangestelltem @ als Drush-Argumente angewendet.

Nun legt man eine weitere Datenbank in MySQL (oder PostgreSQL) an, kopiert mit Drush den Ordner mit der Live-Installation in ein anderes Verzeichnis und passt in der Datei settings.php die $db_url an.

drush rsync --include-conf @live @test   
cd /var/www/test.beispiel.de/   
vim sites/beispiel.de/settings.php

Als Nächstes muss die Datenbank aus der Live-Site noch mittels Drush in die Datenbank der Test-Site kopiert werden.

drush sql-sync @live @test

Jetzt muss man noch dafür sorgen, dass die Test-Website von draußen erreichbar ist und dafür den Webserver anpassen, und ggf. auch den Nameserver.

Nun kann die Test-Website aufgerufen und bearbeitet werden. Um nicht die Übersicht zu verlieren, bietet sich das environment_indicator.module an. Mit dessen Hilfe wird auf der Website eine unaufdringliche Kennzeichnung der Live- und Test-Website an.

Das sieht für die Test-Site so:

$conf['environment_indicator_text'] = 'TEST SITE';   
$conf['environment_indicator_color'] = 'dark-red';   
$conf['environment_indicator_enabled'] = TRUE;

und für die Live-Site so:

$conf['environment_indicator_text'] = 'LIVE SITE';   
$conf['environment_indicator_color'] = 'green';   
$conf['environment_indicator_enabled'] = TRUE;

aus.

Sollen nun neue Module, Themes oder Konfigurationsänderungen an der Test-Site ausprobiert werden, so kopiert man “mal eben” die Datenbank und das Verzeichnis der Live-Site in die Test-Site und kann loslegen.

drush sql-sync @live @test   
drush rsync @live @test

Drush kopiert dabei alle Dateien, schließt jedoch die settings.php aus, so dass die Datenbank-Zuordnung der Test-Site erhalten bleibt. Das Verhalten von drush rsync kann umfangreich angepasst werden, Details dazu bietet die umfangreiche Drush-Hilfe.

Unbedenklich ist das Kopieren der Live-Site in die Test-Site. In der umgekehrten Richtung muss man  vorsichtig sein, es werden ja alle Dateien im Verzeichnis und die Datenbank überschrieben. Im einfachsten Fall verliert man die Watchdog-, Session-  und Statistikdaten seit dem letzten Kopieren der Live- in die Test-Site. Sollten jedoch zwischenzeitlich auch Inhalte auf der Live-Site erstellt oder aktualisiet worden sein, oder wurden Kommentare eingegeben, dann gehen diese beim Kopieren der Test-Site auf die Live-Site verloren.    Möglich wäre es, diese Inhaltsdaten vor dem Kopieren mit Backup_migrate und einem angepassten Backup-Profil sichern und nach dem Kopieren wieder in die Datenbank zu importieren. Aber dass setzt detaillierte Kenntnisse der Drupal-Tabellenstruktur voraus – man ganz genau wissen, welche Datenbanktabellen gesichert und wieder hergestellt werden müssen. Ich habe das so noch nicht angewendet, bleibt also Raum für zukünftige Tests.

Update: Nach dem Kopieren der Seite müssen evtl. noch Konfigurationswerte angepasst werden. So speichert z.B. das Modul Secure Pages die Basis-URL für die http- und https-Version.

drush @live vget securepages_basepath   
securepages_basepath: "http://beispiel.de"   
securepages_basepath_ssl: "https://beispiel.de"

Auch das Modul Mobile Tools speichert URLs für Mobil- und Desktop-Version einer Website als Variablen. Solche Variablen müssen für die Test-Website angepasst werden.

drush @test vset securepages_basepath http://test.beispiel.de   
drush @test vset securepages_basepath_ssl https://test.beispiel.de

Einen Schnelltest bietet:

drush @test vget | grep beispiel.de

Man sollte sich jedoch nicht ausschließlich auf diesen Schnelltest verlassen.

Beim Entwickeln einer Drupal-Website gehören bei mir ein paar Module immer auf die Liste der unbedingt zu installierenden Verwaltungsmodule. Neben dem Admin-Modul und den Themes Tao und Rubik ist da vor allem das Backup and Migrate-Modul zu nennen. Ich installiere es auf nahezu allen Drupal-Websites, egal ob die Installation in einem shared Webhosting erfolgt oder auf meinen eigenen Servern.

Zur Funktion des Moduls: Backup and Migrate erstellt manuell oder zeitgesteuert einen Abzug (Dump) der Drupal-Datenbank in eine Datei. Man kann einzelne Datenbanktabellen komplett vom Backup ausgeklammern oder nur deren Struktur sichern. Diese Datei kann beim Backup gleich noch komprimiert werden. Ein solcher Datenbank-Dump wird bei Bedarf per Mausklick wieder in die Datenbank importiert und ersetzt dabei den vorhandenen Datenbankinhalt. Man kann mehrere Profile anlegen und so bei Bedarf verschiedene Sets von Datenbanktabellen sichern, z.B. bei manuellen Backups keine Watchdog-, Session- und Cache-Tabellen, wohl aber bei der täglichen Sicherung.
Das Modul bringt vorbildliche drush-Integration mit, so dass ein Backup oder Restore mal schnell von der Kommandozeile erledigt werden kann.

Mein aktueller Fall: Gerade übertrage ich unser Intranet-Portal von einer seit Jahren produktiven Eigenbau-Drupal-Instanz in eine OpenAtrium-Installation. Auf der bisherigen Site haben sich eine Vielzahl selbstgebauter Inhaltstypen, Ansichten und jede Menge Beiträge (Nodes) angesammelt, die möglichst auf das in OpenAtrium vorgegebene Repertoire an Inhaltstypen (Buchseiten, Blogpost, Projekte und Aufgaben) abgebildet und in die jeweils passende Gruppe einsortiert werden sollen. Details zu der Migration werde ich später beschreiben, aber es sind verschiedene Strategien am Start und es hat viel mit Probieren und Testen zu tun.

Bei dieser Aufgabe unterstützt mich Backup and Migrate bestens, in dem ich nach jeder erfolgreichen Übertragung von Inhalten oder Konfigurations”orgien” ein manuelles Backup erstelle, ähnlich einem Wiederherstellungspunkt bei Windows, oder, um ein besseres Beispiel zu finden: einem git-commit ;)
Schlägt beim nächsten Arbeitsgang ein Node-Import fehl oder haben die importierten Inhalte noch nicht die erwartete Güte, dann wird das letzte Backup mit einem Klick wieder eingespielt, und ein die Importstrategie kann verbessert nochmals angewendet werden.

Backup and Migrate bietet auch die Möglichkeit, zeitgesteuert und automatisch beim Cron-Lauf eine Datenbanksicherung durchzuführen. Üblicherweise stelle ich als Zeitplan eine Datensicherung alle 24 Stunden ein und erhalte mir die drei letzten Backups. So kann man leicht auf aus Drupal heraus auf einen früheren Stand zurückgreifen, ohne die Datenbankdatei aus dem Serverbackup wieder herstellen zu müssen.

Es ist natürlich auch möglich, mal schnell Veränderungen an der Drupal-Site mittels Vergleich von zwei Datenbank-Dumps herauszufinden:

cd files/backup_migrate
vim -d scheduled/bak-2010-11-12T00-21-25.mysql \\   
      manual/bak-2010-11-12T21-22-41.mysql

Das Modul ersetzt jedoch keine Datensicherung auf Serverebene, sondern bildet eine sinnvolle Ergänzung dazu. Auch werden mit dem Modul keine Dateien gesichert, der Schnappschuss ist also nicht vollständig. Mit Git hat man jedoch einen guten Helfer für gleichzeitige Snapshots des Dateisystems.

So hat mir Backup and Migrate schon manche Stunde Arbeitszeit gespart.

Und noch eine Anmerkung: Bei größeren Projekten und komplexeren Setups mit Development-, Staging- und Live Sites ist man mit Git, Drush make und Features natürlich besser aufgestellt. Aber auch das ist eine andere Geschichte, die ich für später aufhebe. ;)

Dank drush war ziemlich schnell eine meiner Websites geklont und dann habe ich versucht, mit “drush site-upgrade” diese Website auf Drupal 7 zu aktualisieren. Randbedingung: Die Site darf keine CCK-Module enthalten, da die Migration von CCK zu D7-Fields nicht vom Drupal-Core verantwortet wird und CCK meines Wissens noch keinen Migrationspfad anbietet.

Beim Upgrade lädt drush die verfügbaren D7-Versionen alle Module herunter bzw. meldet, welche Module nicht aktualisiert werden können. Zum Schluss bin ich jedoch auf zwei Fehler beim Initialisieren der D7-Installation und beim Klonen der Datenbank gestoßen. 3 Issues gemeldet, einen Patch abgeliefert, Schluss für heute.

Nun geht es ab zum Bus, der soll diesmal nicht ohne mich fahren. Es war eine tolle (Fast)Woche. Jede menge Inspiration für die nächste zeit. Und Vorfreude auf den nächsten Code sprint (wo ich mich um die Übersetzung und SimpleTests kümmern will – hoffentlich hat Drupal dann schon ein Git-Repo).

Tschüß Kopenhagen, war schön!

Was mir noch fehlte, war die Einbindung in drush, um “mal eben” einen DB-Schnappschuss erstellen zu können. So hatte ich mir für die erste Januarwoche vorgenommen, ein kleines Modul zu bauen, welches genau dies implementiert. Und siehe da: Die 2.x-Linie des Moduls bringt die Funktionalität schon mit!

bam backup           # Backup the site's database with Backup and Migrate.
bam restore          # Restore the site's database with Backup and Migrate.
bam destinations     # Get a list of available destinations.
bam sources          # Get a list of available sources.
bam profiles         # Get a list of available settings profiles.
bam backups          # Get a list of previously created backup files.

Ein kurzes

drush dl backup_migrate
drush updatedb

erledigte das Update von der bisherigen Version 1.2 auf 2.2. Danke Ronan!