Restore-Script für Duplicity

Meine ownCloud läuft inzwischen auf dem Raspberry Pi im Wohnzimmer. Die wichtigen Daten darauf werden verschlüsselt auf einem externen FTP-Server gesichert. Hierfür wird Duplicity verwendet, ein leistungsfähiges Backup-Tool, das allerdings auf der Kommandozeile etwas unhandlich zu bedienen ist.

Für das tägliche automatische Backup verwende ich dieses Backup-Script für Duplicity von Hetzner. Aber was, wenn der Ernstfall eintritt und verlorene Daten wieder hergestellt werden müssen? Dafür habe ich mir das folgende Restore-Script geschrieben. Es müssen dieselben Zugangsdaten eingetragen werden, die in dem oben verlinkten Backup-Script verwendet wurden.

#!/bin/bash
#
# Simple script for restoring Duplicity backups.
#
# Usage: restore.sh FNAME TARGET [TIME]
# FNAME: fully qualified name of the file or folder to restore
# TARGET: fully qualified name of the restored file or folder,
#         can be the original name and location or another
# TIME: Specify the time from which to restore files, e.g. 3D for 3 days
#       See duplicity manpage chapter "Time Formats" for details
#
# Example to restore /etc from 2 days ago in /home/user/etc_restored:
# restore.sh /etc /home/user/etc_restored 2D 

# Set protocol (use scp for sftp and ftp for FTP, see manpage for more)
BPROTO=scp

# set user and hostname of backup account
BUSER='u10000'
BHOST='u10000.your-backup.de'

# Setting the password for the Backup account that the
# backup files will be restored from.
# for sftp a public key can be used.
BPASSWORD='yourpass'

# Setting the pass phrase to encrypt the backup files. Will use symmetrical keys in this case.
PASSPHRASE='yoursecretgpgpassphrase'
export PASSPHRASE

##############################

if [ $BPASSWORD ]; then
 BAC="$BPROTO://$BUSER:$BPASSWORD@$BHOST"
else
 BAC="$BPROTO://$BUSER@$BHOST"
fi

FNAME=$1
TARGET=$2
TIME=$3

if [ $TIME ]; then
  TIME="-t $TIME"
fi

if [ $FNAME != ${FNAME#/*/} ]; then
  CMD="duplicity $TIME --file-to-restore ${FNAME#/*/} $BAC${FNAME%%/${FNAME#/*/}} $TARGET"
else
  CMD="duplicity $TIME $BAC$FNAME $TARGET"
fi

eval  $CMD

# Check the manpage for all available options for Duplicity.
# Unsetting the confidential variables
unset CMD
unset PASSPHRASE
unset FTP_PASSWORD

exit 0

Das Script kann man z.B. unter /usr/local/sbin/restore.sh speichern und mit folgendem Befehl ausführbar machen:

sudo chmod 750 /usr/local/sbin/restore.sh

Benutzung:

sudo restore.sh FNAME TARGET [TIME]

FNAME: Name der Datei oder des Verzeichnis, das aus dem Backup wiederhergestellt werden soll.
TARGET: Name, unter dem die Daten wiederhergestellt werden sollen. Das kann auch ein abweichender Name oder Speicherort sein.
TIME: Optional, ohne Angabe wird das letzte Backup wiederhergestellt. Für Details siehe die Duplicity Manpage im Kapitel „Time Formats“.

Jetzt wollen wir z.B. das versehentlich gelöschte Verzeichnis /home/username/Maildir an seiner ursprünglichen Stelle wiederherstellen.

sudo restore.sh /home/username/Maildir /home/username/Maildir

Im folgenden Beispiel wird der Stand von vor fünf Tagen wiederhergestellt, außerdem werden die Daten im abweichenden Verzeichnis /home/username/Maildir_restored gespeichert:

sudo restore.sh /home/username/Maildir /home/username/Maildir_restored 5D

Auch einzelne Dateien können aus dem Backup zurückgeholt werden. Im folgenden Beispiel wollen wir nachsehen, wie die Datei /home/username/Dokumente/Artikel.txt vor zwei Wochen ausgesehen hat, ohne den aktuellen Stand zu verlieren:

sudo restore.sh /home/username/Dokumente/Artikel.txt /home/username/Dokumente/Artikel_alt.txt 2W

Duplicity überschreibt beim Wiederherstellen bestehende Dateien nicht. Auch sonst ist es eine gute Idee, die Daten erst mal an einer anderen Stelle wiederherzustellen. Nach einer Kontrolle, ob man wirklich die gewünschte Version aus dem Backup geholt hat, kann man die Daten dann an die ursprüngliche Stelle verschieben.

Veröffentlicht unter Server | Hinterlasse einen Kommentar

ownCloud auf Strato shared Hosting Paketen

Mit ownCloud kann man seine private Cloud auf dem eigenen Server einrichten – wichtig für alle, die ihre Daten nicht Google, Apple oder anderen Datenkraken anvertrauen möchten. Das funktioniert schon mit preiswerten Hosting-Paketen, allerdings musste ich bei Strato einige Hindernisse umschiffen. Die beschriebenen Probleme traten mit ownCloud 5.0 auf Strato PowerWeb Basic auf.

Installation

Am einfachsten geht es mit dem Web Installer. Der bricht jedoch mit folgender Fehlermeldung ab:

„ownCloud is NOT installed
download of ownCloud source file failed.
SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failedSSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed“

Da stimmt was mit dem Zertifikat nicht, wir schalten daher die Verifikation ab. Dazu ändern wir Zeile 139 in  setup-owncloud.php  von

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, TRUE);

nach

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);

