SuSE Backup aufs Webspace

Lieber Besucher, herzlich willkommen bei: Linux Forum Linux-Web.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Chaoshh

Schüler

Beiträge: 102

Beruf: angehender Linuxer

01.07.2010, 13:14

Ich habe jetzt hier ein Problem. Ich habe ein NAS Laufwerk angeschafft, dies hängt am Netz und lässt sich erreichen. Per Windows kann ich auch Daten darauf kopieren.

Netzwerk 192.168.20.0/24
IP Router 192.168.20.1
IP Server 192.168.20.100
IP NAS 192.168.20.120

In der "conf" Datei habe ich zunächst die Lokale Sicherung im Netz versucht - FTP hochladen klappt ja.

	Quellcode
1	TARGET='file://solus44@192.168.20.120/test_backup'

Auf dem NAS ist der Ordner "test_backup" erstellt und die Zugangsrechte für den Benutzer "solus44". Mit Windows klappt das auch. Filesystem ist xfs.

Wenn ich ftplicity jetzt so starte, dann meldet er zwar den Vollzug, aber kein Daten wurden auf NAS geschrieben ?! Ist meine Befehlszeile für "TARGET" richtig?

Zum Seitenanfang

Chaoshh

Schüler

Beiträge: 102

Beruf: angehender Linuxer

01.07.2010, 18:47

Ich kann sehen, daß die "Link" Diode am NAS Laufwerk aufleuchtet, wenn ich ftplicity ausführe. Aber es wird nichts kopiert. Ich habe auch in den vorhandenen "public" Ordner versucht zu speichern, anderen User genommen usw. Das alles klappt einfach nicht.

Wenn ich mit Windows, mit explorer oder mit z.B. Total Commander die Dateien kopiere, dann klappt das ohne Probleme.

Also muss der Fehler in ftplicity bzw. duplicity sein - ich habeb auch mit "nfs://" versucht, aber er meint es wäre ungültig - so steht es auch in der conf Datei.

So sieht die Ausgabe eines Testlaufs aus:

Quellcode

