mikrocontroller.net

Forum: PC-Programmierung Skript: sicheres Dateien Kopieren auf NAS


Autor: Thomas T. (runout)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Loide,

ich möchte per cronjob  einmal täglich alle Snapshotdateien vom Raspi 
auf ein NAS  ! SICHER ! kopieren.

Das Nas ist gemountet und die Zugriffsrechte passen.

Sicher Kopieren wäre m.E. Kopieren -> Src/Dest-Vergleichen -> 
Src-Löschen.

Jetzt gibt's unter Linux wieder jede Menge Herangehensweisen...

Das Kopieren nach einem bestimmtem Dateimuster funktioniert.
Das Löschen auch.

Aber wie geht das Vergleichen am besten?
Zeit habe ich, könnte also "diff" oder so verwenden.
Dateiname bzw. Zeistempel und Dateigröße wären aber auch OK.

Wenn Vergleich (rekursiv) = OK -> Dateien in Quellordner löschen.

Tipp mit kleiner Begründung reicht...

Grüße Runout

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas T. schrieb:
> Aber wie geht das Vergleichen am besten?
über einen Hash

> Zeit habe ich, könnte also "diff" oder so verwenden.
warum machst du es dann nicht?

> Dateiname bzw. Zeistempel und Dateigröße wären aber auch OK.
das hat dann aber nichts mit sicher zu tun. Die kann dann immer noch 
einen Fehlerhafte Inhalt haben und der ist ja wichtig.


Lege zu jeder Datei einen .md5 hash Dann kopierst du alles. Prüfst auf 
der anderen Seite noch mal ob der Hash zu Datei passt und dann löscht 
du. Dann kannst du auch später noch feststellen, ob der Dateiinhalt 
immer noch richtig ist. Es ist gar nicht so selten, das auch einige Byte 
in den Dateien defekt sind.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas T. schrieb:
> ich möchte per cronjob  einmal täglich alle Snapshotdateien vom Raspi
> auf ein NAS  ! SICHER ! kopieren.

Für sowas gibt es rsync und, wenn erweiterte Funktionen gewünscht sind, 
Versionsverwaltungssysteme wie Git oder Subversion. Letztere führen eine 
Historie mit und benötigen daher mehr Diskspace, bieten dafür allerdings 
Komfortfunktionen wie "ich hätte gerne den Stand vom 18.5.".

> Aber wie geht das Vergleichen am besten?
> Zeit habe ich, könnte also "diff" oder so verwenden.

Das Vergleichen ist der Sinn von "diff" -- allerdings werden die gerade 
gesicherten Daten dann noch einmal komplett über das Netzwerk 
übertragen. Auch wenn Du genug Zeit hast, kann die Saturierung des 
Netzwerks durchaus neue Probleme aufwerfen. Daher wäre es wohl 
eleganter, auf beiden Seiten jeweils MD5-, SHA- oder andere 
kryptografische Prüfsummen (Hashes) von den Daten zu errechnen, und dann 
nurmehr diese zu vergleichen.

Autor: tmomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man braucht das Rad nicht nochmal zu erfinden, daher wie vom Vorredner 
schon vorgeschlagen: rsync.