und die Installation läuft durch.

Aber es lassen sich keine Dateien hochladen

Der Upload-Button im Browser ist ohne Funktion und zeigt die seltsame Meldung „Upload max. B“. Das liegt daran, daß der freie Speicherplatz auf dem Server falsch ermittelt wird. Wir ändern daher in Zeile 221  lib/files/storage/local.php  von

return @disk_free_space($this->datadir.$path);

nach

return disk_free_space('/');

und es sollten sich Dateien hochladen lassen.

SSL verwenden

Leider ist die Verbindung noch ungesichert, und auf dem Webspace lassen sich keine eigenen SSL-Zertifikate verwenden. Strato bietet zum Glück einen SSL-Proxy an, und die gesicherte Verbindung zur eigenen Cloud sieht dann so aus:

https://ssl-id.de/dein-cloud-server

Leider funktioniert das noch nicht ganz, beim Einloggen wird wieder zu einer ungesicherten Verbindung zurückgewechselt. Um das zu verhindern, fügen wir in  config/config.php  folgende Zeilen hinzu:

'overwritehost' => 'ssl-id.de',
'overwriteprotocol' => 'https',

Serverseitige Verschlüsselung

Die wird für Version 5 komlett neu geschrieben und ist leider noch nicht fertiggestellt. Wer den Content unbedingt verschlüsselt speichern möchte, muß zur Zeit noch eine ältere Version verwenden. Update 27.10.2013: Die Verschlüsselungs-App ist inzwischen fertig. Aber Achtung: Nur neu hochgeladene Dateien werden verschlüsselt. Das erfolgt dateiweise, wobei der Dateiname auf dem Server nicht verschlüsselt wird und die Dateigröße sich nur wenig verändert.

Ergebnis

Nach dieser Bastelei funktioniert nun die sichere Synchronisation zwischen Desktop Client, Webinterface, mobiler App und verschiedenen Anwendungen mit webDAV Support.

iOS App

Die ownCloud eigene iOS App synchronisert nicht automatisch mit dem Server. Man muß dazu die Dateiliste nach unten ziehen und wieder loslassen (muß man erst mal finden).

Update installieren (Nachtrag 13.07.2013)

Auch das läuft nicht so reibungslos wie man es sich wünscht. Wir laden uns zuerst die ZIP-Datei mit der neuen Version herunter und entpacken sie lokal. Der Patch in  lib/files/storage/local.php muß wie oben beschrieben wiederholt werden. Dann werden alle entpackten Dateien per FTP auf den Server kopiert. Beim nächsten Aufruf der eigenen ownCloud-Seite wird der Updatevorgang automatisch gestartet. Leider bleibt das System danach im im Wartungsmodus hängen und meldet nur noch „ownCloud is in maintenance mode“. Um den zu beenden, müssen wir auf dem Server in config/config.php manuell folgende Zeile löschen:

  'maintenance' => true,
Veröffentlicht unter Server | 51 Kommentare