solus44: # /usr/local/bin/ftplicity full
Reading globbing filelist /root/.ftplicity/exclude
Local and Remote metadata are synchronized, no sync needed.
Last full backup left a partial set, restarting.
Last full backup date: Thu Jul  1 18:22:30 2010
--------------[ Backup Statistics ]--------------
StartTime 1278002639.21 (Thu Jul  1 18:23:59 2010)
EndTime 1278002939.77 (Thu Jul  1 18:28:59 2010)
ElapsedTime 300.55 (5 minutes)
SourceFiles 516
SourceFileSize 938397805 (895 MB)
NewFiles 516
NewFileSize 938397805 (895 MB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 516
RawDeltaSize 938217581 (895 MB)
TotalDestinationSizeChange 780182770 (744 MB)
Errors 0
-------------------------------------------------

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Chaoshh« (01.07.2010, 18:58)

Zum Seitenanfang

Chaoshh

Schüler

Beiträge: 102

Beruf: angehender Linuxer

02.07.2010, 16:21

Hey Leute. Das hier wird immer verrückter.

Ich kann die HDD Leuchte blinken sehen am NAS, die zeigt Festplattenzugriff an. Dann habe ich noch folgendes versucht:

- das Script mit einem Benutzer ausgeführt, welcher auch auf dem NAS erstellt ist.
- diesen Benutzer auch natürlich in die conf Datein aufgenommen - natürlich mit passwort

- In der conf Datei habe ich schon statt "ftp" auch "file" (und auch in ftplicity selbst) eingesetzt

Das script starte ich so:

	Quellcode
1	solus44:~> /usr/local/bin/ftplicity full

@ linuxer
Kann es sein, dass du noch weiterreichende Veränderungen gemacht hattest bevor es bei dir lokal funktionierte?

Ich brauche wohl zunächst eine gute, solide Alternative für FTPlicity für den LAN Einsatz. Für Empfehlungen wäre ich dankbar.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Chaoshh« (02.07.2010, 16:22)

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

02.07.2010, 16:34

ich habe keine ahnung, was die angabe "file://....blah blah blah " bedeuten soll, soetwas gibt es nicht. kontaktiere dein nas per ftp und gut, das ding nutzt ncftp und sucht das backupmedium über ftp, denn dafür wurde es geschrieben.

wenn es einen fehler gibt, zeigt ftplicity das an, wenn du einen ftp-pfad angibst de nicht existiert, von dem ftp-user aber rechtemässig erstellt werden darf, dann tut ftplicity das. wenn die rechte das nicht zulassen, versucht ftplicity es zwar, hat aber keinen erfolg.

ich benutze ftplicity schon mehrere jahre und es funktioniert hervorragend, egal ob local oder extern.

übrigens ist deine aktion mit dem zulassen von duplicity6.xx keine gute idee, da es dadurch zu problemen kommen kann.

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Zum Seitenanfang

Chaoshh

Schüler

Beiträge: 102

Beruf: angehender Linuxer

02.07.2010, 18:08

Ok, ich habe jetzt was ganz "verrücktes" versucht - nicht wirklich, aber das Ergebnis ist verrückt.

Offenbar wird noch irgendwo auf dem NAS ein verstecktes Verzeichnis erstellt, welches auf keine Art und Weise gesehen wird wenn ich das NAS mit einem Commandertool bzw. mit Windows browse.

Ich habe mich jetzt nämlich mit scftp zu dem NAS verbunden und siehe da: es gibt das erwünschte Verzeichnis und lauter ftplicity Dateien.

Wenn ich aber mit z.B. Total Commander unter Windows auf das NAS zugreife, dann sehe ich folgende Verzeichnisse:

Drucker und Faxgeräte
admin
test_backup
public

Das "test_backup" ist aber offenbar nicht das selbe wie bei dem FTP erreichbaren. Dieses hier habe ich mit der NAS Software angelegt und für den Benutzer "solus44" freigegeben.

Wie kommt das denn? Kannst du dir darauf einen Rheim machen wie sowas möglich ist? Es gibt allen Anschein nach nur eine Partition auf dem NAS.

:keineahnung:

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

02.07.2010, 22:23

das das backup an dieser stelle liegt, liegt an deiner einstellung für "TARGET" im conf-file.
das du unter ftp, windows-lanman-dienst und eventuell ssh immer etwas anderes siehst ist ganz normal, da die netzwerkdienste von linux das dateisystem immer auf unterschiedliche art mapen, je nach konfiguration.

das das verzeichnis testbackup an der stelle auftaucht ist weder verrückt noch eigenartig, sondern genau so hast du es in der conf geschrieben. wenn du mit dem totalcommander dein nas kontaktierst, dann landest du in der ftp-root des entsprechenden users (eventuell chroot-umgebung) und du hast ftplicity angewiesen genau dort ein unterverzeichnis testbackup anzulegen und die dateien dort abzulegen.

was du unter windows als verzeichnisdienst siehst, hat mit ftp nichts zu tun, sondern wird durch samba (lanman/NT-server-Simulation) erzeugt und da kann die verzeichnisstruktur aus einem ganz anderen blickwinkel dargestellt sein.

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »linuxerr« (03.07.2010, 08:58)

Zum Seitenanfang

Chaoshh

Schüler

Beiträge: 102

Beruf: angehender Linuxer

04.07.2010, 11:29

Habe jetzt einen Testlauf gestartet. Eine Dateimenge von ca. 64 GB wurde mit

	Quellcode
1	solus44 : ~# /usr/local/bin/ftplicity full

gesichert. Es hatte ewig gedauert, etwa. 1 1/2 Tage. Danach wollte ich das Backup nochmal restaurieren. Leider gab es am Ende eine Fehlermeldung:

Quellcode

solus44 : ~# /usr/local/bin/ftplicity full
CONF=/root/.ftplicity/conf
Schluessel  nicht gefunden, versuche Import aus /root/.ftplicity/gpgkey.
gpg: Schlüssel 7A5ECD54: "SuSE Package Signing Key <build@suse.de>" nicht geändert
gpg: Schlüssel 6C804ACA: "SuSE Package Signing Key <build@suse.de>" nicht geändert
gpg: Schlüssel 3E4AF8AD: "Solus44 (test) <meine@email.de>" nicht geändert
gpg: Schlüssel 2FF8F5A6: "Solus44 (test) <meine@email.de>" nicht geändert
gpg: Schlüssel 9E8AD1AD: Ist bereits im geheimen Schlüsselbund
gpg: Schlüssel 2FF8F5A6: Ist bereits im geheimen Schlüsselbund
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 6
gpg:                             unverändert: 4
gpg:              gelesene geheime Schlüssel: 2
gpg:                 unveränderte geh. Schl.: 2
Es ist ein fataler Fehler aufgetreten:
  Schluesseldatei /root/.ftplicity/gpgkey ungueltig.

Tja, endweder vernichtet ftplicity die gpg keys oder es war sonstwas passiert. Jetzt muss ich nochmal versuchen. Mit deutlich weniger Daten.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Chaoshh« (04.07.2010, 11:29)

Zum Seitenanfang

strcat

Unix Gladiator

Beiträge: 2 331

Wohnort: /Earth/Germany/Bavaria/Regensburg

04.07.2010, 14:14

Zitat
Original von Chaoshh
Habe jetzt einen Testlauf gestartet. Eine Dateimenge von ca. 64 GB wurde mit
Quellcode
1
solus44 : ~# /usr/local/bin/ftplicity full
gesichert. Es hatte ewig gedauert, etwa. 1 1/2 Tage. Danach wollte ich das Backup nochmal restaurieren. Leider gab es am Ende eine Fehlermeldung:

1 1/2 Tage fuer 64 GB? Ueber SSH/SCP durch eine 64kb/s Leitung oder wie?

Christian 'strcat' Schneider <http://www.strcat.de/>
/* When all else fails, read the instructions. */

Zum Seitenanfang

Chaoshh

Schüler

Beiträge: 102

Beruf: angehender Linuxer

04.07.2010, 15:25

Gute Frage. Beide Geräte hängen am gleichen Netz, also müssten es eigentlich 100 MBit/s sein. Allerdings ist die CPU des Server auch nur ein ATOM 230 mit 2GB RAM 667MHz.

Zum Seitenanfang

strcat

Unix Gladiator

Beiträge: 2 331

Wohnort: /Earth/Germany/Bavaria/Regensburg

04.07.2010, 16:03

1 1/2 Tage fuer 60G ist kein Zeitraum, sondern ein Zustand; selbst ueber10 MBit/s. Mach das Backup testweise mal mit ftp/rsync/scp oder was halt zur Verfuegung steht und sieh nach wielange es damit dauert. Evtl. vorher pruefen ob DMA aktiviert ist (wenn nicht kanns wirklich langsam werden).

Christian 'strcat' Schneider <http://www.strcat.de/>
/* When all else fails, read the instructions. */

Zum Seitenanfang

Chaoshh

Schüler

Beiträge: 102

Beruf: angehender Linuxer

04.07.2010, 18:15

Ich denke, daß liegt an der Verschlüsselung und Signierung der Datei ftplicity. Die CPU ist halt nicht so leistungsstark - ist nur ein Testsystem - und vielleicht dauert es damit halt länger. Was könnte denn sonst das ganze so verlangsamen? Auf dem Server läuft außerdem nur noch ntpd und smb/nmb.

Zum Seitenanfang

Chaoshh

Schüler

Beiträge: 102

Beruf: angehender Linuxer

05.07.2010, 00:04

Ich glaube es zu wissen wieso das so lange dauerte - es waren unter den Testdateien nämlich einige, die recht groß waren. Mehrere GB. Das kann natürlich sein, daß die Bearbeitung dieser länger dauert und mehr Power kostet. Das Backup von Heute dauerte mit ca. 30GB nämlich "nur" ca. 4 Stunden.

Zum Seitenanfang

strcat

Unix Gladiator

Beiträge: 2 331

Wohnort: /Earth/Germany/Bavaria/Regensburg

05.07.2010, 00:35

4h fuer 30G? Meine Kunden wuerden - zurecht - Amok laufen wenn ich denen so eine Loesung praesentieren wuerde.

Christian 'strcat' Schneider <http://www.strcat.de/>
/* When all else fails, read the instructions. */

Zum Seitenanfang

Chaoshh

Schüler

Beiträge: 102

Beruf: angehender Linuxer

05.07.2010, 12:00

Testsystem wie gesagt. Laufen soll das auf einem anderen, stärkeren. Ich kann nichts dafür wenn ftplicity / duplicity so langsam arbeitet. Einen anderen Grund für diese Verlangsamung sehe ich zur Zeit nicht.

@ linuxer
Deine Modifikationen am Script (wg. der zusätzlichen config) machen Probleme. Denn leider wird - zum Beispiel um die Daten wieder herzustellen - noch ein oder gar mehrere Argumente benötigt. Das geht dann aber nicht mehr, weil Deine Modifikation dies ändert und stattdessen eine config erwartet.

	Quellcode
1 2 3	solus44: ~# /usr/local/bin/ftplicity restore /mnt CONF=/root/.ftplicity//mnt Das Konfigfile /root/.ftplicity//mnt kann nicht gelesen werden!

Zum Seitenanfang

Zurzeit ist neben Ihnen 1 Benutzer in diesem Thema unterwegs:

1 Besucher