Autor: Soeren Kein Gast (srkeingast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas T. schrieb:
> ich möchte per cronjob  einmal täglich alle Snapshotdateien vom Raspi
> auf ein NAS  ! SICHER ! kopieren.
>
> Das Nas ist gemountet und die Zugriffsrechte passen.

Hi,

sicherer ist, du lässt die Daten "ziehen".

Denn wenn ein "Bösewicht" (und davor hast du doch Angst, oder?) das 
gemountete Laufwerk sieht, und dann auch noch darauf rumschreiben und 
löschen kann, dann macht er es evtl. auch. Besser ist: er weiß gar 
nichts davon.

rsync ist aber auch hier ein Freund, nur eben andersherum.

Autor: Dieter (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Unter Linux habe ich gute Erfahrungen mit rsync.
Die Windows Version davon finde ich sehr langsam, weil sie auf cygwin 
basiert. Es gab mal von der ct ein Backup Skript mit rsync.
Ich bin dann irgendwann auf robocopy aus dem MS Haus umgestiegen:
http://www.tecchannel.de/storage/tools/2033515/rob...

Wenn es unter Windows grafisch sein soll, nutze ich auch die 
Synchronisieren Funktion von Total Commander. Der ist aber nicht ganz so 
schnell wie z.B. FreeFileSync.

Wenn es nur um Sourcecode geht wäre es auch eine Option auf dem NAS ein 
Versionskontrolle (.z.B GIT oder SVN) laufen zu lassen und dorthin 
einfach zu committen.

Autor: G. S. (varda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schon oben von einigen vorgeschlagen ...

rsync

Was fertiges gibt es unter

https://wiki.ubuntuusers.de/Skripte/Backup_mit_RSYNC/

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
diff für Binaries ist eine blöde Idee. Wenn schon separat vergleichen 
(statt z.B. rsync), dann cmp.

Autor: Jøran (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes J. schrieb:
> diff für Binaries ist eine blöde Idee. Wenn schon separat vergleichen

warum? man will ja nicht wissen was anders ist, sondern nur ob es einen 
unterschied gibt.

Autor: EcmSpy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurde noch nicht genannt: rsync + rsnapshot.
Etwas aus der Mode gekommen: Unison.
(Für die Ausgangsfrage nicht passend, weil für Windows: SyncToy.)

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> warum? man will ja nicht wissen was anders ist, sondern nur ob es einen
> unterschied gibt.

Weil diff i.d.R. die Differencies der vermeintlichen ASCII-Dateien 
zeilenweise ausgibt.

Dass klügere Varianten von diff dies mittlerweile bei Binaries unter 
Ausgabe einer Warnmeldung unterlassen, um das Terminal-Fenster des 
Benutzer nicht mit Hyroglyphen vollzumüllen, mag ja sein. Das ist aber 
nur den DAUs unter den Usern geschuldet.

"cmp" macht genau das, was Du ansprichst: Es stellt lediglich fest, ob 
zwei Dateien unterschiedlich sind oder nicht. Und da es auf Zeilenenden 
nicht achten muss, sondern einfach geradeaus durch beide Dateien rattern 
kann, ist es auch wesentlich effizienter, dies mit "cmp" zu machen als 
mit "diff". diff dagegen versucht, identische Textblöcke über tausende 
von Zeilen wiederzufinden. Dass dies bei Binärdateien ein hoffnungsloses 
Unterfangen ist, kann man sich leicht vorstellen.

Merke: diff für Textdateien, cmp für alles andere.

: Bearbeitet durch Moderator
Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Weil diff i.d.R. die Differencies der vermeintlichen ASCII-Dateien
> zeilenweise ausgibt.

diff d1 d2 > /dev/null

schon ist ruhe.

(oder -q als Parameter verwenden)

Autor: Planlos (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werf mal BTRFS in den Ring.
Da kannst du am Quellrecher regelmäßig Snapshots ziehen, und die 
Snapshots (btrfs send / receive) über's Netzwerk schicken und am 
Zielrechner/NAS wieder in Dateisystem-Snapshots umwandeln.

Ähnlich wie beim Rsync-Hardlink-Backup schaut jeder Snapshot komplett 
aus und enthält alle Dateien, aber nur die geänderten brauchen wirklich 
Platz.
Alle Daten sind auf beiden Seiten mit checksums auf Dateisystemebene 
versehen, hilft also auch gegen Bitrot.

Vorteil von BTRFS-Snapshots gegenüber RSync: Kein Vergleichslauf nötig, 
das Dateisystem merkt sich selber, welche Blöcke geändert sind, und bei 
einer kleinen Änderung in einer großen Datei benötigt auch nur der Block 
mit dieser Änderung Platz im Snapshot.

Nachteil: NAS/Zielspeicher braucht auch btrfs. Man kann zwar den "btrfs 
receive" Teil wegsparen, und sich nur die von "btrfs send" erzeugte 
Snapshot-Datei am NAS aufheben, das macht aber m.M.n den Restore 
unbequem und fehleranfällig.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> diff d1 d2 > /dev/null

cmp d1 d2 >/dev/null

geht genauso. Und es ist für Binärdateien sinnvoller. Warum, habe ich 
Dir beschrieben. Aber sturer Bock bleibt sturer Bock, der muss nichts 
dazulernen. Es funktioniert ja.

Warum haben die "blöden" Unix-Programmierer bloß in den 70ern zwei 
verschiedene Befehle dafür erfunden? diff reicht ja, sagt Peter II.

: Bearbeitet durch Moderator
Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> > Warum, habe ich Dir beschrieben.
>
> Weil diff i.d.R. die Differencies der vermeintlichen ASCII-Dateien
>zeilenweise ausgibt.
wenn das der Grund war, dann kann man ihn ja beeinflussen.

> Aber sturer Bock bleibt sturer Bock, der muss nichts
> dazulernen. Es funktioniert ja.
hättest du einen richtigen Grund genannt (diff ist langsamer weil er 
auch versucht einen Zeilenversatz anzugleichen) könnte ich deinen 
Einwand auch verstehen.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> hättest du einen richtigen Grund genannt (diff ist langsamer weil er
> auch versucht einen Zeilenversatz anzugleichen) könnte ich deinen
> Einwand auch verstehen.

Dann hast Du das überlesen:

Frank M. schrieb:
> diff dagegen versucht, identische Textblöcke über tausende
> von Zeilen wiederzufinden. Dass dies bei Binärdateien ein hoffnungsloses
> Unterfangen ist, kann man sich leicht vorstellen.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> "cmp" macht genau das, was Du ansprichst: Es stellt lediglich fest, ob
> zwei Dateien unterschiedlich sind oder nicht. Und da es auf Zeilenenden
> nicht achten muss, sondern einfach geradeaus durch beide Dateien rattern
> kann, ist es auch wesentlich effizienter, dies mit "cmp" zu machen als
> mit "diff". diff dagegen versucht, identische Textblöcke über tausende
> von Zeilen wiederzufinden. Dass dies bei Binärdateien ein hoffnungsloses
> Unterfangen ist, kann man sich leicht vorstellen.

Naja, "wesentlich effizienter"... in der Theorie vielleicht. Die Praxis 
sieht so aus (bitte beachte Zeile 33 zum Thema Zeilenorientierung):
     1  Skript gestartet auf Mi 10 Aug 2016 19:12:53 CEST
     2  sheeva@plug:~/diffutils/b$ ls -l
     3  insgesamt 947676
     4  -rw-r--r-- 1 sheeva sheeva 323147591 Aug 10 18:06 1
     5  -rw-r--r-- 1 sheeva sheeva 323147591 Aug 10 18:18 2
     6  -rw-r--r-- 1 sheeva sheeva 323147591 Aug 10 18:19 3
     7  -rw-r--r-- 1 sheeva sheeva         0 Aug 10 19:12 typescript
     8  sheeva@plug:~/diffutils/b$ md5sum 1 2 3
     9  4125a49b777f429f2f9c54597d68a401  1
    10  4125a49b777f429f2f9c54597d68a401  2
    11  757d4eea291ddf48599bf669a509267b  3
    12  sheeva@plug:~/diffutils/b$ du -hsb 1 2 3
    13  323147591       1
    14  323147591       2
    15  323147591       3
    16  sheeva@plug:~/diffutils/b$ time diff 1 2
    17
    18  real    0m0.247s
    19  user    0m0.036s
    20  sys     0m0.208s
    21  sheeva@plug:~/diffutils/b$ time cmp 1 2
    22
    23  real    0m0.778s
    24  user    0m0.572s
    25  sys     0m0.200s
    26  sheeva@plug:~/diffutils/b$ time diff 1 3
    27  Binärdateien 1 und 3 sind verschieden.
    28
    29  real    0m0.230s
    30  user    0m0.036s
    31  sys     0m0.188s
    32  sheeva@plug:~/diffutils/b$ time cmp 1 3
    33  1 3 differieren: Byte 323147591, Zeile 1225448
    34
    35  real    0m0.774s
    36  user    0m0.568s
    37  sys     0m0.204s
    38  sheeva@plug:~/diffutils/b$ exit
    39  exit
    40
    41  Skript beendet: Mi 10 Aug 2016 19:13:38 CEST

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Thomas T. schrieb:

> Sicher Kopieren wäre m.E. Kopieren -> Src/Dest-Vergleichen ->
> Src-Löschen.

Das ist nicht "sicher kopieren", sondern "sicher verschieben".

Du bist so wenig in der Lage, Dinge hinreichend abstrakt zu betrachten, 
dass man nur hoffen kann, dass niemals dei Existenz einer Einzelperson 
oder gar einer Firma von dir abhängen wird...

Allerdings: alle gängigen Betriebssysteme sind sich wohl völlig darüber 
im Klaren, dass sie es in der Regel nur mit Idioten als Benutzern zu tun 
haben. Deswegen machen die das schon von ganz allein völlig richtig (in 
deinem Sinne): wenn was verschoben wird, dann wird es am Quellort erst 
dann gelöscht, wenn die Ankunft im Ziel bestätigt ist...

Wo genau ist also dein Problem?

Autor: Thomas T. (runout)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uff, soviel geballtes Expertenwissen...

Meine "Snapshots" sind kleine JPG's, keine Snapshots im Sinne von Images 
oder
Versionsständen.

Also hash, Git, SVN fällt erstmal aus.
rsync dürfte sogar schon oversized sein.

cmp macht eigentlich das richtige.

c-haters freundlicher Hinweis, dass ein "move" schon
eigensicher funktioniert vereinfacht die Sache noch einmal.

Danke an alle
Runout

Autor: A. H. (ah8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mir nicht ganz sicher, was Du mit „sicher“ meinst. Solltest Du 
prüfen wollen, ob die Daten wirklich richtig auf dem Speichermedium 
angekommen sind, dann hast Du unter Linux erst einmal schlechte Karten. 
Der Grund ist der Buffer Cache. Schreibt eine Applikation Daten in eine 
Datei, so ist der Schreibaufruf in der Regel erfolgreich, wenn die Daten 
im Buffer Cache angekommen sind. Physisch geschrieben werden sie erst 
zeitversetzt im Hintergrund. Man kann durch Flags beim Öffnen einer 
Datei erreichen, dass der Schreibaufruf blockt, bis die Daten physisch 
geschrieben sind (synchronous I/O). Das muss Dein Kopierprogramm aber 
erst einmal tun und nicht alle Dateisysteme implementieren dieses 
Feature korrekt. Selbst dann kannst Du nicht sicher sein, dass Du 
anschließend die physischen Daten von der Platte vergleichst; auch Dein 
Vergleichsprogramm wird die Daten aus dem Buffer Cache erhalten, wenn 
sie dort noch vorhanden sind. Um das auszuschließen musst Du den Buffer 
Cache vorher geleert haben und die einzige sichere Methode, die mir dazu 
bekannt ist, ist das umounten des Dateisystems.

Bei NAS wird die Sache noch komplizierter. Zwar hast Du uns nicht 
gesagt, wie genau Du auf das NAS zugreifst und ich muss gestehen, ich 
weiß auch nicht, wie im Detail die einzelnen Methoden implementiert 
sind. Wenn das NAS aber „gemountet“ ist, dann besteht zumindest 
potentiell die Möglichkeit, das die Daten nicht nur remote, sondern auch 
noch lokal gepuffert werden. Sollte das der Fall sein, dann sagt Dir ein 
lokaler Vergleich noch nicht einmal zuverlässig, ob die Daten den 
lokalen Rechner überhaupt schon verlassen haben.

Mit rsync hast Du zumindest schon mal den lokalen Cache umgangen. Dazu 
muss das NAS aber nicht lokal gemountet sein. Statt dessen brauchst Du 
einen rsync Daemon auf dem NAS.

Autor: Thomas T. (runout)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

eigentlich möchte ich nur erreichen, dass die Dateien
auf dem NAS sind bevor sie lokal gelöscht werden.

Der Gesamtaufbau ist weder sicherheitsrelevant, zeit/traffic-kritisch
noch durch EMV oder labile Stpannungsversorgung gefährdet.

Das Zugriffsprotokoll auf das NAS ist "cifs".
Das Laufwerk selbst ist ein Zyxel NSA325 v2,
also etwas fertiges.

Nach einem umount/mount müsste tatsächlich
cmp "gültig" sein.

Werde das mal ausprobieren.

Grüße Runout

Autor: Zitronen Falter (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> auf ein NAS  ! SICHER ! kopieren.

kopieren bedeutet aber nicht die Quelle zu loeschen.

Und. Man kann trotzdem in den Hammer laufen. Windows hat zB immer noch 
die Pfadlaengen Beschraenkung auf 256 character. zB die Datei :

c:/benutzer/default user/public/public 
documents/roaming/MyApplication/downloads/Machines/Machines1234/Data/Bla 
aaaaaa/Experiment_blaa/temporary  settings/V123/data_hm.csv

ich hab's grad nicht mitgezaehlt. Aber mit ein bisschen Beschreib-Willen 
kriegt man einen langen Pfad hin. Wenn die nun ueber symbolische links 
gehen, faellt deren Laenge gar nicht auf.

Num mache ich ein Backup von dem Zeug auf ein NAS, natuerlich mit Samba, 
sodass man auf der windows Seite connect network drive machen kann.
Das Zeug wird dann nach etwas in der Richtung von
t://volume1/sharedfolder/user_1234/* kopiert, dh es gibt dann noch einen 
vorspann von nochmals 30 charactern.

Wenn alles zusammen laenger als 256 ist, geschieht ein Fehler, ohne dass 
man das merkt.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. H. schrieb:
> Ich bin mir nicht ganz sicher, was Du mit „sicher“ meinst. Solltest Du
> prüfen wollen, ob die Daten wirklich richtig auf dem Speichermedium
> angekommen sind, dann hast Du unter Linux erst einmal schlechte Karten.
> Der Grund ist der Buffer Cache. Schreibt eine Applikation Daten in eine
> Datei, so ist der Schreibaufruf in der Regel erfolgreich, wenn die Daten
> im Buffer Cache angekommen sind. Physisch geschrieben werden sie erst
> zeitversetzt im Hintergrund.

Das ist keine Besonderheit von Linux, sondern das macht jedes moderne 
Betriebssystem so. Aber in der Regel gibt es dabei Möglichkeiten, die 
Synchronisation des Puffers auf die Festplatte manuell anzustoßen; da 
existieren unter Linux das Programm sync(1) und der Syscall fsync(2).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.