glod
Goto Top

Rsync kann einige Files nicht synchronisieren (code 23)

Hallo!

Ich möchte Daten per rsync von einem Linux-Server auf einen anderen synchronisieren, dass läuft aber bei vielen Dateien auf Fehler

Der Befehl sieht so aus:

rsync -azvAp --delete /srv/share/zentral/ backup:/500GB/backup

Den Befehl setze ich als root ab.

Das klappt zu einem Teil, aber bei sehr vielen Dateien steht:

1a23e8acf1d7e34a3a159ef641fd3203

Am Ende steht dann:

22c3335175434e46f2064e00bce8e236

was bedeutet das?

Wie kann ich sicher stellen, dass der rsync-Befehl auch wirklich alles synchronisiert?

Content-Key: 136097

Url: https://administrator.de/contentid/136097

Printed on: April 24, 2024 at 00:04 o'clock

Member: MegaTraveller
MegaTraveller Feb 17, 2010 at 08:50:22 (UTC)
Goto Top
Hallo,

es kann sein, dass Du

a) Dateien hast die nicht so ganz in die POSIX Namenenskonvention passen oder
b) das Du auf einige der Dateien keine Rechte hast (auch wenn Du den Befehl als root ausführst

kannst Du mal ein paar Details zu den zu synchronisierenden Dateien geben. Ansonsten mal den Output mit > (file_name) 2>&1 umleiten, dann können wir ja mal im Detail an einem Dateibeispiel gucken.

Bye
MT
Member: glod
glod Feb 17, 2010 at 09:11:56 (UTC)
Goto Top
Hallo!

Habe mittlerweile rausgefunden, dass trotz der Meldungen alle Dateien rübergesynct werden, allerdings werden die ACLs zerschossen und nur noch root, der Besitzer und die Besitzergruppe können auf die Datei zugreifen. wir haben aber natürlich diverse Gruppen erstellt, die auch in den ACLs stehen und dann auf dem Zielserver nicht mehr auf die Datei zugreifen können.

Der Parameter A soll ja eigentlich dafür sorgen, dass die ACLs mit rübergeschoben werden.

Ich habe nun von meinem Rechenzentrum den Hinweis bekommen, dass ich ausserhalb des /srv-Verzeichnisses keine ACLs mehr beeinflussen kann. Auf dem Zielserver kopiere ich aber ja die Dateien nicht in ein Unterverzeichnis unter /srv sondern auf eine komplett andere gemountete Platte (in diesem Fall also nach /500GB/backup)

Ich vermute hier das Problem.

Aber wie haben die das gemacht und gibt es einen Weg, diese Einschränkung zumindest für meine zusätzliche Platte wieder aufzuheben, so dass die ACLs mitgenommen werden können?

Jemand 'ne Idee?
Member: MegaTraveller
MegaTraveller Feb 17, 2010 at 13:02:19 (UTC)
Goto Top
Hallo,

kann es sein, dass die Dateisysteme, also sprich Quelle und Ziel unterschiedlich sind?

Bye
MT
Member: glod
glod Feb 17, 2010 at 13:52:43 (UTC)
Goto Top
nein, bei Quelle und Ziel handelt es sich um linux-Dateisystem
Member: MegaTraveller
MegaTraveller Feb 17, 2010 at 14:07:18 (UTC)
Goto Top
Seltsam, dann sollten die ACLs mitkommen.

Zwei Sachen vielleicht noch.

Passiert das auch wenn Du die Kompression raus nimmst?

Bei einigen Distributionen gab es mal Probleme mit dem Thema SLES war eine der Baustellen, ich weiß aber nicht genau ob das mal gefixt wurde oder nicht. Welche Dist, benutzt Du?
Member: glod
glod Feb 17, 2010 at 14:59:46 (UTC)
Goto Top
Habe mal testweise die Kompression rausgenommen, kein Erfolg. Es wird weiterhin die ACL zerschossen.

Hier mal ein Beispiel: das Verzeichnis fawism sieht auf dem Quellserver acl-mäßig so aus:

  1. file: fawism/
  2. owner: root
  3. group: root
user::rwx
group::r-x
group:sperre-alle-lw:---
group:sperre-lw-q:---
group:fawism_admin:rwx
group:fawism:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:fawism_admin:rwx
default:group:fawism:rwx
default:mask::rwx
default:other::---


Nach dem Syncen sieht die ACL auf dem Zielserver dann so aus:

  1. file: fawism/
  2. owner: root
  3. group: root
user::rwx
group::rwx
other::---


Alles schön sauber ;)

