Auf dem Server setzte ich Debian Linux als Betriebssystem und duplicity als Backup-Software ein. Dieses Backuptool verschlüsselt die Backups mit GPG-Schlüssel, somit braucht man eine intakte (vorzugsweise unixartige) Systemumgebung und den GPG-Schlüssel, mit dem das Backuparchiv erstellt wurde. Meine Herausforderung war nun, die auf einem Linux-Server erstellten Backup-Archive auf dem Mac wieder auszupacken, um die wiederhergestellten Git-Repositories auf einen anderen Server zu verschieben.

Duplicity bekommt man mit Homebrew in Sekundenstelle installiert, ebenso das Skript duply, ein Wrapper für duplicity, der die Konfiguration und Bedienung extrem vereinfacht.

sudo brew install duplicity

sudo brew install duply

nun braucht man die duply-Konfiguration, lag auf dem Server unter /etc/duplyund kann auf dem Mac in ~/.duplyabgelegt werden. Ich nenne das Backup-Set mal "gitrepo", das Backup-Set liegt in ~/backups. Es muss noch in der Datei ~/.duply/gitrepo/conf der Pfad zu den Backup-Ordnern geändert werden, z.B.

TARGET='file:///var/backups/duply/gitrepo/'

in

TARGET='file:///Users/drue/backups/gitrepo/'

Nun kann man die Wiederherstellung starten, der GPG-Schlüssel-ID und das Passwort steht in der Duply-Konfiguration. In diesem Beispiel soll das Backup ins Verszeichnis ~/gitrepo wiederhergestellt werden.

$ duply gitrepo restore ~/gitrepo

Start duply v1.5.4, time is 2012-02-03 16:11:46.

Using profile '/Users/drue/.duply/gitrepo'.

Using installed duplicity version 0.6.17, gpg 1.4.11 (Home: ~/.gnupg).

Autoset first GPG_KEY entry '09ABCDEF' as signing key.

Test - Encrypt to 09ABCDEF & Sign with 09ABCDEF (OK)

Test - Decrypt (OK)

Test - Compare (OK)

Cleanup - Delete '/tmp/duply.17084.1328281906_*'(OK)



--- Start running command RESTORE at 16:11:47.000 ---

Max open files of 120 is too low, should be >= 1024.

Use 'ulimit -n 1024' or higher to correct.



16:11:47.000 Task 'RESTORE' failed with exit code '37'.

OK, es ist eben kein Server. Duplicity beklagt, dass die Höchstgrenze gleichzeitig geöffneter Dateien mit 120 zu gering ist. Das lässt sich mit

ulimit -n 1024

auf jedem unixartigen System hochsetzen. Ein alternatives mac-spezifisches Kommando ist

launchctl limit 1024 10240

Nun ein weiterer Versuch:

drue@ain:~$ duply gitrepo restore ~/gitrepo

Start duply v1.5.4, time is 2012-02-03 16:10:32.

Using profile '/Users/drue/.duply/gitrepo'.

Using installed duplicity version 0.6.17, gpg 1.4.11 (Home: ~/.gnupg).

Autoset first GPG_KEY entry '09ABCDEF' as signing key.

Test - Encrypt to 09ABCDEF & Sign with 09ABCDEF (OK)

Test - Decrypt (OK)

Test - Compare (OK)

Cleanup - Delete '/tmp/duply.16860.1328281836_*'(OK)



--- Start running command RESTORE at 16:10:36.000 ---

Synchronizing remote metadata to local cache...

Copying duplicity-full-signatures.20110910T232302Z.sigtar.gpg to local cache.

Traceback (most recent call last):

  File "/usr/local/bin/duplicity", line 1377, in <module>

    with_tempdir(main)

  File "/usr/local/bin/duplicity", line 1370, in with_tempdir

    fn()

  File "/usr/local/bin/duplicity", line 1246, in main

    sync_archive(decrypt)

  File "/usr/local/bin/duplicity", line 1059, in sync_archive

    copy_to_local(fn)

  File "/usr/local/bin/duplicity", line 1008, in copy_to_local

    tdp.move(globals.archive_dir.append(loc_name))

  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 617, in move

    self.copy(new_path)

  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 443, in copy

    self.copy_attribs(other)

  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 448, in copy_attribs

    util.maybe_ignore_errors(lambda: os.chown(other.name, self.stat.st_uid, self.stat.st_gid))

  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/util.py", line 65, in maybe_ignore_errors

    return fn()

  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 448, in <lambda>

    util.maybe_ignore_errors(lambda: os.chown(other.name, self.stat.st_uid, self.stat.st_gid))

OSError: [Errno 1] Operation not permitted: '/Users/drue/.cache/duplicity/duply_gitrepo/duplicity-full-signatures.20110910T232302Z.sigtar.gz'

An dieser Stelle habe ich aufgehört, mein Glück mit Duply zu veruchen, da es abbricht, weil es ein paar erweiterte Dateiattribute nicht setzen kann. Beim nächsten Versuch habe ich mir das eigentliche Duplicity-Kommando gesucht und im Ubuntu-Hilfe-Wiki gefunden. Wenn man das GPG-Passwort nicht in der Umgebungsvariable PASSPHRASE hinterlegt, wird man bei der Ausführung des Kommandos duplicity restore ... erfragt.

export PASSPHRASE=SomeLongGeneratedHardToCrackKey

duplicity restore file:///Users/drue/duply/gitrepo/ gitrepo

unset PASSPHRASE

Nun kommt noch immer diese Fehlermeldungen:

...

Error '[Errno 1] Operation not permitted: 'gitrepo/repositories/image_server.git/objects/45'' processing .

...

