Stopp-Seite schließen und weiter - Close and continue
ftplicity: inkrementelle Backups sicher ablegen
ACHTUNG: Die in diesem Artikel besprochenen Versionen sowohl von ftplicity als auch duplicity sind bereits veraltet. Die grundsätzlichen Erklärungen sind zwar weiterhin valid, aber die Syntax oder Konfigurationsparameter könnten sich geändert haben. Bitte verwendet den Such-Tag “duplicity” bzw. den Such-Tag “ftplicity” und die Kommentare, um aktuelle Informationen zu finden.
Nachdem ich durch einen Beitrag von Matthias wieder mal erinnert wurde, dass nicht Jeder Backups macht bzw. sie aktuell hält, dachte ich, dass ich mal kurz einen Teil meiner Backuplösung vorstelle:
Vorteile
In einem (schon älterem) Artikel der c’t (13/2006) wurde ein Tool vorgestellt mit dem man eine einfache und sichere Backup-Strategie für z.B. Root-Server fahren kann. Das Tool heißt ftplicity und ist im Prinzip nur ein Wrapper für das umfangreichere duplicity. Wie der Name schon sagt, kann möchte ftplicity nur via FTP kommunizieren, denn dies ist laut c’t (und auch meiner Erfahrung nach) der häufigste und simpelste Weg einen Backupspace zu erreichen.
Nun beseitigt ftplicity bzw. das dahinterliegende duplicity gleich mehrere Probleme, die bei dem “plain old Dir-to-FTP-sync” enstehen:
- Übertragungsqualität: FTP tendiert bei längeren durchgehenden Übertragungen (= eine große Datei) zu Fehleranfälligkeit und der ganze Upload muss noch einmal begonnen werden oder (was viel schlimmer ist) die Backupdatei ist zerstört/ fehlerhaft und lässt sich im Ernstfall nicht mehr richtig wiederherstellen.
Lösung: kleine Dateien übertragen durch Erstellung von Volumes
- Vertraulichkeit: Wer einen zweiten Server mit guter Anbindung hat braucht sich um diesen Punkt nicht zu sorgen, aber alle anderen, die entweder etwas Platz bei einem Bekannten in Anspruch nehmen oder von Ihrem Provider einen gewissen Platz an FTP-Space zur Verfügung gestellt bekommen (z.B. Strato, Hetzner) müssen sich schon fragen, ob denn der jeweilige Serveradmin nicht nachts mal aus Interesse sich durch das Mailbackup wühlt.
Lösung: Verschlüsselung der Daten mittels GPG
- Authentizität: Das oben genannte Problem wirft ebenfalls die Frage auf, wie weit man den so gesicherten Daten noch vertrauen kann, wenn “Unbekannte” auf die Daten Zugriff hatten. Nichts wäre wohl schlimmer, als dass man sich mit dem Restore auch gleich eine passwd-Datei mit neuen SSH-Usern runterzieht (nette Idee, btw).
Lösung: Die Signatur der Daten mittels GPG, welche auch beim Restore geprüft werden.
- Datenvolumen: Je mehr Daten man gesichert hat, desto leichter findet ein Restore statt. Allerdings nimmt damit auch das Übertragungsvolumen zu, was erstens mehr Backupzeit kostet und zweitens in den meisten Hosterverträgen auch begrenzt ist.
Lösung: Inkrementelle Backups (nur geänderte Daten) unter Nutzung der erprobten rsync-Bibliothek
Diese Probleme werden also von der hier vorgestellten Lösung bereits vermieden. Aber – richtig eingerichtet – kann es noch mehr:
Weitere Vorteile
- Einzelrestore: Wer kennt das nicht: Schnell mal die Config vom Mailserver bearbeitet und statt die alte Zeile auszukommentieren löscht man sie… und siehe da, rien ne va plus! Der Mailserver startet nicht mehr und man kann sich partout nicht mehr an die besagt Zeile erinnern. Wohl dem, der ein Backup von den Configdateien hat und noch wohler dem, der nicht das ganze Backup wiederherstellen muss, um die Einzeldatei zu erhalten.
Lösung: ftplicity besitzt einen Befehl, mit dem man Einzeldateien oder -ordner an einen beliebigen Ort wiederherstellen kann
- Versionierung: Manchmal wäre es schön, wenn man eine Datei nicht nur in dem Zustand des nächtlichen Backups erhielte, sondern sich auch mal die Config ansehen könnte, wie sie vor zwei Wochen war.
Lösung: Ein Argument des oben erwähnten Befehls ermöglicht es, ein Datum oder einen Zeitraum für die wiederherzustellende Datei anzugeben.
So, als ich diese Punkte damals alle las, war für mich klar: Das will ich haben! Wenn es DIR jetzt auch so geht, dann lies jetzt weiter, denn ein kleines Howto folgt. Es basiert auf Debian (zuerst Sarge, nun Etch), aber sollte wohl auch auf anderen (Linux-) Systemen laufen, da duplicity in Python geschrieben ist und ftplicity nur ein Shellscript ist.
Installation
So, wie fangen wir an? Wir ziehen uns das duplicity-Paket mittels apt oder aptitude.
apt-get install duplicity |
Wer z.B. noch kein gnupg (= GPG) installiert hat, wird sich freuen, dass die Abhängigkeiten vernünftig definiert sind und es somit gleich mit geladen wird.
Alternativ kann man sich auch das tgz von der Projektseite herunterziehen. Ich bevorzuge aber aus Sicherheitsgründen die Debian-Pakete.
Dann laden wir uns das File mit ftplicity von dem heise-Server.
wget ftp://ftp.heise.de/pub/ct/listings/0613-216.tar.gz |
Auspacken…
tar -xzf 0613-216.tar.gz |
…und in das Verzeichnis wechseln, …
cd ftplicity-1.1.1/ |
… und einfach mal die Datei ausführen:
./ftplicity |
Diese Ausgabe sollte erscheinen:
Offenbar benutzen Sie ftplicity zum ersten Mal. Eine vorlaeufige
Konfigurationsdatei wurde unter /root/.ftplicity/conf erstellt.
Sie muessen dort die Daten des verwendeten GPG-Schluessels sowie
die Zugangsdaten fuer den FTP-Server eintragen, bevor Sie mit dem
Backup fortfahren koennen.
WICHTIG:
Sichern Sie das komplette Konfigurationsverzeichnis nach dem
ersten erfolgreichen Backup unbedingt auf einen vertrauenswuerdi-
gen externen Rechner und schuetzen Sie es vor unbefugtem Zugriff.Konfiguration
So, das ist zwar schön, aber nicht wirklich sinnvoll. Als guter Admin möchte man seine Configdateien ja alle unter /etc wissen. Also machen wir ein wenig Kosmetik:
Wir verändern den Ort, wo ftplicity nach der config sucht:
edi ftplicity |
Zur leichteren Trennung der verschiedenen Dateien, hänge ich auch noch Endungen an.
CONFDIR="/etc/ftplicity" CONF="$CONFDIR/main.conf" PRE="$CONFDIR/pre.sh" POST="$CONFDIR/post.sh" EXCLUDE="$CONFDIR/exclude.conf" KEYFILE="$CONFDIR/gpg.key" |
F10 – Speichern und beenden.
Dann das besagte Config-Dir erstellen:
mkdir /etc/ftplicity |
Damit ftplicity im Pfad zu finden ist kopieren wir es nach /usr/sbin – für mich ist dies der richtige Ort, denn nur der root soll dieses Script mit der Konfiguration ausführen dürfen.
cp ftplicity /usr/sbin/ |
und damit wir u.U. das Skript schnell bearbeiten können, sollte dies nochmal nötig sein, erstellen wir noch einen Link ins Confdir (optional):
ln -s /usr/sbin/ftplicity /etc/ftplicity/ftplicity |
Danach entweder einfach nochmal
ftplicity |
aufrufen oder die Musterconfig aus dem ersten Aufruf an die richtige Stelle kopieren.
cp ~/.ftplicity/conf /etc/ftplicity/main.conf |
Bevor wir nun die Config bearbeiten, benötigen wir zunächst einen GPG-Key, der zum Signieren und Verschlüsseln dient.
gpg --gen-key |
Die Voreinstellungen sind alle sinnvoll und können mit <Enter> bestätigt werden, aber den Namen, Mailadresse und Kommentar sollte man so sinnvoll ausfüllen, dass man den Key in der GPG-Keyliste dann auch wiederfindet.
Das Passwort sollte natürlich Sicherheitsansprüchen genügen (Klein- und Großbuchstaben + Sonderzeichen + Zahlen).
Es kann sein ist sehr wahrscheinlich, dass bei Key-Erstellung folgendes kommt:
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 282 more bytes)
Wie auch immer das genau funktioniert, nutzt GPG die Systemvorgänge als Zufallsinput. Also mach z.B. folgendes in einer zweiten Shell:
while /bin/true; do cat /var/log/syslog > ~/temp.txt; sleep 1; done; |
Dies erzeugt eine Kopie des Syslogs (= große Datei) in deinem Homeverzeichnis und das zwar endlos, solange du es nicht via Ctrl+C abbrichst bzw. die Sitzung schließt. Damit erzeugst Du genügend Festplattenaktivität. Du kannst natürlich auch andere Dinge tun oder einfach warten – je nach Systemaktivität könnte dies aber eine Weile dauern.
Wie auch immer Du es erreichst, es erscheint dann:
gpg: key 1B6B8FAF marked as ultimately trusted
public and secret key created and signed.gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
pub 1024D/1B6B8FAF 2007-08-17
Key fingerprint = 2B2E DA54 4E2C 08B4 677D 4EC9 1AC5 3DE5 1B6B 8FAF
uid Stevie (Backup-GPG-Key) <admin@domain.tld>
sub 2048g/C4BCAD3E 2007-08-17
wobei uns nur diese Zeile interessiert,
pub 1024D/1B6B8FAF 2007-08-17
denn 1B6B8FAF wäre in diesem Fall die Key-ID, die wir in die ftplicity-Config eintragen müssen. Das merken wir uns also schon mal. Dann können wir jetzt die Config-Datei von ftplicity bearbeiten.
edi /etc/ftplicity/main.conf |
Meine Datei sieht so aus:
# Daten fuer GPG-Schluessel GPG_KEY=<em>KEYID</em> GPG_PW='_MEINPW_' # Zugangsdaten fuer FTP-Server (URL-Format) # subdir ist natürlich optional, aber strengstens empfohlen! ZIEL='ftp://username@ftphost.tld/subdir/' ZIEL_PW='_FTPPASSWORT_' # Basisverzeichnis fuers Backup QUELLE='/' # aeltester Wiederherstellungszeitpunkt # Linux-übliche Abkürzungen, ich habe vorerst 6 Monate eingestellt, # da ich noch genügend freien Platz habe # - je nach Speicherplatz und Backuphäufigkeit zu entscheiden HOECHSTALTER=6M # Ausfuehrlichkeit der Bildschirmausgaben (9 fuer Fehlersuche) # WARNUNG: "9" erstellt Logs/Ausgaben in der Größenordnung von 200MB (je nach Dateianzahl) VERBOSITY=3 # Verzeichnis fuer temporaere Dateien. Beim Restore muss dort # mindestens Patz fuer die groesste Datei im Backup sein TEMP_DIR=/tmp |
So, eigentlich wären wir nun fertig. ABER eben nur eigentlich. Bei der Erstellung des Backups würde duplicity auf einige Probleme stoßen, somit sind einige Pfade vom Backup auszuschließen in der exclude.conf:
edi /etc/ftplicity/exclude.conf |
+ /backups/mysql/latest /backups/** /var/run/** /var/tmp/** /tmp/** /dev/** /sys/** /proc/** /floppy/** /cdrom/** /var/lib/mysql/** |
Der Selektor “**” steht für alle Dateien und Unterverzeichnisse in diesem Ordner. Der Selektor “+” vor dem Ordner gibt an, dass es explizit gesichert werden soll, auch wenn es eigentlich in einem Exclude-Dir liegt (siehe 1. & 2. Zeile). Wie man sieht, schließe ich die MYSQL-Dateien aus. Während der Server läuft, kann man die Dateien auch nicht sichern. Entweder man beendet den Mysql-Server während des Backups oder man dumpt die DBs. Das Script zum Dumpen der MYSQL-Tabellen habe ich hier kurz vorgestellt.
Wer noch andere vorbereitende Schritte zur Sicherung vornehmen möchte, wie z.B. das o.g. MySQL-Dump-Script oder das Beenden des MySQL-Servers, kann diese in der pre.sh einstellen. Nachbereitende Schritte, z.B. Start von Mysql, kann ist der post.sh erfolgen. (Beide Dateien müssen erst erstellt werden, sofern sie benötigt werden.)
Absichern
Zur Sicherheit sichern wir nun noch das gesamte Confdir, damit uns niemand das Key-PW auslesen kann:
chown -R root:root /etc/ftplicity chmod -R o-rwx /etc/ftplicity |
So, fertig. Nun ist alles konfiguriert und bereit zum Test. Auf manchen FTP-Servern hat duplicity Probleme zu starten, wenn der Ordner leer ist (wie es beim ersten Mal der Fall sein wird). Wo das der Fall ist, genügt es, eine leere Datei in dem Verzeichnis zu platzieren.
Test
Nun wird es ernst. Die Verwendungshinweise erhält man nun, in dem man einfach
ftplicity |
aufruft und es wäre sinnlos alles zu wiederholen. Nur ein paar Hinweise:
Beim “fetch” einzelner Dateien darf man keinen führenden Slash und muss eine Zieldatei angeben:
ftplicity fetch etc/passwd /root/restoretest/passwd now |
Lädt aus dem Backup die letzte Version der Datei passwd, die aus /etc gesichert wurde und speichert sie nach /root/restoretest/passwd.
Bevor man sich nun darauf verlässt, dass alles funktioniert, sollte man mittels
ftplicity full |
ein Vollbackup machen und es mittels
ftplicity restore /root/restoretest/ |
zurückspielen und untersuchen. Wenn alles geklappt hat, kann man sich beruhigt auf die Schulter klopfen.
Cron
So, nun ist alles bereit für den Regelbetrieb. Damit man von nun an keine Kopfschmerzen mehr mit dem Backup hat, richten wir noch cronjobs ein, die wöchentlich ein komplettes Backup und an den anderen Tagen eine inkrementelle Sicherung erstellen. Richtig eingerichtet sollte der Cron-Daemon die Ausgabe des Cronjobs via E-Mail an den root senden. Als root führen wir also aus:
crontab -e |
und tragen dort ein:
# FTP-Backup ... jede Nacht um 2:05 Uhr (außer Montags) 5 2 * * 2-7 /usr/sbin/ftplicity cleanup --force ; /usr/sbin/ftplicity backup # FTP-Backup ... um 1:30 Uhr jeden Montag 30 1 * * 1 /usr/sbin/ftplicity cleanup --force; /usr/sbin/ftplicity full ; /usr/sbin/ftplicity purge --force |
Zusätzlich wird so dafür gesorgt, dass vor jedem Backup das Verzeichnis von fehlerhaften Backups bereinigt wird und Montags nach dem vollständigen Backup veraltete Dateien ebenfalls gelöscht werden. (Anmerkung: Es werden nur veraltete Dateien gelöscht, wenn es eine neuere Version gibt, die innerhalb des konfigurierten Höchstalters liegt. Es gibt also immer mindestens eine Version der Datei … irgendwie sinnvoll 
)
Backup des Backups
Nach dem ersten Lauf existiert ein gpg.key im Config-Dir. Der muss unbedingt die Rechte 400 oder 600 haben und sollte an einem sicheren Platz fernab vom Server gesichert werden. Nur mit diesem Key (und dem PW) ist eine Wiederherstellung des Backups möglich, sollte der Keyring nach einem Totalabsturz nicht mehr verfügbar sein. Sicherlich kann es auch nicht schaden, die Configs zu sichern. So hat man gleich die perfekte Voraussetzung, um das ganze erneut aufzusetzen.
Das war’s, we are done. Wir sind nun sowas von auf der sicheren Seite… wow!
Fragen? Hinweise? Optimierungen? –> Bitte hinterlasse einen Kommentar!
Ich kann nur positives vermelden .. immernoch. Wir “verlieren” täglich zwischen 70 und 85 tsd Spams mit sql grey. verzögerungen...
Ich quäl mich damit seit ner Woche rum, und alles nur weil ich mich um eine Zeile verlesen habe 
Aktionen: Trackback URL Kommentarfeed
4 Trackbacks/Pingbacks
Trackback von WE ARE ROOT&hellip am 27. September 2007 um 12:06 Uhr :
duplicity-Patch für FTP mit Portangabe (0.4.4RC2)…
Da Daniel in dem HOWTO zu ftplicity nach einer Möglichkeit zur Verwendung eines anderen Ports beim Verbinden mit seinem FTP-Server gefragt hat und diese Möglichkeit bei duplicity scheinbar nicht ganz gegeben ist, habe ich mal fix einen Patch …
Trackback von WE ARE ROOT&hellip am 29. Oktober 2007 um 14:29 Uhr :
duplicity 0.4.4 und ftplicity…
duplicity ist gerade in der Version 0.4.4RC4 veröffentlicht worden und dort wurde u.a. die komplette Syntax für Befehle umgebaut.
Resultat: ftplicity geht nicht mehr.
Da dies ja kein Zustand ist, habe ich meine ftplicity-Version selbst geupda…
Pingback von Backup virtual machines with LVM snapsho&hellip am 8. Juli 2009 um 20:47 Uhr :
[...] http://www.weareroot.de/2007/08/17/ftplicity-inkrementelle-backups-sicher-ablegen/ (German) [...]
Pingback von Strategien zum sicheren Online Backup - &hellip am 25. November 2009 um 17:01 Uhr :
[...] von Duplicity ist Duply (vormals ftplicity) und eine ausführliche deutsche Anleitung findet sich hier. Alternativ sind noch zu nennen Bacula (grafische Benutzeroberfläche; ohne GnuPG; benötigt [...]
33 Kommentare
Taucha
24. August 2007
( 14:29 Uhr )
Moin.
Und wie sieht es mit der sicheren Kommunikation zum FTP Server selbst aus?
ftplicity hat ja leider keine SSL Unterstützung.
hast du da schon nen Weg gefunden? TLSWRAP bringt mich leider nicht weiter.
Taucha
stevie
24. August 2007
( 14:35 Uhr )
Hallo Taucha!
Ich habe die Kommunikation mit dem FTP-Server bewusst ignoriert, weil ich auf dem von mir genutzten Backup-Server (Strato) 1. keine SSL-Verbindung nutzen kann und 2. ich auf dem Backupserver eh nur noch verschlüsselte und damit für andere nutzlose Daten liegen habe.
Nichtsdestotrotz wäre es sicherlich für alle anderen auch interessant, wenn Du eine Möglichkeit findest und sie hier postest.
Ich werde, sobald Zeit da ist, mal in der Doku von duplicity nachsehen. Das kann ja sogar via SSH usw. kommunizieren.
So long,
Stevie
stevie
29. August 2007
( 17:46 Uhr )
NACHTRAG:
Auf serversupportforum.de gibt es einen Patch für alle, die Probleme mit unterbrochenen Backups haben. Dies ist bei mir nämlich auch andauernd passiert und seit dem Patch nicht ein einziges Mal.
Vielen Dank an “Cheef-Daniel” dafür!
Taucha
30. August 2007
( 10:08 Uhr )
Hey.
Ich habe im Hetzner Forum dazu auch schon einen beitrag eröffnet.
Aktuell wollte jmd Kontakt mit den Entwicklern von Duplicity aufnehmen und diese Erweiterung vorschlagen.
Mal schauen was bei rauskommt.
Taucha
30. August 2007
( 10:10 Uhr )
Achso,
was bringt mir mein verschlüsseltes Backup, wenn jmd meine Nutzerdaten und das Passwort für den FTP mitlesen kann?
So könnte er die Daten löschen, dann bringt mir mein sicheres Backup auch nichts mehr
Ob das nun so einfach ist, die Verbindung zu sniffen, muss jetzt nicht diskutiert werden
taucha
stevie
30. August 2007
( 11:42 Uhr )
@Taucha:
Ja, das ist der einzige Punkt, bei dem SSL dann doch Sinn macht, trotz der Backup-Form. Aber 1. bin ich mir ziemlich sicher, dass mein Strato-Backup-Server kein SSL unterstützt (warum eigentlich nicht?) und 2. kann der “Hacker” eben wirklich nur destruktiv tätig sein, denn er kann mit Daten ja nichts anfangen und kommt auch nicht auf den Quell-Server rauf.
Es ist nicht so, dass ich das Problem wegdiskutieren möchte, da aber der Server nur innerhalb des Stratonetzes erreichbar ist, ist die Problematik bei mir etwas eingegrenzt.
Natürlich würde mir das im “Ernstfall” auch nichts helfen.
PS: Sehr sinnvoller Beitrag, dies in den Original-Quellcode einfließen zu lassen. Man ist immer so darauf bedacht, sein eigenes System zum laufen zu bringen, dass man vergisst, dass Open Source auch heißt, die Ergebnisse zu teilen.
PPS: Kannst Du mir den Link von Hetzner hier auch mal posten?
stevie
30. August 2007
( 12:22 Uhr )
UPDATE:
Im CHANGELOG von duplicity für Version 0.4.3 (siehe RC9) steht, dass nun eine andere FTP-Lib verwendet wird, die auch Dinge wie retrys als Startparameter usw. unterstützt.
Bei Gelegenheit werde ich mir die neue Version mal ansehen und schauen, ob das FTP-SSL nun auch einfach in ftplicity zu portieren wäre.
Taucha
30. August 2007
( 12:47 Uhr )
aber sicher. hier ist der link (aber kommst nur in das forum, wenn du dort nen Server hast :-/ )
http://forum.hetzner.de/wbb2/thread.php?threadid=9515
Wenn die Übergabe der Accountdaten nicht in URL Form, sondern einzeln anzugeben ist, würde das ja helfen.
Mit “tslwrap” und “ncftp” mache ich das auch so. Wenn es neues im Hetzner Forum gibt, werde ich es hier mit anbringen. (Für den Fall das du nicht reinkommst)
Taucha
stevie
30. August 2007
( 13:11 Uhr )
@Taucha:
Danke für den Link, ich habe trotz Nicht-Kundenstatus bei Hetzner mich einfach mal versucht zu registrieren… mal sehen.
Was würde es denn helfen, wenn die Accountdaten nicht in der URL stehen? Ich meine bei der unverschlüsselten Übertragung könnte man das Passwort so oder so mitsniffen. Allerdings ist mir im o.g. duplicity-Changelog eine Variable “FTP_PASSWORT” (o.ä.) untergekommen. Vielleicht ist das was du suchst?!
Taucha
30. August 2007
( 13:40 Uhr )
ich poste einfach mal das, was ich im Hetzner-Forum geschrieben hatte (u.a.).
Taucha
30. August 2007
( 13:41 Uhr )
hm. mist
wollte alles in “code” setzen. Aber ich denk du wirst verstehen, was ich sagen wollte
stevie
30. August 2007
( 13:47 Uhr )
Dafür ist ja auch “blockquote” da!
Habs gefixt…
PS: Für Comments wo es kein bq gibt, musst du um den code-block noch ein pre-block setzen.
Taucha
30. August 2007
( 14:24 Uhr )
*aufschreib*
*info in Feed reinbingen*
*link zu diesem post speichern*
*drucken*
*auswendiglern*
stevie
30. August 2007
( 14:29 Uhr )
Hmmm, sind die <ironie>-tags nun nur nicht sichtbar oder wirklich nicht da?!
chris
14. September 2007
( 21:20 Uhr )
Ein Backup auf eine FAT32- oder NTFS-Partition schlägt fehl, weil duplicity die Backupdateien mit Doppelpunkten im Namen abspeichert, die in MS-Dateisystemen bekannterweise nicht erlaubt sind.
Abhilfe schafft eine Änderung des ftplicity-Scripts in den Zeilen 80/81:
Der Parameter --short-filenames macht die Dateinamen gleich zu mehreren Dateisystemen kompatibel – leider sind nicht alle so freizügig wie ext3 & Co.
Daniel
26. September 2007
( 18:05 Uhr )
Hallo,
ich wollte ftplicity auf einem neuen Server mit der neuen duplicity Version verwenden, aber diese frisst meine Portangabe mit user@server:port nicht. Kann ich diesen irgendwie evtl durch abändern des Scripts einstellen? Außerdem wäre für mich auch ein FTPoverSSL interessant, geht das evtl auch?
Danke
stevie
26. September 2007
( 19:08 Uhr )
@Daniel:
1. Was genau ist Dein Problem mit dem Port? Der Ziel-FTP läuft auf einem anderen Port? Ich habe dazu in der Doku leider nichts finden können – alle FTP-Beispiele sind ohne Hinweis auf einen Port.
2. Wie lautet Deine aktuelle Versionsnummer von duplicity? Laut changelog (link s.o.) ist bereit RC1 von 0.4.4 raus, der wohl ein krassen Fehler beim FTP-Backend löst.
3. Die SSL-Geschichte kam ja hier in den Comments ja schon auf. Ich habe noch das Debian-Paket und damit “nur” Version 0.4.2 installiert – damit soll FTP-SSL wohl ziemlich unmöglich sein. Seit 0.4.3 ist aber, wie bereits oben gesagt, eine neue FTP-Lib dabei. Genaueres kann ich derzeit aber noch nicht sagen.
Daniel
27. September 2007
( 11:03 Uhr )
Hallo stevie,
vielen Dank für Deine Antwort. Mein Problem ist folgendes. Ich habe meinen ftp-Server nicht auf Port 21 am laufen, damit dieser nicht mit Loginversuchen überschwemmt wird. Ich habe einen Server mit duplicity 0.4.2, da klappt auch alles durch angabe der Portnummer server:port. Auf einem anderen Server habe ich 0.4.4RC2 laufen. Da die neue Version aber ncftp als ftp Wrapper einsetzt, klappt die Angebe der Portnummer nicht mehr. Als Antwort kommt immer “No Route to host”. In der Syntax habe ich gelesen, dass ncftp ein “-P ‘port’” und kein “:port” erwartet, aber das kann ich unter ftplicity leider in der Form nicht angeben, da ein ‘ den Befehl vorzeitig beendet und ohne gehts auch nicht.
Kann ich dieses Problem irgendwie umgehen?
Vielen, vielen Dank
Daniel
stevie
27. September 2007
( 12:11 Uhr )
Hallo Daniel,
bitte schau oben den Trackback an, dort findest Du einen Patch.
Sobald ich Zeit habe, werde ich mich der SSL/TLS-Geschichte nochmal widmen…
HTH,
stevie
ovizii
15. März 2008
( 18:29 Uhr )
hi.
wie schon in deinem anderen thread besprochen, und angeregt, setzen wir die config diskussion hier fort.
da du in deinem script die pfade komplett geändert hast, hab ic halle meine config dateien, sprich exclude, pre post und gpg.key umkopiert und an deine namen angepasst. jetzt den ersten versuch mit ftplicity full gestartet, melde mich dann in 5h oder so
aber jetzt zum crontab. ic hhatte dmals alles nach CT anleitung eingerichtet, und deine crontabs, sehen etwas anders aus.
meine waren:
# 0 4 * * * /usr/local/bin/ftplicity backup #daily ftplicity backup to FTP_Backupspace
# 0 6 1 * * /usr/local/bin/ftplicity full && /usr/local/bin/ftplicity purge --force #monthly full backup + deleting of old records
ich hätte gerne monatlic hein full backup und täglich ne inkrementelle sicherung.
hab gesehen du hast da ein paar andere parameter mit übergeben, wie cleanup.
ist meine crontab-config so ok? bin grad extrem faul die hilfe dazu zu lesen, udn ja ich weiß was cleanup macht, aber wo sollte ich das sinnvollerweise bei meinem crontab einbauen?
ovizii
15. März 2008
( 18:39 Uhr )
so, jetzt hab ic hauch einen der zahllosen threads gefudnen in denen ich mein problem geschildert habe: http://serversupportforum.de/forum/perl-php-python-bash/9463-problem-mit-duplicity-ftplicity-3.html
scheint so als hätte damals jemand die lösung gepostet aber ich hab den thread anscheinend nicht abonniert. wäre das dort geschilderte problem geläst? oder brauche ich eventuell immer noch diesen patch?
ich meine ich werde es nach dem ersten inkrementellen backup ja auch herausfinden aber trotzdem hier mal die frage
ovizii
15. März 2008
( 18:49 Uhr )
so, leider war der erste full backup test nicht erfolgreich
/usr/local/bin# ftplicity full
NcFTP version is 3.2.0
Reading globbing filelist /etc/ftplicity/exclude.conf
Last full backup date: Thu Jan 1 01:00:00 1970
Traceback (most recent call last):
File "/usr/bin/duplicity", line 421, in ?
if __name__ == "__main__": main()
File "/usr/bin/duplicity", line 410, in main
if action == "full": full_backup(col_stats)
File "/usr/bin/duplicity", line 150, in full_backup
bytes_written = write_multivol("full", tarblock_iter, globals.backend)
File "/usr/bin/duplicity", line 83, in write_multivol
globals.gpg_profile,globals.volsize)
File "/usr/lib/python2.4/site-packages/duplicity/gpg.py", line 198, in GPGWriteFile
try: data = block_iter.next(bytes_to_go).data
File "/usr/lib/python2.4/site-packages/duplicity/diffdir.py", line 407, in next
result = self.process(self.input_iter.next(), size)
File "/usr/lib/python2.4/site-packages/duplicity/diffdir.py", line 487, in process
data, last_block = self.get_data_block(fp, size - 512)
File "/usr/lib/python2.4/site-packages/duplicity/diffdir.py", line 508, in get_data_block
buf = fp.read(read_size)
File "/usr/lib/python2.4/site-packages/duplicity/diffdir.py", line 338, in read
buf = self.infile.read(length)
IOError: [Errno 22] Invalid argument
ok, werde mir die error ausgabe mal daheim in Ruhe durchlesen, bin grad in nem cafe, schlecht für die konzentration.
Daniel
18. März 2008
( 16:19 Uhr )
Hallo,
ich wollte nochmal nachfragen, ob es mittlerweile eine Möglichkeit gibt die Daten über SSH laufen zu lassen? Ich möchte einen Server eines Kunden bei mir sichern lassen und möchte ungern, dass evtl jemand meine dyndns-Adresse umbiegt und so an die wenn auch verschlüsselten Daten kommt (Server-Authentifizierung). Wenn nicht würde mir für das Passwort ftp/ssl auch reichen.
Grüße
Daniel
stevie
18. März 2008
( 22:46 Uhr )
@all:
Es ist von einem Einzelentwickler ftplicity weiterentwickelt und auf sourceforge migriert worden. Ich werde mir dies demnächst mal ansehen und dann darüber einen Beitrag verfassen.
Erste Infos hier@sourcforge
@ovizii:
IOError: [Errno 22] Invalid argumentDas klingt schon ziemlich seltsam und hart. Ich habe dazu leider spontan auch keine Idee und würde Dich dafür in Englisch an die Mailingliste von duplicity verweisen.
@Daniel:
Sorry, ich habe bisher noch nicht die SSH-Variante in Angriff genommen. Bei einem Test ging die FTPSSL-Sache aber problemlos. In der aktuellen duplicityversion ist der FTP-Patch ja bereits drin.
ed
27. März 2008
( 14:53 Uhr )
@23_daniel
nun .. wenn das backup verschlüsselt und signiert ist musst du dir keine sorgen machen. maximal verlierst du die backup sets und die zugangsdaten zum server … somit ist dein ftp server evtl. kompromittiert (aber wenn du so misstrauisch bist, checkst du wohl auch die logs)
ansonsten halte ich backups auf eine dynamische IP, die keine Standleitung ist, generell für fragwürdig und rate dir zu einem sicheren ftp account ala strato backup.serverkompetenz.de ..
Daniel
2. April 2008
( 22:12 Uhr )
@ed:
“maximal verlierst du die backup sets”
Das ist gerade das Problem dabei. Die Daten mögen ja sicher sein, da ich aber einen Server mit sensiblen Daten sichern will ist es nicht hinnehmbar, wenn die Backups mal weg sein sollten…
Klar, die Daten werden beim nächsten Backup wieder alle übertragen, aber die history wäre damit weg. Nicht gerade professionell!
Daniel
stevie
3. April 2008
( 0:33 Uhr )
@Daniel:
Natürlich ist das Backup immer so gut wie das schwächste Glied in der Kette. Du musst also Deinem Space vertrauen können.
Hast Du schon mal drüber nachgedacht einen eigenen Dyn-Ip-DNS dafür einzurichten? Es bräuchte ja nur eine Subdomain einer deiner Domains sein. So kannst Du Dir etwas sicherer sein, dass Du unter der Zieladresse auch Deinen Server bedienst.
Nur mal so eine Idee.
ed
8. April 2008
( 18:59 Uhr )
@daniel 26
wie gesagt die schwachstelle in deiner strategie ist die dyndns zuweisung.. ergo wenn du sicherstellen kannst, dass das backup auf dem richtigen server landet, ist dein problem gelöst…
mir fällt da z.B. ein verzicht auf einen öffentl. dyndns dienst ein
.. du könntest per scripting sicherstellen dass die entsprechende IP irgendwo hinterlegt wird, wo du sie abholst ODER du nutzt kommerzielles dyndns (vielleicht mit verschlüsseltem update) da kenne ich aber keinen anbieter
wie auch immer … zusätzlich kannst und solltest du versuchen sftp zu nutzen und die authentifizierung per key organisieren … der hijacker kann relativ unmöglich deinen key besitzen.
soviel dazu .. ed
Daniel
9. April 2008
( 10:43 Uhr )
Hi ed,
die Idee mit sftp reicht ja vollkommen aus, damit hab ich ja alles, was ich immer wollte. 1. Klappt nur bei meinem Server, 2. Verschlüsselt auch noch doppelt.
Das Problem wird nur evtl sein sftp mit ftplicity anzusprechen. Ich hab es mal in einer älteren Version probiert, dort war jedoch nur ftp möglich.
Danke
Daniel
Daniel
15. April 2008
( 17:18 Uhr )
Hallo Ihr,
jetzt melde ich mich mal wieder zu Wort. Seit einem Update von ftplicity funktioniert zwar das Backup noch, aber sonst bricht fast alles mit folgender Meldung ab. Gibt es ein HowTo für die neue Version, wo man sich auch über neuerungen einlesen kann??
# ftplicity backup purge –force
awk: line 2: function gensub never defined
expr: missing operand
Try `expr –help’ for more information.
awk: line 2: function gensub never defined
/usr/sbin/ftplicity: line 219: [: -eq: unary operator expected
/usr/sbin/ftplicity: line 221: [: too many arguments
Using installed duplicity version (OK).
Command line error: Too many arguments
See the duplicity manual page for instructions
Danke
Daniel
Manuel
5. Mai 2008
( 11:44 Uhr )
habe hier genau dasselbe Problem wie Daniel mit demselben Output.
awk: line 2: function gensub never defined
expr: missing operand
Try `expr –help’ for more information.
awk: line 2: function gensub never defined
/usr/local/bin/ftplicity: line 230: [: -eq: unary operator expected
/usr/local/bin/ftplicity: line 232: [: too many arguments
Using installed duplicity version 0.4.10 (OK).
Manuel
5. Mai 2008
( 11:50 Uhr )
Daniel,
apt-get install gawk
hat bei mir geholfen.
Daniel
30. September 2008
( 1:33 Uhr )
Hallo,
ich kann Eure Probleme mit FTP und SSL nicht ganz nachvollziehen. Natürlich sollte auch die FTP-Verbindung nach Möglichkeit verschlüsselt sein, auch wenn die Daten selber schon verschlüsselt sind. Was nützt es mir, wenn mein FTP-VErzeichnis geleert ist und mir genau dann die Festplatte wegfliegt…
Ich mache das hier mit tlswrap von http://tlswrap.sunsite.dk/, das wurde auch schon einmal kurz angesprochen. Dem tlswrap übermittelt man im Usernamen die Informationen über den eigentlichen Usernamen und den eigentlichen FTP-Server, leider wird dazu standardmässig das “@” als Trenner benutzt. Gibt man das nun so in die conf-Datei ein, will duplicity das gar nicht haben, soweit ganz richtig.
tlswrap muss dagegen z.B. mit
tlswrap -t “#_:%+”
gestartet werden, das sorgt dafür, dass jetzt der “_” als Trennungszeichen dient. In der conf-Datei steht dann entsprechend:
TARGET=’ftp://username_ftpserver@localhost:7000/subdir/
Und damit ist die FTP-Übertragung verschlüsselt.
Als neues Problem ist hier mit dem Duplicity aus Debian-Backports und dem ftplicity von Sourceforge noch aufgetreten, dass die Dateien zwingend in einem Unterverzeichnis auf dem FTP-Server erwartet werden. Will man die duplicity-Dateien direkt in das Home des FTP-Users werfen, gibt es die seltsamsten Fehlermeldungen.
Schreibe einen Kommentar