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
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.
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.
Man braucht das Rad nicht nochmal zu erfinden, daher wie vom Vorredner schon vorgeschlagen: rsync.
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.
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/robocopy_fuer_windows_daten_schnell_und_einfach_sichern/index2.html 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.
Wie schon oben von einigen vorgeschlagen ... rsync Was fertiges gibt es unter https://wiki.ubuntuusers.de/Skripte/Backup_mit_RSYNC/
diff für Binaries ist eine blöde Idee. Wenn schon separat vergleichen (statt z.B. rsync), dann cmp.
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.
Wurde noch nicht genannt: rsync + rsnapshot. Etwas aus der Mode gekommen: Unison. (Für die Ausgangsfrage nicht passend, weil für Windows: SyncToy.)
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
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)
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.
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
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.
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.
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 | 1 Skript gestartet auf Mi 10 Aug 2016 19:12:53 CEST |
2 | 2 sheeva@plug:~/diffutils/b$ ls -l |
3 | 3 insgesamt 947676 |
4 | 4 -rw-r--r-- 1 sheeva sheeva 323147591 Aug 10 18:06 1 |
5 | 5 -rw-r--r-- 1 sheeva sheeva 323147591 Aug 10 18:18 2 |
6 | 6 -rw-r--r-- 1 sheeva sheeva 323147591 Aug 10 18:19 3 |
7 | 7 -rw-r--r-- 1 sheeva sheeva 0 Aug 10 19:12 typescript |
8 | 8 sheeva@plug:~/diffutils/b$ md5sum 1 2 3 |
9 | 9 4125a49b777f429f2f9c54597d68a401 1 |
10 | 10 4125a49b777f429f2f9c54597d68a401 2 |
11 | 11 757d4eea291ddf48599bf669a509267b 3 |
12 | 12 sheeva@plug:~/diffutils/b$ du -hsb 1 2 3 |
13 | 13 323147591 1 |
14 | 14 323147591 2 |
15 | 15 323147591 3 |
16 | 16 sheeva@plug:~/diffutils/b$ time diff 1 2 |
17 | 17 |
18 | 18 real 0m0.247s |
19 | 19 user 0m0.036s |
20 | 20 sys 0m0.208s |
21 | 21 sheeva@plug:~/diffutils/b$ time cmp 1 2 |
22 | 22 |
23 | 23 real 0m0.778s |
24 | 24 user 0m0.572s |
25 | 25 sys 0m0.200s |
26 | 26 sheeva@plug:~/diffutils/b$ time diff 1 3 |
27 | 27 Binärdateien 1 und 3 sind verschieden. |
28 | 28 |
29 | 29 real 0m0.230s |
30 | 30 user 0m0.036s |
31 | 31 sys 0m0.188s |
32 | 32 sheeva@plug:~/diffutils/b$ time cmp 1 3 |
33 | 33 1 3 differieren: Byte 323147591, Zeile 1225448 |
34 | 34 |
35 | 35 real 0m0.774s |
36 | 36 user 0m0.568s |
37 | 37 sys 0m0.204s |
38 | 38 sheeva@plug:~/diffutils/b$ exit |
39 | 39 exit |
40 | 40 |
41 | 41 Skript beendet: Mi 10 Aug 2016 19:13:38 CEST |
:
Bearbeitet durch User
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?
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
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.
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
> 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.
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).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.