Das Kommando aber läuft durch. Ich hatte meine Git-Repositories zurück und habe sie mittlerweile funktionierend und an neuer Location wieder am Start.

Epilog

Den Beitrag habe ich geschrieben, um alle im Netz verstreut liegenden Infos zusammenzutragen und den Suchmaschinen zu den Fehlermeldungen die passenden Beschreibungen zu liefern. ;)
Ein wichtige Lehre ist wiedermal: Hast Du alle Daten zur Hand, die Du zur Wiederherstellung brauchst. In diesem Fall waren das der GPG-Schlüssel, das zugehörige Kennwort und natürlich ein möglichst aktuelles und konsistentes Backup.

Hätte die Wiederherstellung auf dem Mac nicht funktioniert, wäre der nächste Programmpunkt, eine Jiffybox mit Debian Linux einzurichten, die Backups auf diesen vServer zu transferieren und mit nahezu identischer Systemumgebung ausgepackt. Hätte aber ein paar Stunden länger gedauert.

Ich hatte Gelegenheit zu einem Selbsttest, als ich kürzlich mein Macbook wegen eines Hardwaredefekts - nur für mich überraschend? - im Apple Store zurück lassen musste. Ich reaktivierte mein Linux-Notebook und legte los. Wichtig war mir, schnell wieder eine funktionierende Arbeitsumgebung einzurichten.

• Mein iPod und iPad wurden regelmäßig mit dem Mac synchronisiert. Adressbuch, Kalender und so waren also auf aktuellem Stand und weiterhin gut nutzbar. Damit habe ich mich am Linux-Desktop nicht beschäfftigt.
• Dank Mails auf dem IMAP-Server hatte ich mit Thunderbird schnell wieder Zugriff auf die Mails. Auf dessen Adressbuch konnte ich verzichten: wenn ich eine Adresse brauchte, habe ich sie schnell in einer früheren Mail im Gesendet-Ordner gefunden.
• Für die Arbeit brauche ich Firefox, Netbeans, OpenOffice und ein gutes Terminal - alles da.
• Aktuelle Projekt- und Konfigurationsdaten habe ich mir aus dem wöchentlichen Mac-Backup von der Backup-Festplatte (USB) kopiert. Das klappt mit Linux im Lesezugriff auf Apples HFS-Dateisystem sehr gut.
• Auf Fotos in der Aperture-Bibliothek kann man ganz gut zugreifen, wenn man weiß, wonach man sucht, da die Aperture-Metadaten fehlen. Aber der Import der Bilder aus dem Backup nach Digikam macht sie nutzbar.
• Meine Dokumente liegen auf dem Mac in einem verschlüsselten Sparsebundle. An die kam ich ohne Mac OS nicht heran. Zum Glück hat mir ein Freund dann mal seinen Mac geliehen und ich habe mir die notwendigen Dateien aus dem USB-Backup kopiert. (Dafür habe ich die Software auf seinem Mac gleich mal aktualisiert. Win-Win :)

Insgesamt ein ganz gutes Ergebnis. Nur für das Sparsebunde werde ich mir noch was überlegen müssen. Ich will mal probieren, ob ein Truecrypt-Container sich ähnlich reibungslos ins Mac OS integrieren lässt und so eine plattformübergreifende Alternative darstellt.

Man kann von meinem Anwendungsfall leicht abstrahieren und eine andere Betriebssystem-Kombi für die Notlösung wählen. Mit einem Windows-PC als Interimslösung wäre der temporäre Rechnerverlust sicher schmerzlicher spürbar gewesen. Wichtig ist jedoch, einen Plan zu haben.

PS: Allerdings wollte ich mich die ganze Zeit nicht mehr mit der Qualität und dem Bedienkomfort der Anwendungen auf dem Linux-Desktop anfreunden. Das Jahr des Linux-Desktops liegt wohl noch in weiter Zukunft.

Anmerkung: Den Beitrag hatte ich im Frühjahr geschrieben, aber aus den Augen verloren. Als nun mein Kollege Thomas drei Wochen ohne Mac auskommen musste, kam er mir wieder in den Sinn.

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. ;)

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!

I just found a website called the Internet Archive and it’s WayBackMachine. You can enter a website URL and it brings you a table of the dates it has snapshots of this website. So I entered my former homepage URL and was in the unexpected situation that I could see the page as it looked like in 2002 (look at the screenshot below).

I don’t have the code base of these pages (plain HTML, written using Vim and organized with CVS as the footer message reveals) and I didn’t miss it either. I think forgeting and (ony limited) rememberance is a high value of our brain. And if I don’t like to remember my old website and dropped these bytes from my computers hard disk, it might have happened because it was time doing so. Why do other people think these bytes need to be kept for future generations?

Hey guys: Take the money you spend for maintaining this archive (you claim to have currently  85 billion pages in your archive) and invest it in useful things! You need a clue? Donate some hundret one laptop per child notebooks to some schools in asia or africa.

• It is not possible to store the individual backup files next to each other. All backups are stored in one single file (don’t think about the consequences of a single read error when opening the file) or one backup replaces the previous backup with the same file name.
• It’s not possible to define any measures to manage the space on the backup media an remove older backups depending on their age or the used space on the backup media.
• It is not  possible to define a sophisticated backup policy: only full OR incremental OR differential backups are possible.
• ...

So I decided to install Perl (because Perl is my scripting language of choice) on the server and write a small script that does exactly that. It renames the backup file (originally named backup.bkf) and appends the timestamp to the file name. It also observes the free space on the backup media and deletes the oldest backups so that a certain amount of disk space is assured for the next backup run. To keep the script simple the path to the backup folder, the available disk space and the required free disk space (depending on the size of one backup file). I run this script as a "planned task" one hour before the ntbackup task will run. Its working without problems on a server for about 6 months.