staging.inyokaproject.org

rsync sichert defaultmäßig incrementell - d.h. nur geänderte Files werden übertragen.
Und "geändert" wird entweder über Filesize und mdate (Timestamp) oder über einen Hash (Option -c) ausgewählt.

Das weiß ich. Wieso also willst du die beiden Dateien sichern, obwohl sie sich nicht geändert haben? Sonst hätte sie ja einen neuen Zeitstempel. Haben sie nicht, also brauchen und sollen sie nicht gesichert werden.

Ich hatte geschrieben:

Da die Option "-c" wirklich sehr lahm ist (Sicherung auf ein ARM-Device) und ich sie deshalb meide, passiert(e) es, daß 2 Files bei unterschiedlichem Inhalt gleiche Size und gleichen bzw. keinen Timestamp haben/hatten

Und der unterschiedliche Inhalt ist u.a. die Versionsnummer von FF! Und besagte Files haben ein falsches bzw. garkein mdate:

1. Februar 2010, 01:00h

Guck mal bei die in /var/cache/apt/archives ein FF-Paket an.

EDIT:
Und die Moral von der Geschicht': "Trau' einem Backup ohne Verify nicht"!

Und was macht jetzt jemand aus dem Artikel oder nicht? Also bisher klingt es so, als ob man mit den zwei falschen FF-Dateien leben kann und sie beim nächsten Update sowieso wieder stimmen.

ingo2 schrieb:

Ich hatte mit dem umgekehrten Fall bei System-Backups zu kämpfen.

Da die Option "-c" wirklich sehr lahm ist (Sicherung auf ein ARM-Device) und ich sie deshalb meide, passiert(e) es, daß 2 Files bei unterschiedlichem Inhalt gleiche Size und gleichen bzw. keinen Timestamp haben/hatten:

FILE_1="./usr/share/iceweasel/browser/defaults/preferences/webide-prefs.js" 
FILE_2="./usr/share/iceweasel/browser/defaults/preferences/firefox.js"

und dadurch nicht ins Backup übertragen werden!

Abhilfe ist ein touch der Files vor einem rsync-Backup in meinem Script.

Vielleicht betrifft das auch nur Iceweasel?

Benno-007

Vielleicht betrifft das auch nur Iceweasel?

Das müßt ihr checken, ich habe hier kein *buntu mehr, aber ist ja wohl 'ne Kleinigkeit.

Ingo

Bei mir gibt es trotz neuem Firefox-Profil gar keine firefox.js mehr, nur:

$ ls -hal /usr/lib/firefox/browser/defaults/preferences/vendor-firefox.js
-rw-r--r-- 1 root root 382 Feb  9 23:45 /usr/lib/firefox/browser/defaults/preferences/vendor-firefox.js

Und die sieht aktuell aus.

webide-prefs.js gar keine.

Wäre dann sowieso ein FF-"Bug" - einen fehlenden Zeitstempel könnte man so sehen.

1

rsync --numeric-ids -avze ssh /home/benutzer benutzer@example.com:/backups 

Möchte man hier einen anderen Port als 22 nutzen, muss dies in der e-Option angegeben werden:

1

rsync --numeric-ids -avze "ssh -p PORT" /home/benutzer benutzer@example.com:/backups 

Nutzt man

1

rsync --numeric-ids -avze ssh /home/benutzer benutzer@example.com:PORT/backups 

kommt es zu einer Fehlermeldung, dass der Port nicht erreichbar ist.

Wegen Verständnisproblemen bei der Anwendung rsync-daemon habe ich einige kleine Ergänzungen im Abschnitt rsync-daemon vorgenommen. Siehe dazu auch mein Posting im Forum rsync: Synchronisation mit rsync-daemon klappt nicht.

Warum die Änderung von [Freigabename] in [share]?

Hallo,

V_for_Vortex schrieb:

Warum die Änderung von [Freigabename] in [share]?

Gute Frage, da Anglizismen im Wiki vermeiden werden sollen. Genau so wie Links auf das Wort "hier".

Gruß, noisefloor

V_for_Vortex schrieb:

Warum die Änderung von [Freigabename] in [share]?

Siehe mein Posting / Thread im Forum: rsync: Synchronisation mit rsync-daemon klappt nicht

Du kannst dort nachlesen, dass ich mir genau an [Freigabename] die Ohren gebrochen habe.

Meine Kritik: Die beispielhaft vorgestellte rsyncd.conf ist in jeder Zeile konkret, nur bei der Zeile [Freigabename] soll man ahnen, dass Freigabename durch eine konkrete Bezeichnung zu ersetzen ist. Für Experten mag das klar sein, für weniger Versierte aber nicht.

Wie man es besser macht, zeigt Juan Valencias Website. Dort sieht die beispielhaft rsyncd.conf nämlich unmissverständlich aus:

[documents]
    path = /home/juan/Documents
    comment = The documents folder of Juan

Aus meiner jetzigen Sicht finde ich übrigens auch die abstrakte rsync Syntax-Beschreibung unzulänglich:

rsync [OPTION...] [USER@]HOST::SRC... [DEST]
rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST]

Warum? Weil [DEST] ein Platzhalter ist für eine Pfadangabe. SRC aber ist ein Platzhalter für etwas anderes, nämlich Freigabename + Pfadangabe. Mit folgender Syntax-Beschreibung wäre die Sache besser beschrieben:

rsync [OPTION...] [USER@]HOST::MODULNAME[/SRC-PATH]... [DEST-PATH]
rsync [OPTION...] rsync://[USER@]HOST[:PORT]/MODULNAME[/SRC-PATH]... [DEST-PATH]

Der Modulname (Freigabename) als Pflichtangabe, SRC-Path als Kann-Angabe.

noisefloor schrieb:

Gute Frage, da Anglizismen im Wiki vermeiden werden sollen. Genau so wie Links auf das Wort "hier".

Gruß, noisefloor

Sorry. Ich habe die Link-Beschreibung "hier" durch konkreten Text ersetzt. Eigennamen sind keine Anglizismen.

Dieser Fehler

When specifying the --link-dest option for a destination that is on a remote host, your path should be given as a relative path from the perspective of the destination path. Don't use the user@host:full path syntax.

ist mir passiert.

Vielleicht sollte man irgendwo im Wiki erwähnen, dass bei der Option --link-dest am besten ein relativer Pfad zum Ziel-Verzeichnis angegeben werden sollte. Zumindest, wenn man über ssh sichert.

Oder ?

Hallo,

relativ zu was bzw. welchem Pfad eigentlich? Das ist mir gerade nicht ganz klar...

Gruß, noisefloor