obnam.1.de.in

.\" Copyright 2010-2015  Lars Wirzenius
.\" Copyright 2015  Jan Niggemann
.\"
.\" This program is free software: you can redistribute it and/or modify
.\" it under the terms of the GNU General Public License as published by
.\" the Free Software Foundation, either version 3 of the License, or
.\" (at your option) any later version.
.\"
.\" This program is distributed in the hope that it will be useful,
.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
.\" GNU General Public License for more details.
.\"
.\" You should have received a copy of the GNU General Public License
.\" along with this program.  If not, see <http://www.gnu.org/licenses/>.
.TH OBNAM 1
.SH BEZEICHNUNG
obnam \- Backups anlegen, wiederherstellen bzw. verändern
.SH ÜBERSICHT
.B obnam
erzeugt und verwaltet Backups, die entweder lokal oder remote über
sftp abgelegt werden können. Mit obnam brauchen Sie nicht zwischen
Full-Backup und inkrementellem Backup unterscheiden: Jedes Backup
verhält sich wie ein vollständiger
.I Snapshot,
ist in Wirklichkeit aber inkrementell. Es werden nur Daten gesichert,
die seit dem letzen Backup geändert wurden. Wenn ein Teil der Daten
bereits in einem anderen File gesichert wurde, wird dieser Teil erneut
benutzt. Dies wird
.I Deduplizierung
genannt.
.SH BESCHREIBUNG
Der Ort an dem die Daten gesichert werden wird als "backup repository"
bezeichnet. Ein Repository kann zum Beispiel ein Verzeichnis auf einem
sftp-Server oder auf einer USB-Festplatte sein. Ein einzelnes
Repository kann Backups von mehreren Clients enthalten, so können die
Daten mehrerer Clients für die Deduplizierung benutzt werden. Trotzdem
kann ein Client nur "seine" Daten einsehen, also z.B.
Wiederherstellen.
.PP
Das erste Argument für
.B obnam
sollte eine
.I Funktion
sein, gefolgt von optionalen Parametern.
Hier die Liste der Funktionen:
.IP \(bu
.B backup
erzeugt ein neues Backup.
Beim ersten Aufruf wird ein vollständiges Backup angelegt, bei
nachfolgenden Aufrufen ein inkrementelles.
.IP \(bu
.B restore
Das Gegenteil von "backup".
Es extrahiert gesicherte Daten aus dem Repository in ein Verzeichnis.
Sie können eine vollständige Generation oder einzelne Dateien
wiederherstellen.
.IP \(bu
.B clients
zeigt eine Liste der Clients, die im Repository gesichert sind.
.IP \(bu
.B generations
zeigt eine Liste aller Generationen (Backups) eines Clients und einige
Metadaten der Generationen.
.IP \(bu
.B genids
zeigt eine Liste aller Generations-IDs eines Clients.
Keine anderen Daten werden angezeigt. Sinnvoll für Scripte.
.IP \(bu
.B ls
zeigt den Inhalt einer Generation an, ähnlich wie
.BR "ls \-lAR" .
.IP \(bu
.B kdirstat
zeigt den Inhalt einer Generation an. Die Ausgabe erfolgt in einem
.BR "kdirstat"
kompatiblen Format, das dann benutzt werden kann um den Inhalt eines
Backups zu visualisieren.
.IP \(bu
.B verify
vergleicht Backup-Daten mit Echtdaten und stellt sicher, das sie
identisch sind. Sinnvollerweise wird verify sofort nach einem
Backup-Lauf aufgerufen um zu prüfen das auch alles geklappt hat.
.B verify
kann jederzeit aufgerufen werden, allerdings schlägt die Überprüfung
fehl wenn die Echtdaten verändert sind, auch wenn das Backup
fehlerfrei ist.
.IP \(bu
.B forget
entfernt nicht mehr benötigte Generationen und gibt wenn möglich
Speicherplatz frei. Wenn eine Generation gelöscht wurde, können deren
Daten nicht mehr zurückgesichert werden. Sie können die Generation(en)
entweder beim Aufruf mitgeben, oder die Option
.B \-\-keep
verwenden um anzugeben, was behalten werden soll (alles andere wird entfernt).
.IP \(bu
.B fsck
überprüft und repariert (optional) ein Repository. Es verifiziert das
sämtliche Clients, Generationen, Verzeichnisse, Dateien und
Dateiinhalte konsistent im Repository gespeichert sind. Der Aufruf
kann sehr lange dauern.
.IP \(bu
.B force\-lock
entfernt die Sperre eines Clients im Repository. Sie sollten dies nur
tun, wenn Sie sicher sind das nichts anderes auf die Daten des Clients
im Repository zugreift. Die Sperre kann zum Beispiel hängen bleiben,
wenn obnam während einer Operation die Netzwerkverbindung zum
Repository verliert.
.IP \(bu
.B client\-keys
zeigt eine Liste der Verschlüsselungs-Schlüssel jedes Clients.
.IP \(bu
.B list\-keys
zeigt eine Liste aller Schlüssel die auf das Repository zugreifen
können und auf welche Top-Level Verzeichnisse jeder Schlüssel Zugriff
hat. Manche Top-Level Verzeichnisse sind von mehreren Clients
"geshared", andere sind auf einen Client beschränkt.
.IP \(bu
.B list\-toplevels
ähnlich wie
.BR list\-keys ,
zeigt aber Top-Level Verzeichnisse und welche Schlüssel Zugriff haben.
.IP \(bu
.B add\-key
fügt einen Schlüssel zum Repository hinzu. Standardmäßig wird der
Schlüssel nur zu gemeinsam genutzen Top-Level Verzeichnissen
hinzugefügt, er kann aber auch zu einzelnen Clients hinzugefügt werden
(Client-Namen als Argument angeben). Der Schlüssel wird durch die
.B \-\-keyid
spezifiziert. Wer auch immer Zugriff zum privaten Schlüssel der
zugehörigen Key-ID hat, kann auf das Repository zugreifen. (gemeinsam
genutze Top-Level Verzeichnisse plus angegebene Clients).
.IP \(bu
.B remove\-key
entfernt einen Schlüssel aus den gemeinsam genutzen Top-Level
Verzeichnissen und allen angegebenen Clients.
.IP \(bu
.B nagios\-last\-backup\-age
gibt einen Wert ungleich Null zurück wenn das letzte Backup eine
konfigurierbare Anzahl Tage als ist. Dies erlaubt die Einbindung in
Nagios, Schwellenwerte werden über
.B \-\-warn-age
und
.B \-\-critical-age
eingestellt.
.IP \(bu
.B diff
vergleicht zwei Generationen und gibt eine Liste der Unterschiede aus,
das erste Zeichen zeigt den Unterschied an:
.br
 + Datei neu hinzugekommen
.br
 - Datei entfernt
.br
 * Datei geändert
.br
Wenn nur eine Genearion angegeben wurde, dann wird diese Generation
mit dem direkten Vorgänger verglichen. Werden zwei Generationen
angegeben, werden die Unterschiede dieser beiden Generationen
angezeigt.
.IP \(bu
.B mount
mounted das Repository als FUSE filesystem (read-only). Jede
Generation wird als eigenes Unterverzeichnis dargestellt, das nach der
Generations-ID benannt ist. Sie können so mit den normalen Werkzeuge
auf die gesicherten Daten zugreifen, zum Beispiel GUI File Manager
oder auch Kommandozeilen-Werkzeuge wie
.BR ls (1),
.BR diff (1),
und
.BR cp (1).
Sie können keine Daten hinzufügen, aber ganz einfach Daten wieder
herstellen.
.IP
Sie benötigen die FUSE utilities und die entsprechende Berechtigung um
FUSE zu benutzen, damit dies funktioniert. Details sind je
Betriebssystem unterschiedlich, in Debian benötigen Sie das Paket
.I fuse
und müssen Sich zur Gruppe
.I fuse
hinzufügen (evtl. müssen Sie Sich neu anmelden).
.SS "Backups anlegen"
Wenn Sie ein Backup machen, speichert
.B obnam
die Daten in das Repository. Die Daten werden in Teile (engl. chunk)
aufgeteilt, wenn ein chunk schon im Repository enthalten ist, wird er
nicht noch einmal gespeichert.
So kann
.B obnam
leicht mit nur teilweise geänderten oder umbenannten Dateien umgehen.
Außerdem wird so vermieden das mehrere Clients die selben Daten
sichern. Wenn zum Beispiel jeder im Büro eine Kopie des
Verkaufsprospektes gespeichert hat, werden die Daten im Repository
trotzdem nur einmal abgelegt.
.PP
Jedes Backup ist eine
.IR Generation .
Zusätzlich legt
.B obnam
während eines Backup-Laufs 
.I checkpoints
an, die sich genau wie normale Generationen verhalten, aber noch nicht
die gesamten Echtdaten enthalten. Sollte ein Backup-Lauf unterbrochen
werden, kann der folgende Lauf beim letzten Checkpoint weiter machen
und muss nicht komplett von vorn beginnen.
.PP
Sollte ein Backup-Lauf ein Verzeichnis entfernen, so behalten die
älteren Genrationen die Daten trotzdem: Neue Generationen haben keinen
Einfluß auf die älteren Generationen. Wurde das Verzeichnis
unabsichtlich entfernt, kann es wieder hinzugefügt werden und beim
nächsten Backup-Lauf werden die bereits im Repository befindlichen
Daten wiederverwendet. Es werden dann lediglich Metadaten (Dateinamen,
Berechtigungen, ...) erneut gesichert.
.SS "Backups überprüfen"
Was nützt ein Backup-System, dem Sie nicht vertrauen können? Wie
können Sie etwas vertrauen, das Sie nicht testen können? Der Befehl
.B "obnam verify"
prüft das die Daten im Repository und die Echtdaten übereinstimmen. Es
holt eine oder mehrere Dateien aus dem Repository und vergleicht sie
mit den Echtdaten. Im Wesentlichen ist dies das gleiche wie ein
Restore und ein Vergleich mittels
.BR cmp (1),
aber es ist einfacher.
.PP
Standardmäßig werden alle Daten verglichen, Sie können aber auch
einzelte Dateien als Parameter mitgeben. Dabei müssen Sie den
vollständigen Pfad zu den Dateien angeben, keinen relativen Pfad.
.PP
Die Ausgabe zeigt Dateien, bei denen es Unterschiede zwischen
Echtdaten und Repository gibt. Wenn Sie sämtliche Dateien überprüfen
ist es sehr wahtscheinlich, das einige Dateien geändert sind, ohne das
dies ein Problem darstellt. Bitte beachten Sie das Pfadangaben absolut
sein müssen und nicht relativ zum Backup root. Sie müssen mindestens
ein Backup root auf der Kommandozeie older mittels
.B \-\-root
angeben, damit obnam das Filesystem findet, falls es remote ist.
.SS "URL syntax"
Jedes Mal wenn obnam eine URL akzeptiert kann das entweder ein lokaler
Pfadname oder eine
.B sftp
URL sein.
Eine sftp URL hat die folgende Form:
.IP
\fBsftp://\fR[\fIuser\fR@]\fIdomain\fR[:\fIport\fR]\fB/path
.PP
wobei
.I domain
ein normaler Internet domain name eines Servers ist,
.I user
der Benutzername auf dem Server,
.I port
eine (optionale) Portnummer,
und
.I path
Wie in 
.BR bzr (1),
aber im Gegensatz zum sftp URL standard, ist der Pfadname absolut,
außer wenn er mit
.B /~/
beginnt. In diesem Fall ist er relativ zum home directory des
Benutzers auf dem Server.
.PP
Im Abschnitt BEISPIELE finden Sie einige Beispiele für sftp URLs.
.PP
Sie können
.B sftp
URLs sowohl für das Repository als auch die Echtdaten (backup root)
benutzen.
Bitte beachten Sie, das sich
.B sftp
durch Beschränkungen des Protokolls und seiner Implementierung in der
.B paramiko
Bibliothek weniger gut eignet, um darübe rauf Echtdaten zuzugreifen.
So werden zum Beispiel Hardlinks nicht optimal verarbeitet. Beim
Zugriff auf Echtdaten sollte die URL daher nicht mit
.B /~/
enden und es sollte in diesem Fall ein Punkt am Ende stehen.
.SS "Mit Generationen arbeiten"
Wenn Sie nicht mit der neuesten Generation arbeiten, müssen Sie mittels
.B \-\-generation
eine Generation spezifizieren.
Sie können entweder das Wort
.IR latest ,
angeben (neueste Generation, default),
oder einge Nummer. Benutzen Sie die Funktion
.B generations
um zu sehen, welche Generationen zur Verfügung stehen und welche
Nummern (IDs) sie haben.
.SS "Vorgaben zum behalten und entfernen von Generationen"
Die Funktion
.B forget
kann optional Vorgaben enthalten, auf deren Basis Generationen
automatisch gelöscht oder behalten werden. Diese Vorgaben (engl.
policy) werden mit
.BR \-\-keep =\fIPOLICY
gesetzt.
.PP
.I POLICY
ist dabei eine komma-getrennte Liste von Regeln.
Jede Regel besteht aus einer Anzahl und einem Zeitraum.
Die Zeiträume sind:
.BR h ,
.BR d ,
.BR w ,
.BR m ,
und
.BR y ,
für Stunde (engl. hour), Tag (engl. day), Woche (engl. week), Monath
(engl. month), und Jahr (engl. year).
.PP
Die Vorgabe 
.I 30d
bedeutet: Behalte das neueste Backup (Generation) für jeden Tag an dem
eines erstellt wurde und behalte die letzten 30 dieser Backups
(Generationen). Jede Generation die zu einer Vorgabe passt wird
behalten, alle anderen dazwischen werden entfernt. Backups die älter
als das älteste zu behaltende Backup sind, werden ebenfalls entfernt.
.PP
Stellen Sie Sich zum Beispiel vor, dass Backups jede volle Stunde
gemacht werden, also um 00:00, 01:00, 02:00, und so weiter, bis 23:00.
Wenn die
.B forget
Dunktion um 23:15 mit der oben erwähnten Policy aufgerufen wird,
werden die Backups von 23:00 jedes Tags behalten und die anderen
werden entfernt. Es werden auch alle Backups entfernt, die älter als
30 Tage sind.
.PP
Wenn Backups jeden zweiten Tag um 12:00 erstellt werden, dann behält
.B forget
mit der oben angegebenen Policy ebenfalls die letzten 30 Backups, die
sich in diesem Fall allerdings auf einen Zeitraum von 60 Tagen
erstrecken.
.PP
Beachten Sie das obnam nur die Zeitstempel im Backup repository prüft
und sich um die aktuelle Systemzeit nicht kümmert. Das bedeutet auch,
das wenn Sie aufhören Backups zu machen, die bereits bestehenden nicht
automatisch irgendwann gelöscht werden. Im Prinzip benutzt obnam für
den forget-Lauf die Uhrzeit direkt nach dem neuesten Backup.
.PP
Die Vorgaben könnne in beliebiger Reihenfolge gegeben werden, sie
werden aufsteigend nach Zeitraum geordnet, bevor sie angewendet weden.
(Zwei Angaben für den gleichen Zeitraum führen zu einem Fehler). Ein
Backup (= eine Generation) wird behalten, wenn eine Vorgabe darauf
passt.
.PP
Ein anderen Beispiel. Stellen Sie Sich wieder stündliche Backups wie
oben vor, aber eine Vorgabe wie
.IR 30d,52w .
Diese Vorgabe wird 30x die letzten Backups des Tages behalten
.I und
52x das neueste Wochen-Backup. Weil die stündlichen Backups täglich
von der 30d-Vorgabe gelöscht werden, noch bevor die 52w Regel sie
erfassen kann, werden die letzten 30 Tages-Backups von je 23:00
behalten, und das 23:00 Uhr Backup eines jeden Sonntags für 52 Wochen.
.PP
Geben Sie stattdessen eine Vorgabe wie
.IR 72h,30d,52w ,
behält
.B obnam
die letzten 72 stündlichen Backups, die letzten Backups jedes
Kalendertages der letzten 30 Tage, und das letzte Backup jeder
Kalenderwoche für 52 Wochen. Bei nur einem Backup am Tag behält
.B obnam
dann also effektiv die Backups der letzen 72 Tage...
.PP
Klingt verwirrend? Überlegen Sie mal, wie verwirrt der Entwickler beim
Schreiben des Codes wohl war...
.PP
Wenn keine Vorgabe gemacht wird, behält
.B forget
alles.
.PP
Eine typische Vorgabe wäre 
.IR 72h,7d,5w,12m ,
was soviel bedeudet wie: Behalte
die letzten 72 stündlichen Backups,
die letzten 7 täglichen Backups,
die letzten 5 wöchentlichen Backups,
die letzten 12 monatlichen Backups.
Werden Backups systematisch stündlich erstellt,
bedeutet das: Es werden
die stündlichen Backups der letzten 3 Tage,
die täglichen Backups für eine Woche,
die wöchentlichen Backups für einen Monat
und die monatlichen Backups für ein Jahr behalten.
.PP
Die Vorgaben sind in der Tat etwas kompleiziert, führen Sie
.B forget
daher bitte mit
.B \-\-pretend
aus um sicherzustellen, das die richtigen Backups entfernt würden.
.\"
.SS "Verschlüsselung benutzen"
.B obnam
kann sämtliche Daten im Repository verschlüsseln.
Es nutzt dabei
.BR gpg (1)
um die Verschlüsselung durchzuführen.
Sie benötigen ein Schlüsselpaar, das Sie mittels
.B "gpg --gen-key"
erzeugen können, oder ein bestehendes Schlüsselpaar.
Dann müssen Sie
.B obnam
mittels
.B \-\-encrypt\-with
konfigurieren, den Schlüssel zu benutzen.
.SS "Konfigurationsdateien"
.B obnam
sucht Konfigurationsdateien an mehreren Stellen, im Abschnitt DATEIEN
finden Sie eine Auflistung. Alle diese Konfigurationsdateien werden
gemeinsam als eine große Konfigurationsdatei behandelt, so als wären
alle concatenated.
.PP
Konfigurationsdateien sind im INI format, es wird ausschließlich der
Abschnitt
.I [config]
benutzt (alle anderen Abschnitte werden ignoriert).
.PP
Die Langnamen der Optionen werden als Schlüssel für Variablen in den
Konfigurationsdateien verwendet. Jede Option, die auf der
Kommandozeile gesetzt werden kann, kann auch in einer
Konfigurationsdatei im Abschnitt
.I [config]
stehen.
.PP
So können zum Beispiel die Optionen des folgenden Befehls
.sp 1
.RS
obnam --repository=/backup --exclude='\.wav$' backup
.RE
.sp 1
durch die folgende Konfigurationsdatei ersetzt werden:
.sp 1
.nf
.RS
[config]
repository: /backup
exclude: \.wav$
.RE
.fi
.sp 1
(Sie können sowohl
.I foo=value
als auch
.I foo: value
verwenden.)
.PP
Das einzig ungewöhnliche in den Konfigurationsdateien ist, wie
Optionen die mehrmals auftreten können behandelt werden. Alle Werte
werden durch Komma getrennt in eine einzige logische Zeile geschrieben
(optional auch durch Leerzeichen). Ein Beispiel:
.sp 1
.RS
.nf
[config]
exclude = foo, bar, \\.mp3$
.fi
.RE
.sp 1
Im Bespiel gibt es drei Werte für die
.B exclude
Option, alle Dateien welche
.I foo
oder
.I bar
irgendwo im fully qualified pathname enthalten oder Dateien die mit
einem Punkt und
.I mp3
enden (exclusions sind reguläre Ausdrücke).
.PP
Eine lange logische Zeile kann in mehrere physische aufgespalten
werden, indem mit Whitespace begonnen wird und die Folgezeilen dann
genau so eingerückt sind:
.sp 1
.RS
.nf
[config]
exclude = foo,
    bar,
    \\.mp3$
.fi
.RE
.sp 1
Das Beispiel enthält, wie das Beispiel vorher, 3 Ausschluss-Muster.
.SS "Locking mit mehreren Clients"
.B obnam
unterstützt gemeinsam benutzte Repositores, die Clients können
Dateiinhalte (chunks) gemeinsam nutzen. Wenn Client A also eine große
datei sichert, und Client B die gleiche Datei hat, muss B sie nicht
erneut ins Repository hochladen. Damit dies funktioniert, benutzen die
Clients einen einfachen Locking-Mechanismus. Es kann immer nur ein
einziger Client gemeinsam genutzte Daten im Repository verändern.
Sperren (locks) verhindern keinen lesenden Zugriff, Sie können also
gleichzeitig ein Restore durchführen, während ein anderer Client ein
Backup macht.
.PP
Manchmal kann eine Leseoperation zur Gleichen Zeit auf die
Datenstrukturen zugreifen, die gerade neu geschrieben werden. Dies
kann zu einem Absturz führen, der allerdings weder Daten korrumpiert,
noch die Wiederherstellung verfälscht. Eventuell müssen Sie nach einem
Absturz die lesende Operation wiederholen.
.\"---------------------------------------------------------------------
.SH OPTIONEN
.SS "Optionswerte"
Der Wert
.I SIZE
gibt eine Größe in Byte an, wobei optionale Suffixe folgendes
bedeuten: Kilobyte (k), Kibibyte (Ki), Megabyte (M), Mebibyte (Mi),
Gigabyte (G), Gibibyte (Gi), Terabyte (T), Tibibyte (Ti). Die Suffixe
sind nicht case-sensitive.
.\" ------------------------------------------------------------------
.SH "EXIT STATUS"
Falls keine Fehler passierten, endet
.B obnam
mit einem Status von 0. Ansonsten ist der Wert ungleich Null.
.SH UMGEBUNGSVARIABLEN
.B obnam
gibt die Umgebungsvariablen seines Elternprozesses ohne Änderung
weiter. Es hört nicht auf ungewöhnliche Umgebungsvariablen, beachtet
aber die üblichen wenn externe Programme ausgeführt werden, z.B.
temporäre Dateien erzugt werden usw.
.SH FILES
.I /etc/obnam.conf
.br
.I /etc/obnam/*.conf
.br
.I ~/.obnam.conf
.br
.I ~/.config/obnam/*.conf
.RS
Konfigurationsdateien für
.BR obnam .
Es ist kein Fehler, wenn eine der Dateien oder sogar alle fehlen.
.RE
.SH BEISPIELE
Ihr Home-Verzeichnis auf einen Server sichern:
.IP
.nf
obnam backup \-\-repository sftp://your.server/~/backups $HOME
.PP
Das neueste Backup vom Server wieder herstellen:
.IP
.nf
obnam restore \-\-repository sftp://your.server/~/backups \\
\-\-to /var/tmp/my.home.dir
.PP
Nur eine Datei wiederherstellen (bzw. ein Verzeichnis):
.IP
.nf
obnam restore \-\-repository sftp://your.server/~/backups \\
\-\-to /var/tmp/my.home.dir $HOME/myfile.txt
.fi
.PP
Alternativ dazu können Sie auch das Repository mittels FUSE mounten.
(Dazu benötigen Sie die
.B \-\-to
):
.IP
.nf
mkdir my-repo
obnam mount \-\-repository sftp://your.server/~/backups \\
\-\-to my-repo
cp my-repo/latest/$HOME/myfile.txt
fusermount -u my-repo
.PP
Prüfen ob das Backup funktioniert hat:
.IP
.nf
obnam verify \-\-repository sftp://your.server/~/backups \\
/path/to/file
.PP
Alte Backups löschen, das jeweils neueste Backup eines Tages behalten
(10 Jahre lang):
.IP
.nf
obnam forget \-\-repository sftp://your.server/~/backups \\
\-\-keep 3650d
.PP
Das Repository überprüfen:
.IP
.nf
obnam fsck \-\-repository sftp://your.server/~/backups
.fi
.PP
Mittels FUSE die gesicherten Dateien betrachten:
.IP
.nf
obnam mount \-\-to my-fuse
ls -lh my-fuse
fusermount -u my-fuse
.fi
.SH "SIEHE AUCH"
.B obnam
wird mit Handbüchern in den Formaten HTML und PDF geliefert.
Schauen Sie in 
.I /usr/share/doc/obnam
wenn Sie obnam systemweit installiert haben, oder in das
Unterverzeichnis
.I
manual
im Verzeichnis mit dem Quellcode.
.TP
.BR cliapp (5)
.SH ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Jan Niggemann
<jn@hz6.de> erstellt.
.PP
Dieses Werk steht unter der GNU General Public License Version 3
oder,je nach Vorliebe, einer beliebigen neueren Version.
.PP
Es wird KEINE HAFTUNG übernommen.
.PP
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken 
Sie bitte eine E-Mail an <obnam-dev@obnam.org>.