die Frage ist: wieso und wie löse ich das Problem...?
Member: MegaTraveller
MegaTraveller Feb 18, 2010 at 10:29:44 (UTC)
Goto Top
Sorry, bin noch dran, jedoch wie das so in der Arbeit ist ^_^
Member: MegaTraveller
MegaTraveller Feb 18, 2010 at 11:03:43 (UTC)
Goto Top
Aaaalso, ich habe mir mal ein paar Ideen noch von einem Kollegen geholt. Laut deren Info sollte das ja alles ganz wunderbar gehen. Also, vielleicht noch zwei interessante Punkte.

Hast Du das Volume vom anderen Server mit root Rechten gemountet? (Ich würde mal vermuten ja, das wäre ja Standard)

Eine Vermutung des Kollegen war, dass Du vielleicht auf der Zielbox einen User mit gleicher ID aber anderen Rechten hast, weshalb die Rechte, für diese ID, nicht gesetzt werden können.

Der völlige Brachialtrick um ein Problem bei den IDs zu umgehen und um zu sehen, ob vielleicht die verwendete Version das Problem herstellt, ist, laut meinen Kollegen, dass Du die IDs von Quellserver auf Zielserver klonst, den rsync job ausführst, die Berechtigungen checkst und anschließend die IDs auf dem Zielserver wiederherstellst. Dadurch könnten wir es ja ein wenig eingrenzen.
Member: glod
glod Feb 18, 2010 at 12:37:55 (UTC)
Goto Top
Vielen Dank MegaTraveller für die Hilfestellung und Ideen und den Hirnschmalz!!!

Die Lösung war dann aber doch etwas anderes (hat mich ein Kollege drauf gebracht):

Die Festplatte war irgendwie falsch gemountet. Wenn man "mount" eingibt, erhält man ja die Übersicht, was wie gemountet ist. Dort steht dann nicht nur das Dateisystem (was ja bei mir korrekterweise ext3 bei Quelle und Ziel ist) sondern auch weitere Parameter zum Volume.

Und genau bei den Parametern war der Hund begraben. Meine zusätzliche IDE-Platte war mit dem Standard Mount-Befehl ohne Parameter gemountet und hatte daher bei den Parametern nur "rw" stehen.

Um die erweiterten ACLs auf diesem Volume aber auch nutzen zu können, muss mindestens auch der Parameter "acl" erscheinen.

Ich habe das so gelöst: in der /etc/fstab habe ich den Eintrag für die weitere Platte wie folgt modifiziert:

/dev/hda1            /500GB               ext3       noauto,acl,usrquota   0 0

und das volume einmal mit umount und mount neu gemountet. Und siehe da, nun steht nach Eingabe von "mount" bei dem Volume als Parameter auch acl mit drin.

Wenn ich nun mittels rsync und dem Parameter -A synchronisiere, werden auch schön die ACLs mit rüber geschoben. Fein Fein!

Also nochmal: auch wenn's nicht direkt die Lösung war: vielen Dank für die Tipps und Ideen!!!
Member: MegaTraveller
MegaTraveller Feb 18, 2010 at 13:15:59 (UTC)
Goto Top
Cool, Dank, wieder auch mal was dazu gelernt face-smile